In this procedure the MC service client is requested by the MC service server to send a MBMS suspension report. This request for MBMS suspension report can be included in the MBMS bearer announcement and the MC service server may choose to only send this request for MBMS suspension report to a subset of all MC service clients.
The information flow below defines a procedure in which the MC service client notifies the MC service server about an MBMS suspension decision in RAN.
The MC service server can decide on a subset of all UEs in the MBMS broadcast area that shall report on MBMS bearer suspension. When the MC service server make the decision of the UE subset, consideration shall be taken to the location of the UEs, since UEs location is dynamically changed. This means that the MBMS suspension reporting instruction may need to be updated regularly based on the UEs mobility.
Pre-conditions:
It is assumed that there is at least one active MBMS bearer
The MC service client detect the MBMS suspension and sends an MBMS suspension report.
MC service client that is not instructed to send an MBMS suspension report shall still detect the MBMS suspension indication from RAN (step 3). An MC service client shall in this case not send other types of report (e.g. MBMS listening reports).
The same procedure can be applied at MBMS resumption or other MBMS events that may be detected by the MC service client.
To avoid allocating duplicate bearers for an MBMS service area, a single MC service server may manage all the MBMS media transmission for all groups and users within a particular MBMS service area. An MC service server controlling the MBMS bearer has the MBMS bearer control role. Different MC service servers may allocate bearers as needed and make them available for other MC service servers to use. The use of the procedure in this sub clause is optional. MC system that supports multi-server bearer coordination shall use this procedure.
The procedure in this sub clause may be used when two or more MC service servers are serving users in the same area and are configured to share MBMS bearers 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 broadcast 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 MBMS bearer control role.
The MC service server 1 evaluates whether multicast 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 a bearer with coverage for the MBMS service area where multicast is desired. To do this, the MC service server 1 consults a pre-configured list of MC service servers and sends them a discover bearer request. This request may be sent to several MC service servers.
The MC service server 2 (MBMS bearer control role) responds with a discover bearer response indicating whether there is an MBMS bearer available in the specific MBMS service area with the requested bandwidth. The discover bearer response message includes the TMGI of the bearer that is shared between the MC service servers. If the bearer of interest has insufficient bandwidth, the polling MC service server 1 may resort to unicast, or may allocate another bearer for the congested area. If a duplicate bearer is allocated for the same area, the bearer should not be shared with other servers and may be torn down as soon as the congestion on the original bearer clears up, in order to conserve resources.
For any MBMS service areas not covered by another MC service server, the MC service server 1 prepares to distribute media to those MBMS service areas via multicast by setting up a bearer. The bearer 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 MBMS bearer announcement and the MBMS listening reporting according relevant procedures specified in this specification. If the MC service server 2 is authorized to receive MBMS related location information from the users utilizing the services from MC service server 1, the MC service server 2 may optionally do the MBMS bearer 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.
The MC service server 1 sends a media distribution request to the MC service server 2 (MBMS bearer control role). The media distribution request is sent to reserve the specified capacity in the MBMS bearer.
MC service server 2 (MBMS bearer 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 bearer.
The MC service server 1 establishes a group communication session via the bearer, informing MBMS connected MC service clients 1 and 2 that a group communication session is about to start on the MBMS bearer. This step is equivalent to MapGroupToBearer in MCPTT.
The MC service server 1 sends a media distribution release request, informing the MC service server 2 (MBMB bearer control role) to request the MC service server 2 (MBMS bearer control role) to release the capacity that was reserved in step 5.
The procedure in this sub clause may be used when two MC service servers are serving users in the same area and are configured to share MBMS bearers 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 broadcast 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 MBMS bearer control role.
The MC service server 1 evaluates whether multicast 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 a bearer with coverage for the MBMS service area where multicast is desired. To do this, the MC service server 1 consults a pre-configured list of MC service servers and sends them a discover bearer request. This request may be sent to several MC service servers.
The MC service server 2 (MBMS bearer control role) responds with a discover bearer response indicating whether there is an MBMS bearer available in the specific MBMS service area with the requested bandwidth. The discover bearer response message includes the TMGI of the bearer that is shared between the MC service servers. If the bearer of interest has insufficient bandwidth, the polling MC service server 1 may resort to unicast, or may allocate another bearer for the congested area. If a duplicate bearer is allocated for the same area, the bearer should not be shared with other servers and may be torn down as soon as the congestion on the original bearer clears up, in order to conserve resources.
For any MBMS service areas not covered by another MC service server, the MC service server 1 prepares to distribute media to those MBMS service areas via multicast by setting up a bearer. The bearer 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 MBMS bearer announcement and the MBMS listening reporting according relevant procedures specified in this specification. If the MC service server 2 is authorized to receive MBMS related location information from the users utilizing the services from MC service server 1, the MC service server 2 may optionally do the MBMS bearer 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.
The MC service client 2 initiate a group call that is subject for multicast transmission. In this scenario there are more than one MC service server (i.e. MC service server 1 and MC service server 3) that serves 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 (MBMS bearer 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 (MBMS bearer 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 (MBMS bearer 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 bearer. This also includes details on which media stream that should be used for broadcasting the media on the MBMS bearer. This information is used in the MapGroupToBearer message sent by the MC service server when setting up the group call.
The MC service server 2 (MBMS bearer control role) sends a media distribution response to the MC service server 3 indicating that the group call is already transmitted on the MBMS bearer by another MC service server. Based on the information, the MC service server 3 could decide to not broadcast media if media is already being broadcasted.
The MC service server 1 sends a media distribution release request, informing the MC service server 2 (MBMS bearer control role) to request the MC service server 2 (MBMS bearer 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.