Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.246  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   4…   4.4…   4.4.3…   5…   6…   7…   8…   8.3…   8.4   8.5…   8.6…   8.7   8.8…   8.9…   8.10…   8.11…   8.16…   9…   C   D…   E…

 

8  MBMS ProceduresWord‑p. 37

8.1  MBMS NotificationWord‑p. 37

8.1.1  Iu mode notification (UTRAN and GERAN) for GPRSWord‑p. 37

When an MBMS Session starts, UEs interested in the MBMS bearer service (PMM-CONNECTED UEs and PMM-IDLE UEs) shall be notified.
MBMS Session attributes such as Session Identifier and MBMS Service Area(s) are made available in all interested RNCs during the Session Start procedure.
For radio efficiency reasons, the UTRAN may select on a per cell basis whether to establish point-to-point or point-to-multipoint links for the distribution of MBMS data to the UEs.
In order to perform this selection, the UTRAN requests a proportion of UEs to move to PMM-CONNECTED mode by means of MBMS notification sent in the MBMS service Area.
The exact number of UEs moved to PMM-CONNECTED mode is a decision of the RAN node. It is not necessary for all UEs to move to PMM-CONNECTED mode in order for the RAN to decide to use point-to-multipoint, other UEs may remain in PMM-IDLE state. This is a UTRAN choice (based on Radio Resource Management criteria).
Following the decision to set up point-to-point or point-to-multipoint links, the number of UEs that need to be maintained in PMM-CONNECTED mode or moved to PMM-IDLE mode for MBMS data reception is also a decision of the RAN node.
Up

8.1.2  A/Gb mode notification (GERAN)Word‑p. 38

When an MBMS Session starts, UEs interested in the MBMS bearer service and that are in READY or STANDBY states shall be notified. The MBMS notification triggers detection or counting of UEs per cell for selection of the most appropriate MBMS radio bearer.
MBMS Session attributes such as Session Identifier, MBMS Service Area, QoS are made available in all interested BSCs that are connected to a registered SGSN by the Session Start procedure.

8.2  MBMS Multicast Service ActivationWord‑p. 38

