7.5A MBMS Messages

29.0603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaceRelease 17TS

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

7.5A.0 General

The MBMS messages defined here are control plane messages that are used in accordance with 3GPP TS 23.246 [26]. These are further categorised into control plane messages related to UE specific MBMS signalling, and control plane messages related to MBMS service specific signalling.

7.5A.1 UE Specific MBMS Messages

7.5A.1.1 MBMS Notification Request

When receiving an IGMP/MLD join message within a G-PDU, an MBMS capable GGSN shall initiate the authorisation procedure towards the BM-SC as outlined within TS29.061 [27]. Upon successful authorisation, the GGSN sends an MBMS Notification Request message to the SGSN from where the G-PDU was received. The IP address of the SGSN shall be derived from the address currently stored in the GGSN under the SGSN Address for Control Plane for the UE’s active PDP context.

The End User Address information element contains the PDP type and IP Multicast PDP address that the SGSN shall request the MS to activate. The IP multicast address shall be the one requested by the UE in the Join request.

The Access Point Name information element identifies the access point of packet data network that the UE should connect to receive the required MBMS service. It should be noted that the APN may resolve to a GGSN that is different from the GGSN sending the MBMS Notification Request. The configuration of this APN may be based on subscription information in the GGSN and is outside the scope of the standardisation.

The NSAPI information element is the NSAPI of the PDP context over which the IGMP/MLD join message was received.

The GGSN shall include a GGSN Address for control plane. The SGSN shall store this GGSN Address and use it when sending control plane messages to the GGSN.

The Tunnel Endpoint Identifier Control Plane information element shall be a tunnel endpoint identifier Control Plane selected by the GGSN and shall be used by the SGSN in the GTP header of the corresponding MBMS Notification Response or MBMS Notification Request Reject message.

The MBMS Protocol Configuration Options (MBMS PCO) information element may be included in the request when the GGSN wishes to provide the MS with MBMS specific parameters. The SGSN includes this IE in the Request MBMS Context Activation message if the associated MBMS Notification Request message from the GGSN includes MBMS protocol configuration options. The SGSN shall copy the content of this IE transparently from the content of the MBMS PCO IE in the MBMS Notification Request message.

Table 7.5A.1: Information Elements in an MBMS Notification Request

Information element	Presence requirement	Reference
IMSI	Mandatory	7.7.2
Tunnel Endpoint Identifier Control Plane	Mandatory	7.7.14
NSAPI	Mandatory	7.7.17
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
GGSN Address for Control Plane	Mandatory	7.7.32
MBMS Protocol Configuration Options	Optional	7.7.58
Private Extension	Optional	7.7.46

7.5A.1.2 MBMS Notification Response

The message is sent by a SGSN to GGSN as a response of a MBMS Notification Request.

The Cause value "Request accepted" indicates if the MBMS context activation will proceed. The MBMS context activation procedure will not proceed for all other Cause values.

Possible Cause values are:

– "Request Accepted".

– "No resources available".

– "Service not supported".

– "System failure".

– "GPRS connection suspended".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "Roaming restriction".

After an unsuccessful MBMS activation attempt the GGSN may, dependent the cause value indicated, and based on operator configuration fall back to IP multicast access as defined in 3GPP TS29.061[27].

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.2: Information Elements in a MBMS Notification Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.46

7.5A.1.3 MBMS Notification Reject Request

If the MBMS context activation proceeds after the MBMS Notification Response, but the MBMS UE context was not established, due to explicit rejection of the MBMS context Activation Request by the MS, or the MS not responding, or the MS MBMS Bearer Capabilities are insufficient, the SGSN sends a MBMS Notification Reject Request message. The Cause value indicates the reason why the MBMS UE Context could not be established:

– "MS is not GPRS Responding".

– "MS Refuses".

– "MS MBMS Capabilities Insufficient".

When receiving the MBMS Notification Reject Request message the GGSN may, dependent the cause value indicated, and based on operator configuration fall back to IP multicast access as defined in 3GPP TS29.061[27]..

The Tunnel Endpoint Identifier in the GTP header of the MBMS Notification Reject Request message shall be the same as the Tunnel Endpoint Identifier Control Plane information element of the MBMS Notification Request that triggered the reject.

The Tunnel Endpoint Identifier Control Plane information element shall be a tunnel endpoint identifier Control Plane selected by the SGSN and shall be used by the GGSN in the GTP header of the corresponding MBMS Notification Reject Response message.

The SGSN may include an SGSN Address for control plane, which may be used by the GGSN in the corresponding MBMS Notification Reject Response message.

The End User Address information element contains the PDP type and IP Multicast PDP address that could not be activated. The IP multicast address shall be the one requested by the UE in the Join request.

The Access Point Name shall be the same as the Access Point Name of the received MBMS Notification Request message that triggered the reject.

The NSAPI information element is the NSAPI of the PDP context over which the IGMP/MLD join message was received that triggered the MBMS Notification Request

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.3: Information Elements in a MBMS Notification Reject Request

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Tunnel Endpoint Identifier Control Plane	Mandatory	7.7.14
NSAPI	Mandatory	7.7.17
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
SGSN Address for Control Plane	Optional	7.7.32
Private Extension	Optional	7.7.46

7.5A.1.4 MBMS Notification Reject Response

The message is sent by a GGSN to SGSN as a response of a MBMS Notification Reject Request.

Possible Cause values are:

– "Request Accepted".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.4: Information Elements in a MBMS Notification Reject Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.46

7.5A.1.5 Create MBMS Context Request

A Create MBMS Context Request shall be sent from an SGSN node to a GGSN node as part of the MBMS Context Activation procedure. After sending the Create MBMS Context Request message, the SGSN marks the MBMS UE context as "waiting for response". A valid request creates a MBMS UE Context within the SGSN and GGSN, (see 3GPP TS 23.246 [26]). Furthermore, a valid request creates a GTP tunnel in the GTP-C plane, however no GTP-U tunnel is created at this step.

The Tunnel Endpoint Identifier Control Plane field specifies a downlink Tunnel Endpoint Identifier for control plane messages which is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink control plane messages which are related to the requested MBMS UE context.

The MSISDN of the MS shall be passed to the GGSN inside the Create MBMS Context Request. This additional information can be used when a secure access to a remote application residing on a server is needed. If no MSISDN is provided by the HSS, the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [2]). The GGSN would be in fact able to provide the user identity (i.e. the MSISDN) to the remote application server, providing it with the level of trust granted to users through successfully performing the GPRS authentication procedures, without having to re-authenticate the user at the application level.

The IMSI information element together with the Enhanced NSAPI information element uniquely identifies the MBMS UE context to be created. If available, the IMSI shall be passed to the GGSN inside the Create MBMS Context Request.

The End User Address information element contains the PDP type and IP Multicast PDP address that the UE requires to be activated. The SGSN shall include either the UE provided APN, a subscribed APN or an SGSN selected APN in the message. The Access Point Name information element identifies the access point of packet data network that the UE requires to connect to receive the required MBMS service. The Selection Mode information element shall indicate the origin of the APN in the message. The APN and End User Address information element shall uniquely identify the MBMS service.

The SGSN shall include an SGSN Address for control plane, which may differ from that provided by the underlying network service (e.g. IP). If the GGSN is IPv6 capable, the IPv4/IPv6 capable SGSN shall include IPv6 addresses in the field SGSN Address for signalling. Otherwise, it shall include IPv4 addresses in this field. The GGSN shall store the SGSN Address and use them when sending control plane on this GTP tunnel for the UE.

