8.2 MBMS RNC Signalling Flows

25.3463GPPIntroduction of the Multimedia Broadcast/Multicast Service (MBMS) in the Radio Access Network (RAN)Release 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.2.1 MBMS Session Start procedure

Figure 8.2.1: MBMS Session Start procedure. Successful operation.

The MBMS Session Start procedure is initiated by the CN when an MBMS Session is started. The MBMS SESSION START REQUEST is sent to each RNC that is connected to the CN (in case of Iu-flex the RNC may receive more than one MBMS SESSION START REQUEST message).

The MBMS SESSION START REQUEST contains the MBMS Service Id, and optionally the MBMS Session ID, MBMS Bearer Service Type and the MBMS Session Attributes (MBMS Service Area Information, QoS parameters…) It may also include a list of RAs which lists each RA that contains at least one PMM-IDLE UE that has activated the service.

MBMS Session Start procedure also provides the MBMS Iu Data Bearer Establishment functionality. In case of Iu-flex the RNC shall not establish more than one MBMS Iu bearer for a certain service towards a pool area and shall inform the respective CN nodes accordingly.

MBMS Session Start procedure may also be initiated by the CN to restore the MBMS service following an RNC failure or an Iu path failure as specified in TS 23.007 [15].

The MBMS Session Start procedure in case of IP Multicast is described in section 8.2.16.

8.2.2 MBMS Session Update procedure

Figure 8.2.2: MBMS Session Update procedure. Successful operation.

The MBMS Session Update procedure is initiated by the CN when an MBMS Session is ongoing and SGSN notices that there is a need to update the list of RAs. The MBMS SESSION UPDATE REQUEST contains the MBMS Service Id, and e.g. List of RAs with PMM Idle UEs..

8.2.3 MBMS Session Stop procedure

Figure 8.2.3: MBMS Session Stop procedure.

This signalling flow depicts the MBMS Session Stop procedure.

This procedure is initiated by the CN to the RNCs with an ongoing MBMS session, when no more data will be sent for that MBMS service for some period of time.

The MBMS Session Stop procedure also provides the MBMS Iu Data Bearer Release functionality.

8.2.4 RNC Registration procedure

Figure 8.2.4: MBMS Registration procedure.

This signalling flow depicts the MBMS Registration procedure.

This procedure is initiated by the RNC in the case that the RNC is not SRNC for any UE that has joined the MBMS Service, but this RNC is DRNC for PMM-CONNECTED UEs that have joined the MBMS Service and there is no MBMS Service Context for the MBMS Service in this RNC.

This procedure shall be initiated by the DRNC, as soon as a UE link is received over the Iur and there exists no MBMS Service Context for the MBMS service for which the UE link is received.

8.2.5 RNC De-Registration procedure

Figure 8.2.5: RNC MBMS De-Registration procedure.

This signalling flow depicts the RNC De-Registration procedure. This procedure is initiated by the RNC towards the CN node it was registered to in case the RNC is not acting as a Serving RNC for any UE that has activated the MBMS Service and has ceased to act as a Drift RNC for UEs which has activated an MBMS service.

8.2.6 CN De-Registration procedure

Figure 8.2.6: CN MBMS De-Registration procedure.

This signalling flow depicts the CN De-Registration procedure.

This procedure is initiated by the CN in order to inform the RNC that a certain MBMS Service is no longer available.

8.2.7 MBMS Channel Type Switching over Uu

Figure 8.2.7: Channel type switching signalling flow from p-t-m to p-t-p.

The CRNC is responsible for the decision regarding having p-t-m transmission or no p-t-m transmission in a cell for a specific MBMS service. The CRNC informs all the SRNCs having UEs in that cell about its decision. The SRNC is the RNC controlling the RRC connection and RBs to a specific UE. In the example shown, the CRNC decided to no longer use p-t-m, then the SRNC decided to perform channel type switching to deliver the MBMS service over DTCH mapped on a dedicated channel. The RB SETUP message contains the MBMS Service Id. It is FFS whether the SRNC always follows the CRNC’s request or not.

NOTE: the channel type switching in this case includes a change of both transport and logical channels.

8.2.8 MBMS UE Linking

Figure 8.2.8: MBMS UE linking signalling flow

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services.

The signalling flow is used to link a specific UE to one or several MBMS service contexts in the SRNC. The MBMS UE LINKING REQUEST message contains the whole list of MBMS Service Ids and MBMS PTP RAB IDs (e.g. mapped from NSAPIs) activated by the UE. If there has not been an MBMS service context related to an MBMS Service Id then SRNC creates an MBMS service context as a result of this procedure.

