8.7 MBMS Multicast Service Deactivation
23.2463GPPArchitecture and functional descriptionMultimedia Broadcast/Multicast Service (MBMS)Release 17TS
The multicast service deactivation is a signalling procedure between the UE and the network. The procedure removes the MBMS UE Context from the UE, RAN, SGSN and GGSN for a particular MBMS multicast service. The multicast service deactivation can be initiated by:
– The UE;
– The GGSN;
– The BM-SC; or
– The SGSN
All these cases are contained in the procedure illustrated in figure 13. The UE initiated Multicast Service Deactivation starts with step 1), the BM-SC initiated Multicast Service Deactivation starts with step 3), the GGSN initiated Multicast Service Deactivation starts with step 4), the SGSN initiated Multicast Service Deactivation starts with step 5) or 9), and the MBMS UE de-linking is performed at step 7).
At GPRS detach, all MBMS UE contexts of the UE are implicitly deactivated in the UE, SGSN and GGSN, i.e. the SGSN performs the deactivation procedure starting with step 7).
If the PDP context linked to the MBMS UE context by the linked NSAPI is deactivated by the UE or SGSN or GGSN, then the SGSN shall perform the MBMS deactivation procedure starting with step 7). The UE will remove all MBMS UE Contexts locally after the Linked PDP Context was deactivated.
Figure 13: MBMS Multicast Service Deactivation
1. The UE sends an IGMP (IPv4) or MLD (IPv6) Leave message (here, the Leave message means Leave Group message in RFC 2236 for IGMP (IPv4) and Multicast Listener Done in RFC2710 for MLD (IPv6)) over the default PDP context to leave a particular multicast service identified by an IP multicast address.
2. The GGSN sends a Leave Indication (IP multicast address, APN,IMSI) to the BM-SC Proxy and Transport function, which forwards it to the BM-SC Membership function, indicating that the UE is requesting to leave the multicast service identified by the IP multicast address. The exact nature of the signalling between GGSN and BM-SC is specified in TS 29.061 [4].
3. Upon reception of the Leave Indication, the BM-SC Membership function verifies that the IP multicast address corresponds to a valid MBMS bearer service and sends a UE Removal Request (IP multicast address, APN, IMSI) to the GGSN that originated the Leave Indication. The APN shall be the same that was provided during service activation (see "MBMS Multicast Service Activation"). The exact nature of the signalling between GGSN and BM-SC is specified in TS 29.061 [4]. The BM-SC Membership function may also initiate the deactivation of an MBMS UE Context for service-specific reasons (e.g. the service is terminated but the UE has not yet left the multicast group) by directly sending a UE Removal Request message to the GGSN.
4. Upon reception of the UE Removal Request or for other reasons (e.g. Error cases), the GGSN sends an MBMS UE Context Deactivation Request (IP multicast address, APN, IMSI) to the SGSN. The IP multicast address, APN and IMSI together identify the MBMS UE Context to be deleted by the SGSN. The APN is the one received in step 3. The SGSN acknowledges reception of the MBMS UE Context Deactivation Request by sending an MBMS UE Context Deactivation Response to the GGSN.
5. Upon reception of the MBMS UE Context Deactivation Request or for other reasons (e.g. due to a change in the roaming restrictions for the user) the SGSN sends a Deactivate MBMS Context Request (TI) to the UE. The TI identifies the MBMS UE Context to be deleted by the UE.
6. The UE deletes the MBMS UE Context and sends a Deactivate MBMS Context Accept (TI) to the SGSN.
7. If the UE is PMM-CONNECTED and has been already linked towards the RAN, t he SGSN sends a MBMS UE De-Linking Request to the RNC (IP multicast address, APN, TMGI). RAN deletes the MBMS UE Context and sends a MBMS UE De-Linking Response (TMGI ) to the SGSN.
8. If dedicated radio resources are currently assigned to the UE for the reception of the MBMS data, the RAN releases these radio resources. If shared radio resources are currently assigned for the distribution of the MBMS data, the RAN may decide to move the remaining UEs to dedicated resources. The detailed procedures and conditions are specified in TS 25.346 [10] and TS 43.246 [11].
9. Upon reception of the Deactivate MBMS Context Accept or for other reasons (e.g. due to expiry of the long timer that is started upon a periodic routeing area update not being received) the SGSN sends a Delete MBMS Context Request (MBMS_NSAPI) to the GGSN that holds the MBMS UE Context. This GGSN may be different from the GGSN that receives IGMP Leave request in step 1.
10. The GGSN deletes the MBMS UE Context and sends a Deactivation Indication to the BM-SC to confirm the successful deactivation of the MBMS UE Context. The BM-SC, after receiving the Deactivation Indication, deletes the MBMS UE Context and sends a confirmation to the GGSN. The exact nature of the signalling between GGSN and BM-SC is specified in TS 29.061 [4].
11. If the GGSN does not have any more users interested in this MBMS bearer service and the "list of downstream nodes" in the corresponding MBMS Bearer Context is empty, the GGSN sends a MBMS De-Registration Request to the BM-SC Proxy and Transport function. The BM-SC Proxy and Transport function responds with a MBMS De-Registration Response and removes the identifier of the GGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context. See clause "MBMS De-Registration Procedure".
12. The GGSN confirms the deactivation of the MBMS UE Context to the SGSN by sending a Delete MBMS Context Response to the SGSN, which then deletes the MBMS UE Context.
13. If the SGSN does not have any more users interested in this MBMS bearer service and the "list of downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS De-Registration Request to the GGSN. The GGSN responds with an MBMS De-Registration Response and removes the identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context. See clause "MBMS De-Registration Procedure".