The SGSN shall include a Recovery information element into the Create MBMS Context Request if the SGSN is in contact with the GGSN for the very first time or if the SGSN has restarted recently and the new Restart Counter value has not yet been indicated to the GGSN. The GGSN that receives a Recovery information element in the Create MBMS Context Request message element shall handle it in the same way as when receiving an Echo Response message. The Create MBMS Context Request message shall be considered as a valid activation request for the MBMS UE context included in the message.

The SGSN shall include Trace Reference, Trace Type, Trigger Id, OMC Identity and Additional Trace Info in the message if GGSN trace is activated in the GGSN. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace request received from the HLR or OMC and the Trace Activity Control shall be set to Trace Activation.

If BM-SC trace is to be activated in the BM-SC (via the GGSN), the SGSN shall include Additional BM-SC Trace Info in the message. The SGSN shall populate the Additional MBMS Trace Info IE with the values of the relevant parameters included in the trace request received from the HLR or OMC, and the Trace Activity Control For BM-SC value shall be set to Trace Activation.

If Additional Trace Info and Additional MBMS Trace Info are both included within the message, the values of Trace Reference2 and Trace Recording Session Reference shall be the same in each IE.

For more detailed description of Trace Session activation/deactivation procedures see 3GPP TS 32.422 [31]

For SGSN and GGSN trace record description see 3GPP TS 32.423 [32]

The SGSN shall include the Routeing Area Identity (RAI) of the SGSN where the UE is registered. The MCC and MNC components shall be populated with the MCC and MNC, respectively, of the SGSN where the UE is registered. The LAC and RAC components shall be populated by the SGSN with the LAC and RAC, respectively, of where the UE is located at the time of the MBMS Context invocation. See one exception to this rule below in shared GERAN and UTRAN networks.

The SGSN shall include the User Location Information IE, MS Time Zone IE, RAT Type IE and the IMEI(SV) IE if they are available (see clause 15.1.1a of 3GPP TS 23.060 [4] for more information). If the User Location Information IE is included then the SGSN shall include the CGI or SAI in the "Geographic Location" field depending on whether the MS is in a cell or a service area respectively.

In shared networks,

– when the message is sent from the VPLMN to the HPLMN, the PLMN ID that is communicated in the User Location Information IE and Routeing Area Identity (RAI) IE shall be that of the selected Core Network Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting UEs. As an exception, based on inter-operator roaming/sharing agreement, if the information on whether the UE is a supporting or non-supporting UE is available, the PLMN ID that is communicated to the HPLMN for non-supported UEs shall be the Common PLMN ID. See clause 4.4 of 3GPP TS 23.251 [35];

– when the SGSN and GGSN pertain to the same PLMN, the Common PLMN ID shall be communicated in SAI/CGI to the GGSN, for both supporting and non-supporting UEs. The Core Network Operator PLMN ID (selected by the UE for supporting UEs or allocated by the network for non-supporting UEs) shall be communicated in RAI.

The optional Private Extension contains vendor or operator specific information.

The MBMS Protocol Configuration Options (MBMS PCO) information element may be included in the request when the MS provides the GGSN with MBMS specific parameters. The SGSN includes this IE in the Create MBMS Context Request if the associated Activate MBMS Context Request from the MS includes MBMS protocol configuration options. The SGSN shall copy the content of this IE transparently from the content of the MBMS PCO IE in the Activate MBMS Context Request message.

Table 7.5A.5: Information Elements in a Create MBMS Context Request

Information element	Presence requirement	Reference
IMSI	Conditional	7.7.2
Routeing Area Identity (RAI)	Mandatory	7.7.3
Recovery	Optional	7.7.11
Selection mode	Conditional	7.7.12
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
Trace Reference	Optional	7.7.24
Trace Type	Optional	7.7.25
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
SGSN Address for signalling	Mandatory	GSN Address 7.7.32
MSISDN	Conditional	7.7.33
Trigger Id	Optional	7.7.41
OMC Identity	Optional	7.7.42
RAT Type	Optional	7.7.50
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
IMEI(SV)	Optional	7.7.53
MBMS Protocol Configuration Options	Optional	7.7.58
Additonal Trace Info	Optional	7.7.62
Enhanced NSAPI	Mandatory	7.7.67
Additional MBMS Trace Info	Optional	7.7.68
Private Extension	Optional	7.7.46

7.5A.1.6 Create MBMS Context Response

The message shall be sent from a GGSN node to a SGSN node as a response of a Create MBMS Context Request. When the SGSN receives a Create MBMS Context Response with the Cause value indicating "Request Accepted", the SGSN may be required to register with the GGSN. For further details see MBMS Registration Request procedure.

The Cause value indicates if a MBMS UE context has been created in the GGSN or not. An MBMS UE context has not been created in the GGSN if the Cause differs from "Request accepted". Possible Cause values are:

– "Request Accepted".

– "No resources available".

– "No memory is available".

– "Missing or unknown APN".

– "Unknown PDP address or PDP type".

– "User authentication failed".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "APN access denied – no subscription".

"No resources available" indicates that not enough resources are available within the network to allow the MBMS UE Context to be created. "Missing or unknown APN" indicates e.g. when the GGSN does not support the Access Point Name. "Unknown PDP address or PDP type" indicates when the GGSN does not support the PDP type or the PDP address. Within the scope of MBMS message, an unknown PDP address is considered to be unknown mulitcast address / service.

"User authentication failed" indicates that the external packet network has rejected the service requested by the user. Only the Cause information element shall be included in the response if the Cause contains another value than "Request accepted".

The Tunnel Endpoint Identifier Control Plane field specifies an uplink Tunnel Endpoint Identifier for control plane messages, which is chosen by the GGSN. The SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent uplink-control plane messages, which are related to the requested MBMS UE context.

The GGSN shall include a GGSN Address for control plane, which may differ from that provided by the underlying network service (e.g. IP).

If the Create MBMS Context Request received from the SGSN included IPv6 SGSN address, an IPv4/IPv6 capable GGSN shall include IPv6 addresses in the fields GGSN Address for Control Plane, and IPv4 addresses in the fields Alternative GGSN Address for Control Plane. If SGSN included only an IPv4 SGSN address in the request, IPv4/IPv6 capable GGSN shall include IPv4 addresses in the fields GGSN Address for Control Plane and IPv6 addresses in the fields Alternative GGSN Address for Control Plane. The SGSN shall store these GGSN Addresses and use one set of them when sending control plane on this GTP tunnel.

The GGSN shall include the Recovery information element into the Create MBMS Context Response if the GGSN is in contact with the SGSN for the first time or the GGSN has restarted recently and the new Restart Counter value has not yet been indicated to the SGSN. The SGSN receiving the Recovery information element shall handle it as when an Echo Response message is received but shall consider the MBMS UE context being created as active if the response indicates successful context activation at the GGSN.

The Charging ID is used to identify all charging records produced in SGSN(s) and the GGSN for this MBMS UE context. The Charging ID is generated by the GGSN and shall be unique within the GGSN.

The Charging Gateway Address is the IP address of the recommended Charging Gateway Functionality to which the SGSN should transfer the Charging Detail Records (CDR) for this MBMS UE Context.

The Alternative Charging Gateway Address IE has a similar purpose as the Charging Gateway Address but enables co-existence of IPv4 and IPv6 stacks in the Ga charging interfaces, without mandating any node to have a dual stack. The format of the optional Alternative Charging Gateway Address information element is the same as the format of the Charging Gateway Address.

