The motivation and principle of supporting Multi-server MBS session coordination is exactly similar to Multi-server eMBMS bearer coordination as described in TS 23.280.
The procedure in this sub clause applies to both multicast and broadcast MBS session. The principle and pre-condition is similar with eMBMS bearer coordination as defined in TS 23.280.
This procedure is used when two or more MC service servers are serving users in the same area and are configured to share 5G MBS sessions for that specific area. The MC service servers may be of the same kind or different kind. The MC service servers are not participating in the same group call, which means that each MC service server transmit media independently of each other.
Pre-conditions:
All MC service servers are configured with the contact information of those MC service servers that are configured to take the MBS session control role.
The MC service server 1 evaluates whether MBS transmission is desired for each service area in which MC service group members are located, based upon the locations, affiliation status and other factors.
The MC service server 1 determines whether another MC service server has already established an MBS session with coverage for the MBS service area where MBS transmissions are desired. To do this, the MC service server 1 consults a pre-configured list of MC service servers and sends them a discover MBS session request. This request may be sent to several MC service servers.
The MC service server 2 (MBS session control role) responds with a discover MBS session response indicating whether there is an MBS session available in the specific MBS service area with the requested bandwidth. The discover MBS session response message includes the MBS session ID of the MBS session that is shared between the MC service servers. If the MBS session of interest has insufficient bandwidth, the polling MC service server 1 may resort to unicast, or may allocate another MBS session for the congested area. If a duplicate MBS session is allocated for the same area, the MBS session should not be shared with other servers and may be torn down as soon as the congestion on the original MBS session clears up, in order to conserve resources.
For any MBS service areas not covered by another MC service server, the MC service server 1 prepares to distribute media to those MBS service areas by setting up an MBS session. The MBS session set up by the MC service server 1 may then become available for other MC service servers (controlling role) for other MC service groups.
The MC service server 1 performs the MBS session announcement towards MC client 1, as well as MBS notification handling, according to the relevant procedures specified in this specification. In case of multicast MBS sessions, the MC service UE subsequently initiates a UE session join towards 5GC, and may send a UE session join notification to MC service server 1 indicating it has successfully joined the multicast MBS session under consideration.
If the MC service server 2 is authorized to receive MBS related location information from the users utilizing the services from MC service server 1, the MC service server 2 may optionally do the MBS session announcement and handling of the notifications on behalf of MC service server 1. The notifications shall in this case be sent to both MC service server 1 and MC service server 2. In case of multicast MBS sessions, the MC service UE subsequently initiates a UE session join towards 5GC, and may send a UE session join notification to MC service server 2.
The MC service server 1 sends a media distribution request to the MC service server 2 (MBS session control role). The media distribution request is sent to reserve the specified capacity in the MBS session.
MC service server 2 (MBS session control role) sends a media distribution response to the MC service server 1 indicating whether the request can be supported and supplies details about the MBS session.
The MC service server 1 establishes a group communication session via the MBS session, informing MBS session connected MC service clients 1 and 2 that a group communication session is about to start on the MBS session. This step is equivalent to MapGroupToSessionStream.
The MC service server 1 sends a media distribution release request, informing the MC service server 2 (MBS session control role) to request the MC service server 2 (MBS session control role) to release the capacity that was reserved in step 5.
The procedure in this subclause applies to both multicast MBS session and broadcast MBS session.
The principle is similar to eMBMS bearer coordination within one group call as the following:
It may be used when two MC service servers are serving users in the same area and are configured to share MBS sessions for that specific area. The MC service servers are of the same kind, and the MC service servers may participate in the same group call, and by that have a need to deliver the same content.
Pre-conditions:
All MC service servers are configured with the contact information of those MC service servers that are configured to take the MBS session control role.
The MC service server 1 evaluates whether MBS based transmission is desired for each service area in which MC service group members are located, based upon the locations, affiliation status and other factors.
The MC service server 1 determines whether another MC service server has already established an MBS session with coverage for the MBS service area where MBS based transmission is desired. To do this, the MC service server 1 consults a pre-configured list of MC service servers and sends them a discover MBS session request. This request may be sent to several MC service servers.
The MC service server 2 (MBS session control role) responds with a discover MBS session response indicating whether there is an MBS session available in the specific MBS service area with the requested bandwidth. The discover MBS session response message includes the ID of the MBS session that is shared between the MC service servers. If the MBS session of interest has insufficient bandwidth, the polling MC service server 1 may resort to unicast, or may allocate another MBS session for the congested area. If a duplicate MBS session is allocated for the same area, the MBS session should not be shared with other servers and may be torn down as soon as the congestion on the original MBS session clears up, in order to conserve resources.
For any MBS service areas not covered by another MC service server, the MC service server 1 prepares to distribute media to those MBS service areas by setting up a MBS session. The MBS session created by the MC service server 1 may then become available for other MC service servers (controlling role) for other MC service groups.
The MC service server 1 performs the MBS session announcement as well as the MBS listening reporting according to the relevant procedures specified in this specification. In case of multicast MBS sessions, the MC service UE(s) subsequently initiate a UE session join towards 5GC, and may send a UE session join notification to MC service server 1 indicating it has successfully joined the multicast MBS session under consideration.
If the MC service server 2 is authorized to receive MBS related location information from the users utilizing the services from MC service server 1, the MC service server 2 may optionally do the MBS session announcement and handling the listening reports on behalf of MC service server 1. Listening reports shall in this case be sent to both MC service server 1 and MC service server 2. In case of multicast MBS sessions, the MC service UE(s) subsequently initiate a UE session join towards 5GC, and may send a UE session join notification to MC service server 2.
The MC service client 2 initiates a group call that is subject for MBS transmission. In this scenario there are more than one MC service server (i.e., MC service server 1 and MC service server 3) that serve MC service clients that are affiliated to the group, and by that should receive the media in the group call.
The MC service server 1 sends a media distribution request to the MC service server 2 (MBS session control role). The media distribution request includes the MC group identifier. This indicates that the media distribution request is used for this specific group call.
The MC service server 3 sends a media distribution request to the MC service server 2 (MBS session control role). The media distribution request includes the MC group identifier. This indicates that the media distribution request is used for this specific group call.
The MC service server 2 (MBS session control role) sends a media distribution response to the MC service server 1 indicating whether the request can be supported and supplies details about the MBS session. This also includes details on which media stream should be used for transmitting the media on the MBS session. This information is used in the MapGroupToSessionStream message sent by the MC service server when setting up the group call.
The MC service server 2 (MBS session control role) sends a media distribution response to the MC service server 3 indicating that the group call is already transmitted on the MBS session by another MC service server. Based on the information, the MC service server 3 could decide to not transmit media if media is already transmitted.
The MC service server 1 sends a media distribution release request, to request the MC service server 2 (MBS session control role) to release the capacity that was reserved in step 5. The media distribution release request shall only be sent when the group call is terminated.