8.2.9 MBMS UE De-Linking

Figure 8.2.9: MBMS UE De-linking signalling flow

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services.

The signalling flow is used to remove a specific UE from one or several MBMS service context in the SRNC. The MBMS UE DE-LINKING REQUEST message contains the list of MBMS Service Ids de-activated by the UE.

8.2.10 MBMS Service Id Request

Figure 8.2.10: MBMS Service Id list over Iu signalling flow

This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The list of MBMS services the user has joined is sent over Iu.

The purpose of this signalling flow is to perform UE linking for a RRC connected, PMM idle user. The UE provides an indication that the user has joined at least one MBMS service and the PS Domain specific IDNNS (the message that would carry this information is FFS) whenever an Iu-cs connection is established and the UE is PMM idle (that is there is no Iu-ps connection), The RNC requests the MBMS services the UE has joined from the SGSN (or the SGSN the UE is attached to in case of Iu-flex) using a connectionless procedure. The MBMS SERVICE ID REQ contains the IMSI of the UE. The SGSN response contains the full list of MBMS services the user has joined.

The MBMS service list is then stored in the RNC. The list is deleted when the UE moves to RRC idle and the RRC context is removed in the RNC.

8.2.11 MBMS Attach/Detach over Iur

Figure 8.2.11-1: MBMS attach request signalling flow: Successful Operation.

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services.

The purpose of this signalling flow is

– to either allow the CRNC to add one or several new UEs to the total number of UEs in a given cell using one or several MBMS services. The MBMS ATTACH REQUEST then contains the Cell Id of the new cell (may contain the URA Id of the new URA for UEs in URA_PCH state), the whole list of affected MBMS Service Ids and a UTRAN specific UE Identification if necessary.

– or to allow the SRNC to inform the DRNC in which URA notifications for MBMS Services have to be sent. The MBMS ATTACH REQUEST then contains a list of URAs and the corresponding MBMS Services.

Figure 8.2.11-2: MBMS detach request signalling flow: Successful Operation.

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services.

The purpose of this signalling flow is

– to either allow the CRNC to decrease the total number of UEs receiving one or several MBMS service in a given cell. The MBMS DETACH REQUEST contains the Cell Id of the old cell (may contain the URA Id of the old URA for UEs in URA_PCH state), the whole list of affected MBMS Service Ids and a UTRAN specific UE Identification if necessary.

– or to allow the SRNC to inform the DRNC in which URA there is not anymore a need to send notifications for MBMS Services due to the presence of UEs in URA_PCH. The MBMS DETACH REQUEST then contains a list of URAs and the corresponding MBMS Services

8.2.12 MBMS Channel Type Reconfiguration over Iur

These signalling flows need further study.

Figure 8.2.12: Channel Type Reconfiguration signalling flow: Successful Operation.

This signalling flow is only applicable for handling MBMS UEs in RRC connected mode.

The purpose of this signalling flow is that the CRNC informs the selected channel type to the SRNCs used in a cell under the CRNC. The MBMS CHANNEL TYPE RECONFIGURATION INDICATION contains a list of U-RNTI, Channel type and MBMS Service Id corresponding to the UEs connected to the SRNC.

8.2.13 Information Exchange over Iur

These signalling flows is used by the DRNC to acquire the MBMS related information for MBMS service identified by TMGI and is used between the RNCs, which are controlling cells neighbouring to each other for selective/soft combining in case of inter-RNC synchronization.

Figure 8.2.13: Information Exchange Initiation signalling flow: Successful Operation.

The purpose of this signalling flow is that the DRNC request the APN and IP multicast address for an MBMS service. The INFORMATION EXCHANGE INITIATION REQUEST includes the TMGI for which the APN and IP multicast address are requested. In the INFORMATION EXCHANGE INITIATION RESPONSE message, the corresponding APN and IP multicast address are included.

If the Information Exchange procedure is started and the transmission mode is changed, this shall be reported by the INFORMATION REPORT message.

And the additional purpose of this signalling flow used in case of inter-RNC synchronization is

– to request the external neighbouring RNC(s) to provide the counting results in cells the neighbouring RNC controls

– to request the external neighbouring RNC(s) to inform about the transmission mode change in cells the neighbouring RNC controls for a MBMS session

– to request the external neighbouring RNC(s) to provide the MBMS PTM RB configuration used in cells the neighbouring RNC controls