When both these addresses are present, the Charging Gateway address IE shall contain the IPv4 address of the Charging Gateway Function and the Alternative Charging Gateway address IE shall contain the IPv6 address of the Charging Gateway Function.

NOTE: The Charging Gateway Address and Alternative Charging Gateway Address both refer to the same Charging Gateway Function.

The optional Private Extension contains vendor or operator specific information.

The MBMS Protocol Configuration Options (MBMS PCO) information element may be included in the response when the GGSN provides the MS with MBMS specific parameters. The SGSN includes this IE in the Activate MBMS Context Accept message if the associated Create MBMS Context Response message from the GGSN includes MBMS protocol configuration options. The SGSN shall copy the content of this IE transparently from the content of the MBMS PCO IE in the Create MBMS Context Response message.

Table 7.5A.6: Information Elements in a Create MBMS Context Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
Charging ID	Conditional	7.7.26
GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Alternative GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Charging Gateway Address	Optional	7.7.44
Alternative Charging Gateway Address	Optional	7.7.44
MBMS Protocol Configuration Options	Optional	7.7.58
Private Extension	Optional	7.7.46

7.5A.1.7 Update MBMS Context Request

An Update MBMS Context Request message shall be sent from an SGSN to a GGSN as part of the GPRS inter-SGSN Routeing Area Update procedure, to redistribute contexts due to load sharing or as part of the inter-system intra-SGSN update procedure i.e. UE transitioning between UTRAN and GERAN A/Gb mode (and vice versa) on the same SGSN. For the inter‑SGSN Routeing Area Update procedure -the message shall be sent by the new SGSN. The GGSN shall update the MBMS UE context fields accordingly.

The Enhanced NSAPI information element together with the Tunnel Endpoint Identifier in the GTP header unambiguously identifies a MBMS UE Context in the GGSN.

The Tunnel Endpoint Identifier Control Plane field specifies a downlink Tunnel Endpoint Identifier Control Plane messages which is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink control plane messages that are related to the requested PDP context.

The SGSN shall include an SGSN Address for control plane, which may differ from that provided by the underlying network service (e.g. IP).

If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from the old SGSN, it shall include IPv4 addresses in the fields SGSN Address for Control Plane and IPv6 addresses in the fields Alternative SGSN Address for Control Plane. Otherwise, an IPv4/IPv6 capable SGSN shall use only SGSN IPv6 addresses if it has GGSN IPv6 addresses available. If the GGSN supports IPv6 below GTP, it shall store and use the IPv6 SGSN addresses for communication with the SGSN and ignore the IPv4 SGSN addresses. If the GGSN supports only IPv4 below GTP, it shall store and use the IPv4 SGSN addresses for communication with the SGSN and ignore the IPv6 SGSN addresses. When active contexts are being redistributed due to load sharing, G-PDUs that are in transit across the Gn-interface are in an undetermined state and may be lost.

The SGSN shall include a Recovery information element into the Update MBMS Context Request if the SGSN is in contact with the GGSN for the very first time or if the SGSN has restarted recently and the new Restart Counter value has not yet been indicated to the GGSN. The GGSN that receives a Recovery information element in the Update MBMS Context Request message element shall handle it in the same way as when receiving an Echo Response message. The Update PDP Context Request message shall be considered as a valid update request for the MBMS UE context indicated in the message.

The SGSN shall include Trace Reference, Trace Type, Trigger Id, OMC Identity and Additional Trace Info in the message if GGSN trace is activated while the MBMS UE context is active. The SGSN shall copy Trace Reference, Trace Type, OMC Identity and Additional Trace Info from the trace request received from the HLR or OMC and the Trace Activity Control shall be set to Trace Activation.

If SGSN deactivates the Trace Session to GGSN, the SGSN shall include the Additional Trace Info in the message and the Trace Activity Control shall be set to Trace Deactivation.

If BM-SC trace is to be activated in the BM-SC (via the GGSN), the SGSN shall include Additional MBMS Trace Info in the message. The SGSN shall populate the Additional BM-SC Trace Info IE with the values of the relevant parameters included in the trace request received from the HLR or OMC, and the Trace Activity Control For BM-SC value shall be set to Trace Activation.

If the SGSN deactivates the Trace Session to the BM-SC, then the SGSN shall include the Additional MBMS Trace Info in the message and the Trace Activity Control For BM-SC value shall be set to Trace Deactivation.

If Additional Trace Info and Additional MBMS Trace Info are both included within the message, the values of Trace Reference2 and Trace Recording Session Reference shall be the same in each IE.

For more detailed description of Trace Session activation/deactivation procedures see 3GPP TS 32.422 [31]

For SGSN and GGSN trace record description see 3GPP TS 32.423 [32]

The SGSN shall include the Routeing Area Identity (RAI) of the SGSN where the UE is registered. The MCC and MNC components shall be populated with the MCC and MNC, respectively, of the SGSN where the UE is registered. The LAC and RAC components shall be populated by the SGSN with the value of "FFFE" and "FF", respectively. See one exception to this rule below in shared GERAN and UTRAN networks.

The SGSN shall include the User Location Information IE, RAT Type IE and MS Time Zone IE if they are available (see clause 15.1.1a of 3GPP TS 23.060 [4] for more information). If the User Location Information IE is included then the SGSN shall include the CGI or SAI in the "Geographic Location" field depending on whether the MS is in a cell or a service area respectively.

In shared networks,

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.7: Information Elements in an Update MBMS Context Request

Information element	Presence requirement	Reference
Routeing Area Identity (RAI)	Mandatory	7.7.3
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
Trace Reference	Optional	7.7.24
Trace Type	Optional	7.7.25
SGSN Address for Control Plane	Mandatory	GSN Address 7.7.32
Alternative SGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Trigger Id	Optional	7.7.41
OMC Identity	Optional	7.7.42
RAT Type	Optional	7.7.50
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
Additional Trace Info	Optional	7.7.62
Enhanced NSAPI	Mandatory	7.7.67
Additional MBMS Trace Info	Optional	7.7.68
Private Extension	Optional	7.7.46

7.5A.1.8 Update MBMS Context Response

The message shall be sent from a GGSN node to a SGSN node as a response of an Update MBMS Context Request.

If the SGSN receives an Update MBMS Context Response with a Cause value other than "Request accepted", it shall abort the update of the MBMS UE context.

If the SGSN receives an Update MBMS Context Response with a Cause value "Non-existent", it shall delete the MBMS UE Context.

Only the Cause information element and optionally the Recovery information element shall be included in the response if the Cause contains another value than "Request accepted".

Possible Cause values are:

– "Request Accepted".

– "Non-existent".

– "Service not supported".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

The Tunnel Endpoint Identifier Control Plane field specifies an uplink Tunnel Endpoint Identifier Control Plane messages which is chosen by the GGSN. The SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent uplink control plane messages which are related to the requested MBMS UE context.

The GGSN shall also include a GGSN address for control plane, which shall not differ from that provided at MBMS UE context setup time and shall remain unchanged for the lifetime of the MBMS UE context. If the Update MBMS Context Request received from the SGSN included IPv6 SGSN addresses, an IPv4/IPv6 capable GGSN shall include an IPv6 address in the field GGSN Address for Control Plane and a corresponding IPv4 address in the field Alternative GGSN Address for Control Plane. If SGSN included only an IPv4 SGSN address in the request, IPv4/IPv6 capable GGSN shall include IPv4 address for Control plane in the field GGSN Address for Control Plane and IPv6 address for Control plane in the field Alternative GGSN Address for Control Plane.

