Content for TS 23.246 Word version: 18.0.0
8.3 MBMS Session Start Procedure
8.3.0 General
8.3.1 MBMS Session Start Procedure for GERAN and UTRAN for GPRS
8.3.2 MBMS Session Start Procedure for E-UTRAN and UTRAN for EPS
...
...
8.3 MBMS Session Start Procedure p. 40
8.3.0 General p. 40
The BM-SC initiates the MBMS Session Start procedure when it is ready to send data. This is a request to activate all necessary bearer resources in the network for the transfer of MBMS data and to notify interested UEs of the imminent start of the transmission.
Through this procedure, MBMS session attributes such as QoS, MBMS service Area, estimated session duration, are provided to the registered GGSN(s) and SGSN(s), to all BSCs/RNCs that are connected to a listed SGSN and to the registered MBMS GW(s) and MME(s). In addition the procedure allocates the bearer plane to all registered GGSNs, all registered SGSNs and all registered MBMS GWs, to BSCs/RNCs and E-UTRAN that respond to the session start request message. If IP multicast distribution of MBMS user plane data to E-UTRAN/UTRAN is supported, the MBMS-GW allocates an IP Multicast address together with the corresponding IP address of the multicast source (i.e. MBMS GW) and the C-TEID are provided to the eNodeB via MME and to the RNC via SGSN in this procedure. Optionally, in the case of E-UTRAN access (e.g. in deployments with a mix of IPv4 and IPv6 eNodeBs and/or backhauls) and if the MBMS GW supports both IPv4 and IPv6, both an IPv4 and an IPv6 IP Multicast address together with the corresponding alternative IP addresses of the multicast source are also allocated by the MBMS GW and provided to the E-UTRAN via the MME. An IP multicast address and the paired IP address of the multicast source shall be of the same IP type.
After sending the Session Start Request message the BM-SC waits for a configurable delay (time to MBMS data transfer) before sending MBMS data. This delay should be long enough to avoid buffering of MBMS data in entities other than the BM-SC, i.e. the delay should allow the network to perform all procedures required to enable MBMS data transfer before the BM-SC sends MBMS data. For example notification of UEs and radio bearer establishment should be performed before MBMS data arrive in the RAN. The delay may be in the region of multiple seconds or tens of seconds. It may be useful for the BM-SC to be able to configure different delays for MBMS bearer services on 2G, 3G and E-UTRAN, respectively.
For the distributed MCE architectures, i.e. when the MCE is part of the eNB as described in clause 15.1.1 of TS 36.300, an absolute time stamp for when data can be expected, "MBMS data transfer start", should be used at MBSFN operation mode to ensure synchronized session control and to facilitate a graceful reallocation of resources for the MBSFN when needed. When the parameter "MBMS data transfer start" is present, a receiving supporting node shall ignore the parameter "time to MBMS data transfer". For session stop signalling, the parameter "MBMS data transfer stop" is if present used to schedule the release of the radio resources in order to ensure a synchronized session control.
8.3.1 MBMS Session Start Procedure for GERAN and UTRAN for GPRS p. 41
For multicast MBMS bearer services the registration of SGSNs and GGSNs is initiated by MBMS multicast Service Activation procedures, Inter SGSN Routeing Area Update procedures, Inter SGSN Serving RNS Relocation procedure and performed by MBMS Registration procedures. The GGSN keeps track of the registered SGSNs in the list of downstream nodes.
For broadcast MBMS bearer services the list of downstream nodes of BM-SC and GGSN are achieved in the following ways:
- The list of downstream nodes for GGSN will be sent from the BM-SC to the GGSN in the Session Start Request.
Step 1.
The BM-SC Session and Transmission function sends a Session Start Request message to indicate the impending start of the transmission and to provide the session attributes (TMGI, Flow Identifier (Broadcast only), QoS, MBMS service Area, Session identifier, estimated session duration, broadcast/multicast, list of downstream nodes for GGSN (Broadcast only), time to MBMS data transfer, MBMS HC indicator (if header compression is used for MBMS payload), ...) and the 2G/3G indicator. The message is sent to the BM-SC Proxy and Transport function, which then forwards it to the GGSNs listed in the "list of downstream nodes" parameter of the corresponding MBMS Bearer Context. The BM-SC Proxy and Transport function sets the state attribute of its MBMS Bearer Context to 'Active'. For a broadcast MBMS bearer service the GGSN creates an MBMS bearer context. In broadcast mode, the BM SC may start multiple sessions for the same MBMS bearer service (identified by the TMGI) but with different content. If so, a Flow Identifier is included in the Session Start Request to identify the different sub-sessions and the associated MBMS Service Areas shall not overlap. The GGSN stores the session attributes and the list of downstream nodes in the MBMS Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active' and sends a Session Start Response message to the BM-SC. Proxy and Transport function which forwards it to the BM-SC Session and Transmission function. The BM-SC Proxy and Transport function copies Session Start Requests to the BM-SC Membership function for charging purposes.
Step 2.
The GGSN sends an MBMS Session Start Request message containing the session attributes (TMGI, Flow Identifier (Broadcast only), QoS, MBMS service Area, Session identifier, estimated session duration, broadcast/multicast, time to MBMS data transfer, IP Multicast and Source addresses for backbone distribution, common TEID-U, MBMS HC indicator, ...) and the 2G/3G indicator to the SGSNs listed in the "list of downstream nodes" parameter of the corresponding MBMS Bearer Context. For a broadcast MBMS bearer service the SGSN creates an MBMS bearer context. The SGSN stores the session attributes and the 2G/3G indicator in the MBMS Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active'. If one or more of the downstream nodes accepts the Session Start and the proposed IP Multicast and Source address for backbone distribution and the proposed C-TEID, the SGSN includes an indication that IP Multicast distribution is accepted in the MBMS Session Start Response message to GGSN. If one or more of the downstream nodes does not accept the proposed IP Multicast and Source address for backbone distribution or the proposed C-TEID or if there are downstream BSCs in Gb mode connected to the SGSN, the SGSN falls back to normal point-to-point MBMS bearer establishment for these nodes and responds with an MBMS Session Start Response message providing the TEID for bearer plane that the GGSN shall use for forwarding the MBMS data. Otherwise if all nodes accept multicast, the SGSN returns the C-TEID and the IP Multicast distribution address in the Session Start Response message. The GGSN shall initiate IP Multicast distribution if at least one of the SGSNs indicates it has accepted IP Multicast distribution. For MBMS bearer service a SGSN receiving multiple MBMS Session Start Request messages establishes only one bearer plane with one GGSN.
Step 3.
The SGSN sends an MBMS Session Start Request message including the session attributes (TMGI, QoS, MBMS service Area, Session identifier, estimated session duration, broadcast/multicast, time to MBMS data transfer, list of RAs, MBMS HC indicator, ...) to each BSC and/or each RNC that is connected to this SGSN. When the message is sent to an RNC/BSC in Iu mode, the IP Multicast and Source address for backbone distribution and C TEID shall also be included if received from the GGSN. The 2G/3G indicator shall be used by the SGSN to determine whether the MBMS Session Start Request message is sent only to BSCs, or only to RNCs, or to both RNCs and BSCs. For a broadcast MBMS bearer service the BSC/RNC creates an MBMS Service Context. The BSC in Iu mode/RNC stores the session attributes in the MBMS Service Context, sets the state attribute of its MBMS Service Context to 'Active'. If the RNC accepts the Session start and the proposed IP Multicast and Source address for backbone distribution and the proposed C-TEID the RNC sends an MBMS Session Start Response message to SGSN including an indication that IP Multicast distribution is accepted. If an RNC does not accept the proposed IP Multicast and Source address for backbone distribution (or the proposed C-TEID), the RNC falls back to normal point-to-point MBMS bearer establishment. A BSC in Gb mode which does not serve the MBMS Service Area need not store the session attributes. A BSC/RNC receiving multiple MBMS Session Start Request messages establishes only one bearer plane with one SGSN.
Step 3a.
If the BSC/RNC accepts IP Multicast distribution the BSC/RNC joins the multicast group in the IP backbone according to RFC 3376, RFC 3810 and RFC 4604.
Step 4.
The BSC/RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. RAN resource set up can be scheduled according to the time to MBMS data transfer parameter.
8.3.2 MBMS Session Start Procedure for E-UTRAN and UTRAN for EPS p. 42
The list of downstream nodes of BM-SC and the list of MBMS control plane nodes (MMEs and SGSNs) of MBMS GW are achieved in the following ways:
- The list of MBMS control plane nodes for MBMS GW will be sent from the BM-SC to the MBMS GW in the Session Start Request.
Figure 8b.2: Session Start procedure for E-UTRAN for EPS with delayed response
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
BM-SC sends a Session Start Request message to MBMS GW to indicate the impending start of the transmission and to provide the session attributes (TMGI, Flow Identifier, QoS, MBMS service Area, list of cell IDs if available, Session identifier, estimated session duration, list of MBMS control plane nodes (MMEs, SGSNs) for MBMS GW, time to MBMS data transfer, MBMS data transfer start, access indicator, ...). The message is sent to the MBMS GWs listed in the "downstream nodes" parameter of the corresponding MBMS Bearer Context in the BM-SC. The BM-SC may start multiple sessions for the same MBMS bearer service (identified by the TMGI) but with different content. If so, a Flow Identifier is included in the Session Start Request to identify the different sub-sessions and the associated MBMS Service Areas shall not overlap. The Access indicator indicates in which radio access types the MBMS service should be broadcasted, i.e. UTRAN, or E-UTRAN, or both. The Access indicator may be included in charging information generated by the MBSM GW.
If MBMS GW is configured to delay response to BMSC when access type is E-UTRAN, then MBMS GW delays response to BMSC (i.e. step 2) until after step 6 is executed as shown in Figure 8b.2. This configuration should be only performed when E-UTRAN executes step 7 below before responding to the MBMS Session Start message as specified in TS 36.300.
Step 2.
The MBMS GW responds with a Session Start Response message with information for BM-SC to send MBMS data to the MBMS GW , if Figure 8b.1 is executed. The MBMS GW responds only after first MME response in step 6 is received, if it is configured to do so as shown in Figure 8b.2.
Step 3.
The MBMS GW creates an MBMS bearer context. The MBMS GW stores the session attributes and the list of MBMS control plane nodes in the MBMS bearer context and allocates a transport network IP multicast address or, optionally, for E-UTRAN access (e.g. in deployments with a mix of IPv4 and IPv6 eNodeBs and/or backhauls) and if the MBMS GW supports both IPv4 and IPv6, both an IPv4 and an IPv6 IP Multicast address, according to clause 6.5.3 and a C-TEID for this session. The MBMS GW sends a Session Start Request message including the session attributes (TMGI, Flow Identifier, QoS, MBMS service Area, list of cell IDs if available, Session identifier, estimated session duration, transport network IP Multicast Address(es), IP address(es) of the multicast source, C-TEID, ...) to MMEs and/or SGSNs listed in the "list of MBMS control plane nodes" parameter after filtering the list using the Access indicator, thus ignoring entries not consistent with the Access indicator.
Step 4.
The MME or SGSN creates an MBMS bearer context. The MME/SGSN stores the session attributes and sends a Session Start Request message including the session attributes (TMGI, QoS, MBMS service area, list of cell IDs if available, Session identifier, estimated session duration, broadcast (for UTRAN only), transport network IP Multicast Address, IP address of the multicast source, C-TEID, ...) to E-UTRAN/UTRAN. Optionally in the case of E-UTRAN access and if the MBMS GW supports both IPv4 and IPv6, the MME includes both an IPv4 and an IPv6 IP Multicast address together with the corresponding alternative IP address(es) of the multicast source. When connected to multiple MCEs, the MME should filter the distribution of Session Control message to the MCEs based on the MBMS service area.
For UTRAN, if one or more of the downstream nodes accepts the Session Start with the proposed IP Multicast and Source addresses for backbone distribution and the proposed C-TEID, the SGSN includes an indication that IP Multicast distribution is accepted in the MBMS Session Start Response message to MBMS GW. If one or more of the downstream nodes does not accept the proposed IP Multicast and Source addresses for backbone distribution or the proposed C-TEID, the SGSN falls back to normal point-to-point MBMS bearer establishment for these nodes and responds with an MBMS Session Start Response message providing the TEID for bearer plane that the MBMS GW shall use for forwarding the MBMS data. Otherwise if all nodes accept multicast, the SGSN returns the C-TEID and the IP Multicast distribution address in the Session Start Response message.
For E-UTRAN access, eNB may respond to Session Start Request after first successful MBMS resources have been reserved (i.e. step 7) which indicates to the BMSC that there are resources already available for MBMS data delivery, as shown in Figure 8b.2.
Step 5.
The E-UTRAN/UTRAN creates an MBMS bearer context. The E-UTRAN/UTRAN stores the session attributes, sets the state attribute of its MBMS Bearer Context to 'Active' (in UTRAN only) and responds the MME/SGSN to confirm the reception of the Session Start Request message. When a cell ID list is included in the Session Start Request, E-UTRAN uses it to determine a set of radio resources to be used for the broadcast. Based on the cell ID list, the set of radio resources selected may be reduced from the full set of resources defined by the MBMS service area. The E-UTRAN ensures that all of its corresponding nodes make the same decision on the reduced set.
For UTRAN, if an RNC accepts the Session start and the proposed IP Multicast and Source addresses for backbone distribution and the proposed C-TEID the RNC sends an MBMS Session Start Response message to SGSN including an indication that IP Multicast distribution is accepted. If an RNC does not accept the proposed IP Multicast and Source address for backbone distribution (or the proposed C-TEID), the RNC falls back to normal point-to-point MBMS bearer establishment.
Step 6.
The MME/SGSN stores the session attributes and the identifier of the eNBs/RNCs as the "list of downstream nodes" parameter in its MBMS Bearer Context and responds to the MBMS GW. The SGSN should wait for a response from all UTRAN nodes (until an acceptable duration) to be able to report to the MBMS GW whether all, part or none of the RNCs have accepted IP multicast distribution and to provide an SGSN IP address and TEID for user plane over Sn if some RNCs did not accept IP multicast distribution. The MME may return an MBMS Session Start Response to the MBMS-GW as soon as the session request is accepted by one E-UTRAN node. The MBMS GW initiates IP Multicast distribution and/or point-to-point MBMS bearers (for UTRAN only) depending on the responses from the MMEs/SGSNs.
If the MBMS GW is configured to delay response to the BMSC, MBMS GW waits until step 6 occurs before responding to the BMSC as shown in Figure 8b.2.
Step 7.
The E-UTRAN/UTRAN establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. For E-UTRAN the radio resource set up is scheduled using the MBMS data transfer start parameter if it is present, otherwise using the time to MBMS data transfer parameter. The MBMS data transfer start parameter is not used by UTRAN.
Step 8.
If the E-UTRAN/UTRAN node accepts IP Multicast distribution, it joins the appropriate transport network IP multicast address (including the IP address of the multicast source) allocated by the MBMS GW, to enable reception of MBMS data. If several MBMS bearer services uses the same IP multicast address, the join is only done once.
Step 9.
The BM-SC starts sending the MBMS data.
Step 10.
MBMS GW function receives MBMS data. MBMS GW sends the MBMS data using IP multicast distribution towards all joined eNodeBs/RNCs.