– to request the external neighbouring RNC(s) to provide the RLC Sequence Number.

8.2.14 MBMS RAB Establishment Indication

Figure 8.2.14: MBMS RAB Establishment Indication procedure

This signalling flow is used by the RNC to indicate to the CN the establishment of the MBMS RAB corresponding to the MBMS Iu signalling connection.

When the RNC decides not to establish an MBMS Iu bearer, for a particular MBMS service, during MBMS Session Start procedure, for example the RNC does not control any contained in MBMS Service Area Information and the RNC does not belong to any of the RA in a list of RAs which lists each RA that contains at least one PMM-IDLE UE but later when a UE linking (via Iu or Iur) is performed or as a result (p-t-p decision) of channel type reconfiguration in another RNC, the RNC establishes the Iu bearer and uses this procedure to inform the CN that an Iu bearer has been established.

If Iu-Flex is active, the selection of the CN node is implementation dependant.

The MBMS RAB ESTABLISHMENT INDICATION message contains the Transport Layer Address IE and the Iu Transport Association IE.

8.2.15 MBMS RAB Release

Figure 8.2.15: MBMS RAB Release Request procedure.

This signalling flow is used by the RNC to indicate to the CN to request the release of an MBMS RAB.

At reception of the MBMS RAB RELEASE REQUEST message the CN should initiate the release of all MBMS resources related to the Iu connection without releasing the Iu signalling connection.

The RNC shall at reception of MBMS RAB RELEASE initiate the release of the related MBMS RAB resources.

The MBMS RAB release may be initiated e.g. for the following reasons (unexhausted):

– There are lack of rafio resource in UTRAN and RNC decided to pre-empt an MBMS RAB for a on-going MBMS session based on Allocation/Retention Priority

– When there are no UEs with a given activated MBMS service consuming radio resources in cells under the RNC or the RNC is controlling UEs in cells under another RNC;

– In case of channel type switching from ptp to ptm in cells under control of another RNC in its role of DRNC;

– There are no cells under the RNC which are part of the RA List Of Idle UEs if received.

8.2.16 MBMS Session Start procedure in case of IP Multicast transport

Figure 8.2.16-1: MBMS Session Start procedure. Successful operation.

The MBMS SESSION START REQUEST contains the MBMS Service Id, and optionally the MBMS Session ID, MBMS Bearer Service Type, the MBMS Session Attributes (MBMS Service Area Information, QoS parameters, …) and Transport Layer Address used for the IP-multicast and Iu Transport Association (DL TEID) IE. In addition in case PDCP is used for the MBMS service the PDCP information is included. It may also include a list of RAs which lists each RA that contains at least one PMM-IDLE UE that has activated the service.

The RNC stores the session attributes in the MBMS Service Context, sets the state attribute of its MBMS Service Context to ‘Active’ and joins the IP Multicast group, which is used for the User data delivery of this MBMS session between the GGSN and RNCs in case radio resource is available. In case of successful joining the indicated IP Multicast group the RNC replies to the CN nodes from which it has received the MBMS Session Start Request message that the IP Multicast Bearer setup was successful and establishes the radio resource for the transfer of MBMS data to the interested UEs.

8.2.17 MBSFN MCCH Information

Figure 8.2.17-1: MBSFN MCCH Information procedure, Successful Operation

The signalling flow shall be used only if MRNC is used for MBSFN operation.

The MBSFN MCCH INFORMATION message contains the MCCH messages list sent on the MRNC and the MCCH configuration information of the MRNC.

The signalling flow is used by the MRNC to inform the CRNC of the MCCH configuration and scheduling information used in MRNC upon receipt of MBMS SESSION START message from CN.

The CRNC shall prepare the setup of the requested MBMS sessions upon receipt of MBMS SESSION START message from CN，then instead of preparing RRC messages and physical configuration, wait for the MBSFN MCCH INFORMATION message that is sent from MRNC.

Upon receipt of the MBSFN MCCH INFORMATION message, if the MCCH Configuration IE exists, the CRNC shall setup or reconfigure the MCCH of all cells in the MBSFN cluster with the configuration contained in this IE, and update the System Information of these cells.

The CRNC shall decode the L3 Information IE contained in the MCCH Message List IE and apply the RLC/MAC/PHY configuration specified by relative MCCH Message to setup the RB information of MTCH, and then send the L3 Information IE on the MCCH in the receiving sequence at the beginning of the first MCCH modification period following the CFN carried in the message.