The GGSN Address for control plane shall be included if the Cause contains the value "Request accepted". The Alternative GGSN Address shall be included if the GGSN supports IPv6 below GTP and the Cause contains the value "Request accepted".

The GGSN shall include the Recovery information element into the Update MBMS Context Response if the GGSN is in contact with the SGSN for the first time or if the GGSN has restarted recently and the new Restart Counter value has not yet been indicated to the SGSN. The SGSN receiving the Recovery information element shall handle it as when an Echo Response message is received but shall consider the MBMS UE context as updated and active if the response cause indicates a successful operation at the GGSN.

The Charging ID is used to identify all charging records produced in SGSN(s) and the GGSN for this MBMS UE context. The Charging ID has been previously generated by the GGSN and is unique for this MBMS UE context. If an inter-SGSN routing area update occurs, it is transferred to the new SGSN as part of each active MBMS UE context. This information element shall be included if the Cause contains the value "Request accepted".

The Charging Gateway Address is the IP address of the recommended Charging Gateway Functionality to which the SGSN should transfer the Charging Detail Records (CDR) for this MBMS UE Context.

NOTE: The Charging Gateway Address and Alternative Charging Gateway Address both refer to the same Charging Gateway Function.

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.8: Information Elements in an Update MBMS Context Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
Charging ID	Conditional	7.7.26
GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Alternative GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Charging Gateway Address	Optional	7.7.44
Alternative Charging Gateway Address	Optional	7.7.44
Private Extension	Optional	7.7.46

7.5A.1.9 Delete MBMS Context Request

A Delete MBMS Context Request can be sent either from a SGSN node to a GGSN node as part of the GPRS Detach procedure or from the GGSN node to the SGSN node as part of the MBMS UE Context Deactivation procedure initiated by the UE by the sending of an IGMP/MLD leave message. A Delete MBMS Context Request shall also be sent from an SGSN node to a GGSN node at Inter SGSN change if the new SGSN does not support MBMS. If the deactivation of the MBMS UE context results in no more users being registered within the GSN for the Multicast Service, the SGSN may initiate the MBMS deregistration procedure. (For further information see 3GPP TS 23.246 [26]).

A GSN shall be prepared to receive a Delete MBMS Context Request at any time and shall always reply regardless if the MBMS UE context exists or not. If any collision occurs, the Delete MBMS Context Request takes precedence over any other Tunnel Management message.

An SGSN initiated Delete MBMS Context Request shall only include the Enhanced NSAPI which shall uniquely identify the MBMS UE context to be deactivated and the optional Private Extension contains vendor or operator specific information.

If the MBMS UE context to be deactivated (indicated by the multicast address within the IGMP/MLD leave message) resides on the same GGSN as which the IGMP/MLD leave message is received, a GGSN initiated Delete MBMS Context Request shall only include the Enhanced NSAPI which shall uniquely identify the MBMS UE context to be deactivated and the optional Private Extension contains vendor or operator specific information.

If the MBMS UE context to be deactivated (indicated by the multicast address within the IGMP/MLD leave message) resides on a different GGSN from that which the IGMP/MLD leave message is received, a GGSN initiated Delete MBMS Context Request shall contain the IMSI, TEID Control Plane, End User Address, APN, the optional Private Extension contains vendor or operator specific information. This message will then trigger the SGSN to send a SGSN initiated Delete MBMS Context Request for the identified MBMS UE context toward the GGSN hosting the MBMS UE context.

The IMSI shall unambiguously identify the user. The End User Address information element contains the PDP type and IP Multicast PDP address that the GGSN shall request the SGSN to de-activate. The IP multicast address shall be the one included by the UE in the Leave request.

The Access Point Name information element further identifies the access point of packet data network that the SGSN will use to identify which MBMS UE context to deactivate. The APN and End User Address information element shall uniquely identify the MBMS service.

In the MS to GGSN direction, the SGSN includes the MBMS Protocol Configuration Options (MBMS PCO) information element in the request if the MS wishes to provide the GGSN with MBMS specific parameters. The SGSN includes this IE in the Delete MBMS Context Request message if the associated message from the MS includes MBMS protocol configuration options. The SGSN shall copy the content of this IE transparently from the MBMS PCO IE in the Deactivate PDP Context Request message.

In the GGSN to MS direction, the GGSN includes the MBMS Protocol Configuration Options (MBMS PCO) information element in the request if the GGSN wishes to provide the MS with MBMS specific parameters. The SGSN includes this IE in the Deactivate PDP Context Request message if the associated Delete MBMS Context Request message from the GGSN includes MBMS protocol configuration options. The SGSN shall copy the content of this IE transparently from the MBMS PCO IE in the Delete MBMS Context Request message.

Table 7.5A.9: Information Elements in a Delete MBMS Context Request

Information element	Presence requirement	Reference
IMSI	Conditional	7.7.2
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
End User Address	Conditional	7.7.27
Access Point Name	Conditional	7.7.30
MBMS Protocol Configuration Options	Optional	7.7.58
Enhanced NSAPI	Conditional	7.7.67
Private Extension	Optional	7.7.46

7.5A.1.10 Delete MBMS Context Response

The message shall be sent as a response to a Delete MBMS Context Request.

A GSN shall ignore a Delete MBMS Context Response for a non-existing MBMS UE context.

If a GSN receives a Delete MBMS Context Request message for a non existing MBMS UE context, it shall send back to the source of the message a Delete MBMS Context Response message with cause value "Non existent". The TEID value used in the response message shall be zero.

Possible Cause values are:

– "Request Accepted".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE Incorrect".

– "Invalid message format".

– "Non existent".

If the received Delete MBMS Context Response contains a cause value other than "Request accepted" and "Non Existent", the PDP context shall be kept active.

The optional Private Extension contains vendor or operator specific information.

In the GGSN to MS direction, the GGSN includes the MBMS Protocol Configuration Options (MBMS PCO) information element in the response if the GGSN wishes to provide the MS with MBMS specific parameters. The SGSN includes this IE in the Deactivate PDP Context Accept message if the associated Delete MBMS Context Response message from the GGSN includes MBMS protocol configuration options. The SGSN shall copy the content of the IE transparently from the MBMS PCO IE in the Delete MBMS Context Response message.

In the MS to GGSN direction, the SGSN includes the MBMS Protocol Configuration Options (MBMS PCO) information element in the response if the MS wishes to provide the GGSN with MBMS specific parameters. The SGSN includes this IE in the Delete MBMS Context Response message if the associated Deactivate PDP Context Accept message from the MS includes MBMS protocol configuration options. The SGSN shall copy the content of the IE transparently from the MBMS PCO IE in the Deactivate PDP Context Accept message.

Table 7.5A.10: Information Elements in a Delete MBMS Context Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
MBMS Protocol Configuration Options	Optional	7.7.58
Private Extension	Optional	7.7.46

7.5A.2 Service Specific MBMS Messages

7.5A.2.1 MBMS Registration Request

An MBMS Registration Request shall be sent by an SGSN in order to request registration with a GGSN and receive future session attributes and data for a particular MBMS service from the GGSN. This message shall be sent when the first MBMS UE context for a particular MBMS service is created in the SGSN, or when an MBMS registration Request is received from an RNC that is registering for a particular MBMS service that is not present in the SGSN. A successful registration causes the creation of an MBMS Bearer Context in the SGSN, and GGSN. (see 3GPP TS 23.246 [26])