The MBMS multicast service activation procedure registers the user in the network to enable the reception of data from a specific multicast MBMS bearer service. The activation is a signalling procedure between the UE and the network. The procedure establishes MBMS UE contexts in UE, SGSN and GGSN and Iu mode BSC/RNC for each activated multicast MBMS bearer service comparable to regular PDP contexts.
Copy of original 3GPP image for 3GPP TS 23.246, Fig. 7: The activation of an MBMS multicast service
Up
Step 1.
The UE activates a general purpose PDP context if one is not already established.
Step 2.
The UE sends an IGMP (IPv4) or MLD (IPv6) Join message over the default PDP context to signal its interest in receiving a particular multicast MBMS bearer service identified by an IP multicast address.
Step 3.
The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive data. The MBMS Authorization Request may include trace information (Additional MBMS Trace Info), if activated. The authorization decision, which may be based on subscription data in the BM-SC, Membership function is provided in the MBMS Authorization Response together with the APN to be used for creation of the MBMS UE context. If the MBMS Authorization Response indicates that the UE is not authorized to receive the MBMS data the process terminates with no additional message exchange.
Step 4a.
The GGSN sends an MBMS Notification Request (IP multicast address, APN, Linked NSAPI) to the SGSN. Linked NSAPI is set equal to the NSAPI of the PDP context over which the Join request was received. The IP multicast address is the one requested by the UE in the Join request. The APN may be different from the APN to which the default PDP context has been activated. In any case, the APN may resolve to a GGSN that is different from the GGSN receiving the IGMP/MLD Join request.
Step 4b.
The SGSN sends a MBMS Notification Response (Cause) to the GGSN that sent the MBMS Notification Request, where Cause shall indicate whether or not the MBMS context activation will proceed. Upon reception of the response message with Cause indicating unsuccessful operation the GGSN should not send any further MBMS Notification Request messages. The procedure is then terminated.
Step 5.
The SGSN sends a Request MBMS Context Activation (IP multicast address, APN, Linked NSAPI, TI) to the UE to request it to activate an MBMS UE Context. Linked NSAPI allows the UE to associate the MBMS UE Context with the PDP context over which it sent the IGMP/MLD Join message in step 2. TI was chosen by the SGSN and contains a value not used by any other activated PDP context and MBMS UE context for this UE.
Step 6.
The UE creates an MBMS UE context and sends an Activate MBMS Context Request (IP multicast address, APN, MBMS_NSAPI, MBMS bearer capabilities) to the SGSN. The IP multicast address identifies the MBMS multicast service, which the UE wants to join/activate. An APN may indicate a specific GGSN. The MBMS bearer capabilities indicate the maximum QoS the UE can handle. The MBMS_NSAPI was chosen by the UE and contains a value not used by any other activated PDP context and MBMS UE context for this UE. If the SGSN has the MBMS Bearer Context information for this MBMS bearer service, the SGSN should verify the UE's MBMS bearer capabilities. If the SGSN determines that the UE's MBMS bearer capabilities are less than the Required MBMS Bearer Capabilities, it shall reject the request for activation of an MBMS context with an appropriate cause.
Step 7.
If the MBMS UE Context was not established, the SGSN sends a MBMS Notification Reject Request (Cause) to the GGSN that sent the MBMS Notification Request, where Cause shall indicate the reason why the MBMS UE Context could not be established. The GGSN then sends a MBMS Notification Reject Response back to the SGSN. This should prevent further sending of MBMS Notification Request messages. The procedure is then terminated.
Step 8.
Security Functions may be performed, e.g. to authenticate the UE.
Step 9.
In A/Gb mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, and OMC Identity) message to the BSS. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC.
Step 10.
The SGSN creates an MBMS UE context and sends a Create MBMS Context Requests (IP multicast address, APN, MBMS_NSAPI, IMSI, MSISDN, RAI, IMEI-SV, RAT Type, MS Time Zone, CGI/SAI, Trace Reference, Trace Type, Trigger Id, OMC Identity , Additional MBMS Trace Info) to the GGSN. The SGSN shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if GGSN trace is activated. The SGSN shall include Additional MBMS Trace Info if BM-SC trace is activated. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC. The inclusion of CGI/SAI shall be according rules detailed in clause 15.1.1a in TS 23.060.
Step 11.
The GGSN sends an MBMS Authorization Request (IMSI, MSISDN, RAI, IMEI-SV, RAT Type, MS Time Zone, CGI/SAI, Additional MBMS Trace Info) seeking authorization for the activating UE. The GGSN shall include Additional MBMS Trace Info if BM-SC trace is activated. The CGI/SAI is included, if available. The authorization decision is provided in the MBMS Authorization Response. The BM-SC creates an MBMS UE Context.
Step 12.
If the GGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the GGSN sends a MBMS Registration Request to the BM-SC. See clause "MBMS Registration Procedure".
If no TMGI has been allocated for this MBMS bearer service, the BM-SC will allocate a new TMGI. This TMGI will be passed to GGSN and SGSN via the MBMS Registration Response message and further to UE via Activate MBMS Context Accept message.
The BM-SC responds with a MBMS Registration Response containing the MBMS Bearer Context information for this MBMS bearer service and adds the identifier of the GGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context. See clause "MBMS Registration Procedure".
Step 13.
The GGSN creates an MBMS UE context and sends a Create MBMS Context Response to the SGSN.
Step 14.
If the SGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the SGSN sends a MBMS Registration Request to the GGSN. See clause "MBMS Registration Procedure".
The GGSN responds with a MBMS Registration Response containing the MBMS Bearer Context information for this MBMS bearer service and adds the identifier of the SGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context. See clause "MBMS Registration Procedure".
Step 15.
The SGSN provides Iu mode RAN with the MBMS UE Context(s) if at least one PS RAB is established for the UE.
Step 16.
In Iu mode and if trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, and OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC.
Step 17.
The SGSN sends an Activate MBMS Context Accept (TMGI) to the UE. If it was not possible to verify the UE's MBMS bearer capabilities in Step 6, the UE's MBMS bearer capabilities shall be verified now b y the SGSN. If the SGSN determines that the UE's MBMS bearer capabilities are lower than the Required MBMS Bearer Capabilities the SGSN rejects the request for activation of an MBMS context indicating an appropriate cause and starts the deactivation of the already established MBMS UE contexts.
Up

Up   Top   ToC