The End User Address information element contains the PDP type and IP Multicast PDP address of the MBMS service for which the SGSN is registering. The Access Point Name information element identifies the access point of packet data network that the GGSN requires to connect to receive the required MBMS service. The APN and End User Address information element shall uniquely identify the MBMS service.

If the MBMS Registration Request is being sent as a result of the first MBMS UE context being created on the SGSN, the SGSN shall copy the End User Address and APN information from the MBMS UE Context. If the MBMS Registration Request is received from an RNC that is registering for a particular MBMS service that is not established in SGSN, the SGSN shall copy the End User Address and APN information from the corresponding message sent by the RNC.

The selection of the GGSN will be dependent on the reason for the registration request. If the MBMS Registration Request is being sent due to the first MBMS UE context for a particular service, the SGSN shall send the MBMS registration Request to the GGSN address identified in the MBMS UE context (APN was resolved by SGSN at MBMS UE context establishment). Alternatively, if the MBMS Registration Request is being sent due to an MBMS registration Request that received from an RNC which is registering for a particular MBMS service that is not established in the SGSN, the GGSN shall be selected via APN resolution. If the registration process is successful, the SGSN shall keep this address for de-registration procedures.

The Tunnel Endpoint Identifier Control Plane field specifies a downlink Tunnel Endpoint Identifier for control plane messages that is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink control plane messages which are related to the MBMS Bearer context. If the SGSN has already confirmed successful assignment of its Tunnel Endpoint Identifier Control Plane, this field shall not be present.

If SGSN has not established control plane tunnel to GGSN for the given MBMS service, the SGSN shall include an SGSN Address for Control Plane, which may differ from that provided by the underlying network service (e.g. IP). The GGSN shall store the SGSN Address and use it when sending control plane messages on this GTP tunnel for the MBMS Bearer context. IPv4/IPv6 capable SGSN shall include IPv6 address in SGSN Address for Control Plane field and IPv4 address in Alternative SGSN Address for Control Plane field. IPv4 only capable SGSN shall not include Alternative SGSN Address for Control Plane field.

Table 7.5A.2.1: Information Elements in a MBMS Registration Request

Information element	Presence requirement	Reference
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
SGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Alternative SGSN Address for Control Plane	Optional	GSN Address 7.7.32
Private Extension	Optional	7.7.46

7.5A.2.2 MBMS Registration Response

An MBMS Registration Response is sent by an GGSN in response to a received MBMS Registration Request. If the GGSN is already registered for the indicated MBMS service, the GGSN can immediately send back this response, adding the SGSN to its list of registered nodes for that MBMS service. If the GGSN is not registered for the indicated MBMS service it shall register with the BM-SC as defined in 3GPP TS29.061 [27].

The Cause value indicates if a registration has been successful in the GGSN. An MBMS Bearer Context has not been created in the GGSN if the Cause differs from "Request accepted". Possible Cause values are:

– "Request Accepted".

– "No resources available".

– "No memory is available".

– "Missing or unknown APN".

– "Unknown PDP address or PDP type".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

The Temporary Mobile Group Identity information element shall be the TMGI allocated by the BM-SC.

The Tunnel Endpoint Identifier Control Plane field specifies an uplink Tunnel Endpoint Identifier for control plane messages that is chosen by the GGSN. The SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent uplink control plane messages which are related to the MBMS Bearer context. If the GGSN has already confirmed successful assignment of its Tunnel Endpoint Identifier Control Plane, this field shall not be present.

If GGSN has not established control plane tunnel to SGSN for the given MBMS service, the GGSN shall include a GGSN Address for control plane, which may differ from that provided by the underlying network service (e.g. IP).

If the GGSN has received an IPv6 address in the SGSN Address for the Control Plane field with MBMS Registration Request message, then an IPv6 capable GGSN shall include its own IPv6 address in the GGSN Address for the Control Plane field of the response message.

If the SGSN has provided its own IPv4 address, an IPv4 only capable GGSN shall include its own IPv4 address in the GGSN Address for the Control Plane field of the response message.

The SGSN shall store the GGSN Address and use it when sending control plane messages on this GTP tunnel for the MBMS Bearer context.

"No resources available" indicates that not enough resources are available within the network to allow the MBMS Context to be created. "Missing or unknown APN" indicates e.g. when the GGSN does not support the Access Point Name. "Unknown PDP address or PDP type" indicates when the GGSN does not support the PDP type or the PDP address. Within the scope of MBMS message, an unknown PDP address is considered to be unknown mulitcast address / service.

Required MBMS bearer capabilities shall contain the minimum bearer capabilities the UE needs to support, as received from the BM‑SC.

Table 7.5A.2.2: Information Elements in an MBMS Registration Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Temporary Mobile Group Identity (TMGI)	Conditional	7.7.56
Required MBMS bearer capabilities	Conditional	7.7.76
Private Extension	Optional	7.7.46

7.5A.2.3 MBMS De-registration Request

An MBMS De-registration Request shall be sent by an SGSN in order to inform an GGSN that it no longer requires to receive session attributes and data for a particular MBMS service. This message shall be sent when the last MBMS UE context for a particular MBMS service is deleted in the SGSN, or when an MBMS De-registration Request is received from an RNC that is de-registering for a particular MBMS service that is currently established in the SGSN that has no MBMS UE context associated. This message is also sent by a GGSN to an SGSN as a part of the BM-SC initiated MBMS De-Registration procedure.

The End User Address information element contains the PDP type and IP Multicast PDP address of the MBMS service for which the SGSN is de-registering. The Access Point Name information element identifies the access point of packet data network that the sending GSN requires to connect to de-register the MBMS service, it this is the last SGSN that was registered for the MBMS service or if the MBMS De-Registration was initiated by the BM-SC.

If the MBMS De-registration Request is being sent as a result of the last MBMS UE context being deleted on the SGSN, the SGSN shall copy the End User Address and APN information from the MBMS UE Context. If the MBMS De-registration Request is received from an RNC that is de-registering for a particular MBMS service for which the SGSN has no MBMS UE Contexts, the SGSN shall copy the End User Address and APN information from the corresponding message sent by the RNC. If the MBMS De-Registration was initiated by the BM-SC, the GGSN shall copy the End User Address and APN information from the MBMS UE Context.

When the SGSN sends this message, the selection of the GGSN will be dependent on the reason for the de-registration request. If the MBMS De-registration Request is being sent due to the leaving of the last MBMS UE context for a particular service, the SGSN shall send the MBMS De-registration Request to the GGSN address identified in the MBMS UE context. Alternatively, if the MBMS De-registration Request is being sent due to an MBMS De-registration Request that received from an RNC for which the SGSN has no MBMS UE contexts established, the GGSN shall be selected via the address stored during registration.

Table 7.5A.2.3: Information Elements in a MBMS De-registration Request

Information element	Presence requirement	Reference
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
Private Extension	Optional	7.7.46

7.5A.2.4 MBMS De-Registration Response

An MBMS De-registration Response is sent by an SGSN or a GGSN in response to a received MBMS De-registration Request. When the GGSN sends this message, if the SGSN is the last registered downstream node within the MBMS bearer context of the GGSN, the GGSN shall de-register itself with the BM-SC as defined in 3GPP TS29.061[27].

The Cause value indicates if the de-registration has been successful in the sending GSN. An MBMS Bearer Context has not been created in the sending GSN if the Cause differs from "Request accepted". Possible Cause values are:

– "Request Accepted".

– "Missing or unknown APN".

– "Unknown PDP address or PDP type".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "Non existent"

"Missing or unknown APN" indicates e.g. when the GGSN does not support the Access Point Name. "Unknown PDP address or PDP type" indicates when the GGSN does not support the PDP type or the PDP address. Within the scope of MBMS message, an unknown PDP address is considered to be unknown mulitcast address / service. "Non-existent" indicates a non-existent MBMS UE context.

Table 7.5A.2.4: Information Elements in an MBMS De-registration Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.46

7.5A.2.5 MBMS Session Start Request

An MBMS Session Start Request message shall only ever be sent by the GGSN, and will be triggered by the BM-SC when it is ready to send data for the indicated MBMS service. An MBMS Session Start Request message may also be triggered by an Error Indication from an SGSN for broadcast mode. An MBMS Session Start Request shall trigger the SGSN to setup the necessary MBMS user plane resources and indicate to the RAN to setup the appropriate radio bearers.

The GGSN shall include a Recovery information element into the MBMS Session Start Request if the GGSN is in contact with the SGSN for the very first time or if the GGSN has restarted recently and the new Restart Counter value has not yet been indicated to the SGSN. The SGSN that receives a Recovery information element in the MBMS Session Start Request message element shall handle it in the same way as when receiving an Echo Response message. The Session Start Request message shall be considered as a valid activation request for the MBMS Bearer context included in the message.

The MBMS Session Duration information element indicates the estimated session duration of the MBMS service data transmission. This information is provided by the BM-SC.

The Tunnel Endpoint Identifier Control Plane and GGSN Address for Control Plane shall be included in Broadcast mode. In Multicast mode, the control plane tunnel has already been established at the MBMS Registration.

The GGSN shall include a GGSN Address for control plane, which may differ from that provided by the underlying network service (e.g. IP). The SGSN shall store the GGSN Address and use it when sending control plane messages on this GTP tunnel for the MBMS Bearer context. IPv4/IPv6 capable GGSN shall include IPv6 address in GGSN Address for Control Plane field and IPv4 address in Alternative GGSN Address for Control Plane field. IPv4 only capable GGSN shall not include Alternative GGSN Address for Control Plane field.

The End User Address information element contains the PDP type and IP Multicast PDP address of the MBMS service. The Access Point Name information element identifies the access point of packet data network that the GGSN requires to connect to receive the required MBMS service. The optional MBMS Flow Identifier allows to differentiate the sub-sessions of an MBMS user service providing location-dependent content in broadcast mode. The APN and End User Address and, if present, the MBMS Flow Identifier information elements shall uniquely identify the MBMS bearer context.

The Quality of Service Profile information element shall be the QoS required from the MBMS bearer.

The MBMS Service Type bit of the Common Flags information element contains explicit information whether the MBMS session is for multicast service or for broadcast service. This information is provided by the BM-SC. If the MBMS Service Type bit of the Common Flags information element is set to 0, then the MBMS session is for multicast service. If the MBMS Service Type bit of the Common Flags information element is set to 1, then the MBMS session is for broadcast service.

The MBMS Counting Information bit of the Common Flags information element contains explicit information whether the Counting procedures are applicable for this MBMS session. This information is provided by the BM-SC. If the MBMS Counting Information bit of the Common Flags information element is set to 0, then counting is not applicable for the MBMS session. If the MBMS Counting Information bit of the Common Flags information element is set to 1, then counting is applicable for the MBMS session.

The Temporary Mobile Group Identity information element shall be the TMGI allocated by the BM-SC.

The MBMS Service Area information element indicates the area over which the MBMS service has to be distributed. This information is provided by the BM-SC.

The MBMS Session Identifier and MBMS Session Repetition Number shall be forwarded to the SGSN if they are provided by the BM-SC.

The MBMS Time To Data Transfer shall be forwarded to the SGSN. This information is provided by the BM-SC.

The MBMS 2G/3G Indicator is provided by the BM-SC and informs the SGSN whether the MBMS Session Start Request message shall be forwarded to the BSCs and/or the RNCs.

If MBMS IP multicast distribution is supported, the GGSN shall inform the SGSN that an IP multicast based user plane is available for the MBMS session by sending MBMS IP Multicast Distribution information element. MBMS IP Multicast Distribution IE shall be forwarded by the SGSN to the RNCs.

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.2.5: Information Elements in an MBMS Session Start Request

Information element	Presence requirement	Reference
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Alternative GGSN Address for Control Plane	Optional	GSN Address 7.7.32
Quality of Service Profile	Mandatory	7.7.34
Common Flags	Mandatory	7.7.48
Temporary Mobile Group Identity (TMGI)	Mandatory	7.7.56
MBMS Service Area	Mandatory	7.7.60
MBMS Session Identifier	Optional	7.7.65
MBMS 2G/3G Indicator	Mandatory	7.7.66
MBMS Session Duration	Mandatory	7.7.59
MBMS Session Repetition Number	Optional	7.7.69
MBMS Time To Data Transfer	Mandatory	7.7.70
MBMS Flow Identifier	Optional	7.7.84
MBMS IP Multicast Distribution	Optional	7.7.85
Private Extension	Optional	7.7.46

7.5A.2.6 MBMS Session Start Response

An MBMS Session Start Response is sent by an SGSN in response to a received MBMS Session Start Request. When the GGSN receives a MBMS Session Start Response with the Cause value indicating "Request Accepted", the GGSN shall mark the MBMS Bearer Context as Active, and may start to forward T-PDUs to the SGSN using the indicated TEID and SGSN Address.

The procedure has not been successful if the Cause differs from "Request accepted". Possible Cause values are:

– "Request Accepted".

– "Context not found"

– "No resources available".

– "No memory is available".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "MBMS Bearer Context Superseded".

"No resources available" indicates that not enough resources are available within the network to allow the MBMS Bearer to be created.

"MBMS Bearer Context Superseded" indicates that the SGSN has already established an MBMS bearer plane with another GGSN. The GGSN receiving the MBMS Session Start Response with this cause value shall not request establishment of the bearer plane.

Only the Cause information element shall be included in the response if the Cause contains another value than "Request accepted".

The SGSN shall include the Recovery information element into the MBMS Session Start Response if the SGSN is in contact with the GGSN for the first time or the SGSN has restarted recently and the new Restart Counter value has not yet been indicated to the GGSN. The GGSN receiving the Recovery information element shall handle it as when an Echo Response message is received but shall consider the MBMS Bearer context being activated if the response indicates successful context activation at the SGSN.

The Tunnel Endpoint Identifier for Data (I) field specifies a downlink Tunnel Endpoint Identifier for G-PDUs that is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink G-PDUs which are related to the MBMS Bearer context.

The SGSN shall include an SGSN address for user traffic, which may differ from that provided by the underlying network service (e.g. IP). The GGSN shall store these SGSN Addresses and use them when G-PDUs to the SGSN for the MBMS Bearer context. IPv4/IPv6 capable SGSN shall include IPv6 address in SGSN Address for user traffic field and IPv4 address in Alternative SGSN Address for user traffic field. IPv4 only capable SGSN shall not include Alternative SGSN Address for user traffic field.

The Tunnel Endpoint Identifier Control Plane and SGSN Address for Control Plane shall be included in Broadcast mode. In Multicast mode, the control plane tunnel has already been established at the MBMS Registration.

The SGSN shall include an SGSN Address for Control Plane, which may differ from that provided by the underlying network service (e.g. IP).

If SGSN has received IPv6 address in GGSN Address for Control Plane field with MBMS Session Start Request message, then IPv6 capable SGSN shall include own IPv6 address in SGSN Address for Control Plane field of the response message.

If the SGSN has provided its own IPv4 address, IPv4 only capable SGSN shall include own IPv4 address in SGSN Address for Control Plane field of the response message.

The GGSN shall store the SGSN Address and use it when sending control plane messages on this GTP tunnel for the MBMS Bearer context.

The MBMS Distribution Acknowledgement field is used by the SGSN to indicate to the GGSN if a) all RNCs have accepted IP multicast distribution, b) no RNCs have accepted IP multicast distribution, or c) some RNCs have accepted IP multicast distribution.

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.2.6: Information Elements in MBMS Session Start Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Data I	Conditional	7.7.13
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
SGSN Address for Control Plane	Conditional	GSN Address 7.7.32
SGSN Address for user traffic	Conditional	GSN Address 7.7.32
Alternative SGSN Address for user traffic	Optional	GSN Address 7.7.32
MBMS Distribution Acknowledgement	Optional	7.7.86
Private Extension	Optional	7.7.46

7.5A.2.7 MBMS Session Stop Request

An MBMS Session Stop Request message shall be sent by the GGSN, when triggered by the BM-SC when it no longer has any data to be sent for the indicated MBMS service. An MBMS Session Stop Request shall trigger the SGSN to teardown the MBMS user plane resources and indicate to the RAN to teardown the Radio bearers associated with the MBMS Service.

An MBMS Session Stop Request message may also be sent by the SGSN, when the SGSN no longer will receive or process the indicated MBMS broadcast service. An MBMS Session Stop Request shall trigger the GGSN to remove the SGSN from the associated MBMS broadcast Service.

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.2.7: Information Elements in an MBMS Session Stop Request

Information element	Presence requirement	Reference
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
MBMS Flow Identifier	Optional	7.7.84
Private Extension	Optional	7.7.46

7.5A.2.8 MBMS Session Stop Response

An MBMS Session Stop Response is sent by an GSN in response to a received MBMS Session Stop Request. When a GSN receives an MBMS Session Stop Response with the Cause value indicating "Request Accepted", the GSN shall mark the MBMS Bearer Context as Standby, indicating no user plane resource are setup, and will no longer forward T-PDU for this MBMS context.

The procedure has not been successful if the Cause differs from "Request accepted". Possible Cause values are:

– "Request Accepted".

– "Context not found"

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

Only the Cause information element shall be included in the response if the Cause contains another value than "Request accepted".

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.2.8: Information Elements in MBMS Session Stop Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.46

7.5A.2.9 MBMS Session Update Request

The MBMS Session Update Request message is sent by a GGSN node to SGSN nodes where the MBMS Broadcast Session needs to be updated.. The GGSN sends the message, triggered by the BM-SC when the service area for an ongoing MBMS Broadcast service session shall be modified.

The GGSN may include Tunnel Endpoint Identifier Control Plane field, which may differ from one provided to SGSN by MBMS Session Start Request message (broadcast) or by MBMS Registration Response message (multicast).

The GGSN may include GGSN Address for control plane, which may differ from that provided by the underlying network service (e.g. IP).

The MBMS Session Duration information element indicates the estimated session duration of the MBMS service data transmission. This information is provided by the BM-SC.

The End User Address information element contains the PDP type and IP Multicast PDP address of the MBMS service. The Access Point Name information element identifies the access point of packet data network that the GGSN requires to connect to receive the required MBMS service. The optional MBMS Flow Identifier allows to differentiate the sub-sessions of an MBMS user service providing location-dependent content in broadcast mode. The APN and End User Address, if present, the MBMS Flow Identifier information elements shall uniquely identify the MBMS bearer context.

The Temporary Mobile Group Identity information element shall be the TMGI allocated by the BM-SC.

The MBMS Service Area information element indicates the area over which the MBMS service has to be distributed. This information is provided by the BM-SC.

The MBMS Session Identifier and MBMS Session Repetition Number shall be forwarded to the SGSN if they are provided by the BM-SC.

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.2.9: Information Elements in an MBMS Session Update Request

Information element	Presence requirement	Reference
Tunnel Endpoint Identifier Control Plane	Optional	7.7.14
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
GGSN Address for Control Plane	Optional	GSN Address 7.7.32
Temporary Mobile Group Identity (TMGI)	Mandatory	7.7.56
MBMS Session Duration	Mandatory	7.7.59
MBMS Service Area	Mandatory	7.7.60
MBMS Session Identifier	Optional	7.7.65
MBMS Session Repetition Number	Optional	7.7.69
MBMS Flow Identifier	Optional	7.7.84
Private Extension	Optional	7.7.46

7.5A.2.10 MBMS Session Update Response

An MBMS Session Update Response is sent by SGSN in response to a received MBMS Session Update Request.

The procedure has not been successful if the Cause differs from "Request accepted". Possible Cause values are:

– "Request Accepted".

– "Context not found"

– "No resources available".

– "No memory is available".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

"No resources available" indicates that not enough resources are available within the network to allow the MBMS Bearer to be updated.

Only the Cause information element shall be included in the response if the Cause contains another value than "Request accepted".

The SGSN may include Tunnel Endpoint Identifier Data field, which may differ from one provided to GGSN by MBMS Session Start Response message.

The SGSN may include Tunnel Endpoint Identifier Control Plane field, which may differ from one provided to GGSN by MBMS Session Start Response message (broadcast) or MBMS Registration Request message (multicast).

The SGSN may include SGSN Address for Data I, which may differ from one provided to GGSN by MBMS Session Start Response message.

The SGSN may include SGSN Address for control plane, which may differ from that provided by the underlying network service (e.g. IP).

The optional Private Extension contains vendor or operator specific information.

Table 7.5A.2.10: Information Elements in MBMS Session Update Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Tunnel Endpoint Identifier Data I	Optional	7.7.13
Tunnel Endpoint Identifier Control Plane	Optional	7.7.14
SGSN Address for Data I	Optional	GSN Address 7.7.32
SGSN Address for Control Plane	Optional	GSN Address 7.7.32
Private Extension	Optional	7.7.46

7.5B.1 MS Info Change Reporting Messages

7.5B.1.0 General

The Location Change Reporting messages defined here are control plane messages that are used in accordance with 3GPP TS 23.060 [4], clause 15.1.1a, and 3GPP TS 23.203 [39].

An SGSN conveys its support of both the MS Info Change Notification Request and MS Info Change Notification Response messages for Location Change Reportng mechanism using the GTP extension header defined in clause 6.1.5.

An SGSN conveys its support of both the MS Info Change Notification Request and MS Info Change Notification Response messages for CSG Information Change Reporting mechanism using the CCRSI flag defined in the Extended Common flags IE in clause 7.7.93.

7.5B.1.1 MS Info Change Notification Request

This message is sent by an SGSN to a GGSN when the GGSN has requested to receive the User Location Information (ULI) change notifications or when the GGSN has requested to receive User CSG Information (UCI) change notifications.

The SGSN and GGSN shall support the MS Info Change Notification procedure per PDN connection.

The SGSN may be configured to defer the reporting of ULI change until a RAB or user plane is established. In that case:

– the SGSN shall not send an MS Info Change Notification Request during a RAU without SGSN change or a Service Request (for UTRAN) procedures not requesting to activate data radio bearer(s);

– for GERAN, the SGSN shall defer the reporting of ULI changes until receipt of an uplink LLC PDU for user data or any valid LLC frame serving as a paging response.

– the SGSN shall send an MS Info Change Notification Request message in the following cases to report a change of User Location Information which occured during a previous RAU procedure without SGSN change but which has not been reported yet to the GGSN:

– during a Service Request procedure to establish data radio bearers for the corresponding PDP context for a UE in UTRAN, when not establishing a direct GTP-U tunnel between the GGSN and the RNC;

– when the SGSN receives an uplink LLC PDU for user data or any valid LLC frame serving as a paging response for a UE in GERAN.

The SGSN shall report ULI changes as soon as detected if it is not configured to defer the reporting of ULI changes until a RAB or user plane is established, or if a RAB or user plane is established.

The SGSN shall set the header TEID value to that of the GGSN’s Control Plane TEID of the corresponding PDN connection. However the GGSN shall be prepared to receive this message in which the header TEID value is set to zero from an SGSN implementation conforming to earlier versions of this specification. When that is the case, the GGSN shall identify the PDN connection context based on the included Linked NSAPI, IMSI, and/or IMEI IEs if the Linked NSAPI is present in the message, or the subscriber context based on the IMSI and/or IMEI IEs if the Linked NSAPI is not present in the message.

The GGSN shall consider that the SGSN supports the MS Info Change Notification procedure per PDN connection upon receipt of an MS Info Change Notification Request with the Linked NSAPI IE or with a non-zero TEID (with or without the Linked NSAPI IE). The GGSN shall otherwise consider that the SGSN supports the MS Info Change notification procedure per UE.

The SGSN may include the Linked NSAPI IE, with the NSAPI assigned to any of the already activated PDP context of the PDN connection.

NOTE: A GGSN complying with an earlier version of the specification can check the presence of this IE for determining whether the SGSN supports the message at the PDN connection granularity, despite receiving a non null TEID.

If the MS is emergency attached and the MS is UICCless (i.e. the mobile terminal cannot obtain IMSI at all) or the IMSI is unauthenticated, the International Mobile Equipment Identity (IMEI) shall be included by the SGSN.

The Unauthenticated IMSI bit field shall be set to 1 if the IMSI present in the message is not authenticated and is for an emergency attached MS.

The SGSN shall include the RAT Type IE and shall set its value appropriately, respective of which access technology is current being used by the MS. The GGSN may ignore RAT Type as the SGSN always informs the GGSN about RAT Type change with the Update PDP Context Request message.

The SGSN shall include the User Location Information IE if the MS is located in a RAT Type of GERAN, UTRAN or GAN and shall include the CGI, SAI or RAI in the "Geographic Location" field depending on whether the MS is in a cell, a service or a routing area respectively. The SGSN may optionally include the User Location Information IE for other RAT Types.

In shared networks,

– when the message is sent from the VPLMN to the HPLMN, the PLMN ID that is communicated in the User Location Information IE and User CSG Information IE shall be that of the selected Core Network Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting UEs. As an exception, based on inter-operator roaming/sharing agreement, if the information on whether the UE is a supporting or non-supporting UE is available, the PLMN ID that is communicated to the HPLMN for non-supported UEs shall be the Common PLMN ID. See clause 4.4 of 3GPP TS 23.251 [35];

The SGSN shall include the User CSG Information IE if the MS is located in the CSG cell or the hybrid cell and the GGSN has requested to receive the User CSG Information (UCI).

The optional Private Extension contains vendor or operator specific information.

Table 7.5B.1.1.1: Information Elements in MS Info Change Notification Request

Information element	Presence requirement	Reference
IMSI	Conditional	7.7.2
Linked NSAPI	Optional	7.7.17
RAT Type	Mandatory	7.7.50
User Location Information	Conditional	7.7.51
IMEI(SV)	Conditional	7.7.53
Extended Common Flags	Optional	7.7.93
User CSG Information	Optional	7.7.94
Private Extension	Optional	7.7.46

7.5B.1.2 MS Info Change Notification Response

This message is sent by a GGSN to an SGSN to acknowledge the receipt of a Location Change Notification Request.

The GGSN shall set the header TEID value to that of the SGSN’s Control Plane TEID. However the SGSN shall be prepared to receive this message in which the header TEID value is set to zero from an GGSN implementation conforming to earlier versions of this specification. When that is the case, the SGSN shall identify the PDN connection context based on the included Linked NSAPI, IMSI, and/or IMEI IEs if the Linked NSAPI is present in the message, or the subscriber context based on the IMSI and/or IMEI IEs if the Linked NSAPI is not present in the message.

The SGSN shall consider that the GGSN supports the MS Info Change Notification procedure per PDN connection upon receipt of an MS Info Change Notification Response with the Linked NSAPI IE or with a non-zero TEID (with or without the Linked NSAPI IE). The SGSN shall otherwise consider that the GGSN supports the MS Info Change notification procedure per UE.

The GGSN shall include the same Linked NSAPI value if the Linked NSAPI IE is received in the MS Info Change Notification Request message.

NOTE: An SGSN complying with an earlier version of the specification determines, based on the presence or absence of the Linked NSAPI IE in an MS Info Change Notification Response, whether the GGSN supports the MS Info Change Notification Request per PDN connection or per UE.

The GGSN shall include the IMSI IE if the IMSI IE is received in the MS Info Change Notification Request message.

The GGSN shall include the International Mobile Equipment Identity (IMEI) IE if the International Mobile Equipment Identity (IMEI) IE is received in the MS Info Change Notification Request message.

If an SGSN receives an MS Info Change Nofitication Response with an unknown IMSI/IMEI, then the message shall be silently discarded and no further processing of the IEs shall continue i.e. the Cause value is not processed.

The Cause value indicates whether or not the MS Info Change Notification Request was received correctly. Possible Cause values are:

– "Request accepted"

– "Invalid message format"

– "IMSI/IMEI not known"

– "Mandatory IE incorrect"

– "Mandatory IE missing"

– "Optional IE incorrect"

– "System failure"

If the received MS Info Change Notification Response contains a Cause value of "IMSI/IMEI not known", then the MS Info Change Reporting mechanism shall be stopped in the SGSN for all PDP Contexts associated with the IMSI (or the IMEI if the MS is emergency attached and the MS is UICCless or the MS is emergency attached but the IMSI is not authenticated) received and the GGSN from which the response was received. The SGSN shall then locally delete all of these PDP Contexts associated with the GGSN and release all associated resources.

For error handling if the received MS Info Change Notification Response contains a Cause value other than "Request accepted", "IMSI/IMEI not known" and "System failure", refer to clause 11.

If the MS Info Change Reporting mechanism is to be stopped in the SGSN for the PDN connection identified by the Linked NSAPI IE (when the Linked NSAPI IE is present in the message) or for all the subscriber’s PDN connections towards this GGSN (when the Linked NSAPI IE is not present in the message), then the GGSN shall include the MS Info Change Reporting Action IE in the message and shall set the value of the Action field appropriately.

If the CSG Information Reporting mechanism is to be stopped for this subscriber in the SGSN, then the GGSN shall include the CSG Information Reporting Action IE in the message and shall set the value of the Action field appropriately.

The optional Private Extension contains vendor or operator specific information.

Table 7.5B.1.2.1: Information Elements in MS Info Change Notification Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
IMSI	Conditional	7.7.2
Linked NSAPI	Optional	7.7.17
IMEI(SV)	Conditional	7.7.53
MS Info Change Reporting Action	Optional	7.7.80
CSG Information Reporting Action	Optional	7.7.95
Private Extension	Optional	7.7.46