20 Usage of Diameter on SGmb interface

29.0613GPPInterworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)Release 17TS

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

20.1 General

Signalling between MBMS GW and BM-SC is exchanged at SGmb reference point.

The MBMS GW uses the SGmb interface:

– to receive indication of session start, session update and session stop messages, which shall cause the MBMS GW, MME/SGSN and E-UTRAN/UTRAN to set up/tear down the appropriate resources for the service. For further details, see 3GPP TS 23.246 [65];

– to enable the BM-SC and MBMS GW to detect an SGmb path failure or the restart of the peer MBMS node. For further details, see 3GPP TS 23.007 [104].

– to enable the BM-SC to transfer the M1 interface information of local MBMS information. For further details, see 3GPP TS 23.285 [112].

NOTE: The localized MBMS architecture refers to Annex B of 3GPP TS 23.285 [112].

The SGmb application is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The SGmb application identifier value assigned by IANA is 16777292.

The SGmb application identifier value shall be included in the Auth-Application-Id AVP.

The BM-SC and the MBMS GW shall advertise the support of the SGmb application by including the value of the application identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in IETF RFC 6733 [111], i.e. as part of the Vendor-Specific-Application-Id AVP. The Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands are specified in the Diameter Base Protocol.

20.2 MBMS session start / update/ stop

The MBMS session start shall be used by the BM-SC to trigger the bearer resource establishment and announce the arrival of data for a MBMS bearer service (along with the attributes of the data to be delivered e.g. QoS, MBMS service area, or MBMS-Cell-List) to every MBMS GW that will deliver the MBMS bearer service.

The MBMS session update shall be used by the BM-SC to trigger the update of MBMS session attributes in the affected MBMS GWs. The attributes that can be modified are the MBMS service area, the MBMS-Cell-List and the list of MBMS control plane nodes (MMEs, SGSNs).

The MBMS session stop shall be used by the BM-SC to indicate the end of the data stream for an MBMS bearer service to every MBMS GW that has been delivering the MBMS bearer service.

20.2A MBMS heartbeat

The MBMS heartbeat procedure enables the BM-SC and MBMS GW to detect an SGmb path failure or the restart of the peer MBMS node, as specified in 3GPP TS 23.007 [104].

The use of this procedure shall be negotiated between the BM-SC and MBMS GW upon contacting the peer node for the first time.

NOTE: The MBMS Heartbeat procedure however applies per (BM-SC, MBMS GW) pair, i.e. not per MBMS session.

When this procedure is applied, the BM-SC and MBMS GW shall detect an SGmb path failure or the restart of the peer MBMS node as specified in clause 29 of 3GPP TS 23.007 [104].

The BM-SC and MBMS GW shall maintain a local restart counter which shall be incremented monotonically whenever the MBMS node restarts with loss of previous states.

The MBMS heartbeat message shall include the Restart Counter AVP set to the local restart counter of the sending node. The Restart-Counter AVP may also be included in any other SGmb messages e.g. if contacting the peer node for the first time or if the local restart counter has been incremented.

20.3 Message flows

20.3.1 Session start procedure

The BM-SC initiates the MBMS session start procedure when it is ready to send data. This informs the MBMS GW of the imminent start of the transmission and MBMS session attributes are provided to the MBMS GWs included in the list of downstream nodes in BM-SC. The bearer plane is allocated.

BM-SC and MBMS GW shall at least support IP unicast encapsulation of IP multicast datagrams, which shall be default mode of sending user plane data. BM-SC may support IP multicast encapsulation of user plane IP multicast datagrams and MBMS GW also may support this mode of operation.

Figure 20.3.1.1: MBMS Session Start procedure

1. The BM-SC sends an RAR message to indicate the impending start of the transmission and to provide the session attributes to the MBMS GWs listed in the "list of downstream nodes" parameter of the corresponding MBMS Bearer Context. BM-SC may indicate to MBMS GW that BM-SC supports sending the user plane IP multicast data without IP unicast encapsulation. In such case BM-SC shall send multicast source address as specified by IETF RFC 4604 [73] and IETF RFC 4607 [74] and the user plane multicast destination address.

If IP unicast mode is used, the BM-SC shall also require the MBMS GW to select one UDP port for the reception of the user plane data for the related MBMS service (identified by TMGI and Flow ID).

The BM-SC may also indicate its intent to use IP multicast encapsulation of IP multicast datagrams across Sgi-mb. In this case, the BM-SC shall specify an Sgi-mb (transport) destination multicast IP address associated with the MBMS bearer context, as well as the source UDP port. The inclusion of these data shall mean IP multicast encapsulation of IP multicast datagram is the only offered multicast mode over Sgi-mb. The destination UDP port for IP multicast transport shall be fixed as port number 927. The BM-SC shall also specify the (transport) multicast source address.

The BM-SC shall indicate the M1 interface information of local MBMS information as specified in 3GPP TS 23.285 [112] if the BM-SC determines to use the local MBMS information.

2. The MBMS GW creates an MBMS Bearer Context, stores the session attributes in the MBMS Bearer Context, initiates session start procedure towards the MMEs/SGSNs in its list of MBMS control plane nodes and sends an RAA message to the BM-SC. In case MBMS GW receives BM-SC multicast source address, which indicates BM-SC support for both modes of sending user plane data, MBMS GW decides in which mode MBMS GW shall receive the user plane data. In case MBMS GW decides to receive unicast encapsulated data, then MBMS GW shall send own IP address for user plane to BM-SC and the MBMS GW shall also indicate the UDP port on which the user plane data shall be received. In case MBMS GW decides to receive IP multicast packets, then MBMS GW shall join the multicast group as specified by IETF RFC 4604 [73] and IETF RFC 4607 [74], and indicate to BM-SC about the decision. In case MBMS GW decides to use M1 interface information of local MBMS information, the MBMS GW skips the allocation procedure for IP multicast distribution.

If configured, the MBMS GW sends the RAA message after receiving the first session start response (when positive) message from any MME.

20.3.2 Session update procedure

The BM-SC initiates the MBMS session update procedure when service attributes (e.g. Service Area, MBMS cell list, Access indicator or ARP) for an ongoing MBMS session shall be modified. The MBMS session update procedure update procedure is initiated towards one or more of the MBMS GWs in the list of downstream nodes in the BM-SC, according to the changes in the service area.

NOTE: In addition, when the MBMS Service Area for an ongoing broadcast session is changed in the BM-SC, then MBMS GW(s) may be added to, or removed from, the list of downstream nodes in the BM-SC. The BM-SC will initiate MBMS session start procedures or MBMS session stop procedures towards these MBMS GWs accordingly.

The attributes that can be modified by the RAR message are the MBMS Service Area, the MBMS-Cell-List, the ARP, the Access indicator and the list of MBMS control plane nodes (MMEs, SGSNs).

When a session update message is received, the MBMS GW updates its MBMS Bearer Context accordingly and informs its downstream MMEs/SGSNs of the changed service attributes. If a list of MBMS control plane nodes (MMEs, SGSNs) is included in the session update message, MBMS GW shall initiate a session start procedure towards the new MMEs/SGSNs, and a session stop procedure towards the MMEs/SGSNs that have been removed from the list.

Figure 20.3.2.1: MBMS Session Update procedure

1. The BM-SC sends an RAR message to all MBMS GWs listed in the "list of downstream nodes" parameter of the affected MBMS Bearer Context to indicate that the MBMS session is updated.

2. The MBMS GW stores the new session attributes in the MBMS Bearer Context, initiates session start, session stop or session update procedure towards the MMEs/SGSNs in its list of MBMS control plane nodes and sends an RAA message to the BM-SC. An AAR message is not mandated for the SGmb application in response to an RAR- RAA command exchange.

20.3.3 Session stop procedure

The BM-SC initiates the MBMS session stop procedure when it considers the MBMS session terminated. Typically this will happen when there is no more MBMS data expected to be transmitted for a sufficiently long period of time to justify the release of bearer plane resources in the network.

Figure 20.3.3.1: MBMS Session Stop procedure

1. The BM-SC sends an RAR message to all MBMS GWs listed in the "list of downstream nodes" parameter of the affected MBMS Bearer Context to indicate that the MBMS session is terminated and the bearer plane resources can be released.

2. The MBMS GW releases the resources regarding the session and sends an RAA message to the BM-SC. An AAR message is not mandated for the SGmb application in response to an RAR- RAA command exchange.

20.3.4 MBMS session termination (MBMS GW initiated)

Figure 20.3.4.1: MBMS session termination

1. In exceptional cases (e.g. resource pre-emption or timeout of the MBMS session), the MBMS GW may send an STR command to the BM-SC to initiate the termination of the Diameter session related to an MBMS bearer service. If a bearer plane had been established over SGi-mb for this MBMS bearer service, the bearer plane is released. If the MBMS GW detects the SGi-mb path failure as specified in subclause 20.3.2.1 of 3GPP TS 23.007 [104], the MBMS GW shall set the Termination-Cause to "DIAMETER_LINK_BROKEN" (see IETF RFC 6733 [111]) and shall include the Diagnostic-Info AVP set to "User Plane Failure" if it tears down the MBMS session as a result of detecting an SGi-mb path failure.

2. The BM-SC removes the Diameter session and confirms the operation by sending an STA message to the MBMS GW.

20.3.5 MBMS heartbeat procedure

The BM-SC initiates the MBMS heartbeat procedure to detect a SGmb path failure or the restart of the MBMS GW as specified in 3GPP TS 23.007 [104].

Figure 20.3.5.1: MBMS Heartbeat procedure initiated by the BM-SC

1. The BM-SC sends an RAR message to the MBMS GW and indicates this is a heartbeart request. The BM-SC also includes the Restart-Counter AVP set to its local restart counter.

2. The MBMS GW sends an RAA message to the BM-SC to acknowledge the heartbeat request. The MBMS GW also includes the Restart-Counter AVP set to its local restart counter.

The MBMS GW initiates the MBMS heartbeat procedure to detect a SGmb path failure or the restart of the BM-SC as specified in 3GPP TS 23.007 [104].

Figure 20.3.5.2: MBMS Heartbeat procedure initiated by the MBMS GW

1. The MBMS GW sends an RAR message to the BM-SC and indicates this is a heartbeart request. The MBMS GW also includes the Restart-Counter AVP set to its local restart counter.

2. The BM-SC sends an RAA message to the MBMS GW to acknowledge the heartbeat request. The BM-SC also includes the Restart-Counter AVP set to its local restart counter.

In the context of this procedure, the Diameter session shall be implicitly terminated, i.e. the client (server) shall behave as if the Auth-Session-State AVP was set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 [111]. As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request.

NOTE: The Auth-Session-State AVP is not included in the RAR/RAA message as this is not permitted by the Diameter base protocol. See IETF RFC 6733 [111].

20.4 SGmb Messages

This clause defines the SGmb interface Diameter message.

The relevant AVPs that are of use for the SGmb interface are detailed in this clause. Other Diameter NASREQ (IETF RFC 7155 [120]) AVPs, even if their AVP flag rules is marked with "M", are not required for being compliant with the current specification.

All SGmb specific AVPs for SGmb are needed to be compliant to the SGmb interface unless otherwise stated.

20.4.1 Re-Auth-Request Command

The Re-Auth-Request (RAR) command, defined in IETF RFC 6733 (DIAMETER BASE) [111], is indicated by the Command-Code set to 258 and the message flags’ ‘R’ bit set.

The relevant AVPs that are of use for the SGmb interface are detailed in the ABNF description below. Other valid AVPs for this command are not used for SGmb purposes and should be ignored by the receiver or processed according to the relevant specifications.

The bold marked AVPs in the message format indicate new optional AVPs for SGmb, or modified existing AVPs.

Message Format:

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

{ Re-Auth-Request-Type }

[ Called-Station-Id ]

[ Framed-IP-Address]

[ Framed-IPv6-Prefix ]

[ Framed-Interface-Id ]

[ MBMS-Access-Indicator ]

[ MBMS-StartStop-Indication ]

[ MBMS-Service-Area ]

[ QoS-Information ]

[ MBMS-Session-Duration ]

[ MBMS-Session-Identity ]

[ MBMS-Session-Repetition-number ]

[ TMGI ]

* [ 3GPP-SGSN-Address ]

* [ 3GPP-SGSN-IPv6-Address ]

[ MBMS-Time-To-Data-Transfer ]

[ MBMS-Data-Transfer-Start ]

[ MBMS-Data-Transfer-Stop ]

[ MBMS-Flags ]

[ MBMS-User-Data-Mode-Indication ]

[ MBMS-BMSC-SSM-IP-Address ]

[ MBMS-BMSC-SSM-IPv6-Address ]

[ MBMS-Flow-Identifier ]

[ CN-IP-Multicast-Distribution ]

[ MBMS-HC-Indicator ]

[ MBMS-GW-UDP-Port-Indicator] ; for IP unicast encapsulated user data

[ MBMS-GW-SSM-IP-Address ] ; for IP multicast encapsulated user data

[ MBMS-GW-SSM-IPv6-Address ] ; for IP multicast encapsulated user data

[ MBMS-BMSC-SSM-UDP-Port ] ; for IP multicast encapsulated user data

[ MBMS-Cell-List ]

[ Local-M1-Information ]

[ Origin-State-Id ]

* [ Proxy-Info ]

* [ Route-Record ]

* [ Supported-Features ]

[ Restart-Counter ]

For the MBMS Session Start procedure, RAR is sent by the BM-SC to the MBMS GW(s) that will deliver the MBMS service 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. The RAR message contains either an IPv4 address included in 3GPP-SGSN-Address AVP or an IPv6 address included in 3GPP-SGSN-IPv6-Address AVP for each participating MBMS control plane nodes (MMEs, SGSNs). The MBMS-Time-to-Data-Transfer AVP shall be included to indicate the expected time between the reception of the MBMS Session Start and the transmission of MBMS data flows. For E-UTRAN access, the RAR message may also contain the MBMS-Data-Transfer-Start AVP containing the absolute time stamp of the data delivery start. The RAR message shall also contain the MBMS-Service-Area AVP. If the MBMS Cell List feature is supported, or if the BM-SC does not yet know whether the MBMS-GW supports this feature, the RAR may contain the MBMS-Cell-List AVP. For the distributed MCE architectures, i.e. when the MCE is part of eNB as described in clause 15.1.1 in TS 36.300 [98], the MBMS-Data-Transfer-Start AVP 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. The RAR message shall also contain the Local-M1-Information AVP if the BM-SC determines to use the local MBMS information as specified in 3GPP TS 23.285 [112].

The MBMS-Flags AVP may provide specific control indications in relation to MBMS, e.g. whether the MBMS Session Start procedure is used to re-establish an MBMS session.

For the MBMS Session Update procedure, RAR is sent by the BM-SC in order for the MBMS GW(s) to update their session attributes. If the MBMS service area or the MBMS cell list needs to be changed, the MBMS-Service-Area AVP shall be included in the RAR. If the MBMS Cell List feature is supported and the MBMS cell list needs to be changed, the MBMS-Cell-List AVP shall also be included. If the MBMS-Service-Area AVP but no MBMS-Cell-List AVP is included, this shall indicate that any MBMS Cell List included in a previous RAR does no longer apply. If the Access indicator needs to be updated, it shall be included in the MBMS-Access-Indicator AVP. For E-UTRAN access, the RAR message may also contain the MBMS-Data-Transfer-Start AVP containing the absolute time stamp of the data delivery start. For the distributed MCE architectures, i.e. when the MCE is part of eNB as described in clause 15.1.1 in TS 36.300 [98], the MBMS-Data-Transfer-Start AVP 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. The MBMS-StartStop-Indication AVP with the value UPDATE shall be included. The MBMS-Time-To-Data-Transfer with AVP the value set to 0 shall be included. The MBMS-Session-Duration AVP shall be included to indicate the duration of the remaining part of the MBMS session. The 3GPP-SGSN-Address AVP and the 3GPP-SGSN-IPv6-Address AVP shall be included if the related lists of MBMS control plane nodes (MMEs, SGSNs) in the MBMS GW(s) have changed. If the ARP needs to be changed, the QoS-Information AVP shall be included. The other bold marked AVPs shall be included as given by the previous, corresponding MBMS Session Start procedure.

For the MBMS Session Stop procedure, RAR is sent by the BM-SC to the MBMS GW(s) when it considers the MBMS session to be terminated. The session is typically terminated when there is no more MBMS data expected to be transmitted for a sufficiently long period of time to justify a release of bearer plane resources in the network. For E-UTRAN access, the RAR message may also contain the MBMS-Data-Transfer-Stop AVP containing the absolute time stamp of the data delivery stop. The MBMS-Flags AVP may provide specific control indications, e.g. whether the MBMS Session Stop procedure is used to release the MBMS bearer context locally.

For the MBMS Session Start procedure, the Qos-Information AVP indicates the QoS that is required for the MBMS bearer service for the actual MBMS session. Only the QoS-Class-Identifier AVP, Max-Requested-Bandwidth-DL AVP, Guaranteed-Bitrate-DL AVP and Allocation-Retention-Priority AVP within the QoS-Information AVP are applicable for the MBMS bearer service. The MBMS-Service-Area AVP is passed from BM-SC transparently through MBMS GW to the MMEs/SGSN(s) that are relevant for the actual MBMS bearer service. The MBMS-Cell-List AVP is also passed transparently through MBMS GW to the MMEs. The MBMS-Access-Indicator AVP indicates in which radio access types the MBMS bearer service shall be broadcasted, i.e UTRAN, or E-UTRAN, or both.

The usage of MBMS-StartStop-Indication AVP, Session-Id AVP, Framed-IP-Address AVP, Framed-IPv6-Prefix AVP, Framed-Interface-Id AVP, Called-Station-Id AVP and MBMS-Flow-Identifier AVP can refer to Gmb interface as described in clause 17.6.5.

If unicast mode is used, the MBMS GW shall select an IP unicast address and a destination UDP port that is unique within the MBMS GW or that IP unicast address.

If IP multicast encapsulation of application IP multicast datagram is used over Sgi-mb, the BM-SC shall select a source UDP port that is unique within the BM-SC for that IP multicast address.

For the MBMS Heartbeat procedure, RAR is sent by the BM-SC to the MBMS GW, or vice-versa. The RAR message shall contain the following AVPs:

– the MBMS-StartStop-Indication AVP set to the value "heartbeat";

– the Restart-Counter AVP set to the local restart counter of the sender.

20.4.2 RE-Auth-Answer Command

The Re-Auth-Answer (RAA) command, defined in IETF RFC 6733 (DIAMETER BASE) [111], is indicated by the Command-Code set to 258 and the message flags’ ‘R’ bit clear, is sent in response to the RAR.

The bold marked AVPs in the message format indicate new optional AVPs for SGmb, or modified existing AVPs.

Message Format:

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

[ MBMS-StartStop-Indication ]

[ MBMS-GGSN-Address ] ; for unicast encapsulated user data

[ MBMS-GGSN-Ipv6-Address ] ; for unicast encapsulated user data

[ MBMS-User-Data-Mode-Indication ]

[ MBMS-GW-UDP-Port] ; for unicast encapsulated user data

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

[ Failed-AVP ]

* [ Redirected-Host ]

[ Redirected-Host-Usage ]

[ Redirected-Host-Cache-Time ]

[ Proxy-Info ]

* [ Supported-Features ]

[ Restart-Counter ]

For the MBMS Heartbeat procedure, RAA is sent by the BM-SC to the MBMS GW, or vice-versa. The RAA message shall contain the following AVPs:

– the MBMS-StartStop-Indication AVP set to the value "heartbeat";

– the Restart-Counter AVP set to the local restart counter of the sender.

20.4.3 Session-Termination-Request Command

A DIAMETER session may be terminated by the MBMS GW in exceptional cases.

Message Format:

<ST-Request> ::= < Diameter Header: 275, REQ, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Auth-Application-Id }

{ Termination-Cause }

[ Destination-Host ]

* [ Class ]

[ Origin-State-Id ]

* [ Proxy-Info ]

* [ Route-Record ]

[ Diagnostic-Info ]

[ Restart-Counter ]

20.4.4 Session-Termination-Answer Command

The STA command, defined in IETF RFC 6733 (DIAMETER BASE) [111], is indicated by the Command-Code field set to 275 and the ‘R’ bit cleared in the Command Flags field, is sent in response to an STR command.

Message Format:

<ST-Answer> ::= < Diameter Header: 275, PXY >

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

* [ Class ]

[ Error-Message ]

[ Error-Reporting-Host ]

[ Failed-AVP ]

[ Origin-State-Id ]

* [ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

* [ Proxy-Info ]

[ Restart-Counter ]

20.4.5 Abort-Session-Request Command

The Abort-Session-Request (ASR) command, defined in IETF RFC 6733 (DIAMETER BASE) [111], is indicated by the Command-Code set to 274 and the message flags’ ‘R’ bit set, is sent by the BM-SC to the MBMS GW to request that the session identified by the Session-Id be stopped.

Message Format

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

[ Origin-State-Id ]

* [ Proxy-Info ]

* [ Route-Record ]

[ Restart-Counter ]

20.4.6 Abort-Session-Answer Command

The Abort-Session-Answer (ASA) command, defined in IETF RFC 6733 (DIAMETER BASE) [111], is indicated by the Command-Code set to 274 and the message flags’ ‘R’ bit clear, is sent in response to the ASR.

Message Format

< Session-Id >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

[ Failed-AVP ]

* [ Redirected-Host ]

[ Redirected-Host-Usage ]

[ Redirect-Max-Cache-Time ]

* [ Proxy-Info ]

[ Restart-Counter ]

20.5 SGmb re-used AVPs

Table 20.5.1 lists the Diameter AVPs re-used by the SGmb reference point from the Gmb reference point and other existing Diameter Application, reference to their respective specifications and short description of their usage witin the SGmb reference point. When reused from Gmb reference point, the specific clause in the present specification is referred. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol, do not need to be supported. The AVPs from Diameter base protocol are not included in table 20.5.1, but they are re-used for the SGmb reference point. Where RADIUS VSAs are re-used, they shall be translated to Diameter AVPs as described in RFC 7155 [120] with the exception that the ‘M’ flag shall be set and the ‘P’ flag may be set.

Table 20.5.1 : SGmb re-used Diameter AVPs

Attribute Name	Reference	Description
TMGI	17.7.2	Contains the Temporary Mobile Group Identity allocated to a particular MBMS bearer service.
MBMS-StartStop-Indication	17.7.5	Indicates the type of MBMS Session procedure.
MBMS-Service-Area	17.7.6	Indicates the area over which the MBMS bearer service has to be distributed.
MBMS-Session-Duration	17.7.7	Indicates the estimated session duration (MBMS Service data transmission).
MBMS-Session-Identity	17.7.11	Together with TMGI it identifies a transmission of a specific MBMS session.
MBMS-Time-To-Data-Transfer	17.7.14	Indicates the expected time between reception of the MBMS Session Start (RAR (Start) command) or the MBMS Session Update (RAR (Update) command) and the commencement of the MBMS Data flow. A value of 0 (1 sec.) shall be used in the Session Update.
MBMS-Session-Repetition-Number	17.7.15	Contains the session identity repetition number of the MBMS transmission session on the SGmb interface.
MBMS-User-Data-Mode-Indication	17.7.18	When sent from the BM-SC to the MBMS GW, it indicates the mode that BM-SC supports. When sent from the MBMS GW to the BM-SC, it indicates the mode that BM-SC shall send user plane data with. Two modes apply: – Unicast mode: IP multicast packets over UDP encapsulated by IP unicast header. – Multicast mode: IP multicast packetsencapsulated over UDP by IP multicast header.
MBMS-GGSN-Address	17.7.19	Contains the value of MBMS GW’s IPv4 address for user plane data.
MBMS-GGSN-IPv6-Address	17.7.20	Contains the valus of MBMS GW’s IPv6 address for user plane data.
MBMS-BMSC-SSM-IP-Address	17.7.21	Contains the value of BM-SC’s IPv4 address of Source Specific Multicasting.
MBMS-BMSC-SSM-IPv6-Address	17.7.22	Contains the value of BM-SC’s IPv6 address of Source Specific Multicasting.
MBMS-Flow-Identifier	17.7.23	Represents a location dependent subflow of an MBMS bearer service.
CN-IP-Multicast-Distribution	17.7.24	Indicates if IP multicast distribution to UTRAN should be used for the MBMS user plane data.
MBMS-HC-Indicator	17.7.25	Indicates if header compression is used by BM-SC when sending for MBMS user plane data.(NOTE 1)
3GPP-SGSN-Address	16.4.7	Represents the SGSN or MME’s IPv4 address that is used by the GTP control plane for the handling of control messages.
3GPP-SGSN-IPv6-Address	16.4.7	Represents the SGSN or MME’s IPv6 address that is used by the GTP control plane for the handling of control messages.
Called-Station-Id	NASREQ, IETF RFC 7155 [120]	Contains the Access Point Name (APN) for which the MBMS bearer service is defined
Framed-Interface-Id	NASREQ, IETF RFC 7155 [120]	Contains the IPv6 interface identifier of the multicast address
Framed-IP-Address	NASREQ, IETF RFC 7155 [120]	Contains the IPv4 multicast address.
Framed-IPv6-Prefix	NASREQ, IETF RFC 7155 [120]	Contains the IPv6 prefix of the multicast address.
Local-M1-Information	3GPP TS 29.468 [113]	Contains the M1 interface information of the local MBMS information, i.e., transport network IP Multicast Address, IP address of multicast source and C-TEID.
QoS-Information	3GPP TS 29.212 [75]	Contains the QoS that is required for the MBMS bearer service for the MBMS session. Only the QoS-Class-Identifier AVP, Max-Requested-Bandwidth-DL, Guaranteed-Bitrate-DL AVP and Allocation-Retention-Priority AVP within the QoS-Information AVP are applicable for the MBMS bearer service.
Supported-Features	3GPP TS 29.229 [105]	If present, this AVP informs the destination host about the features that the origin host requires to successfully complete this command exchange
NOTE 1: Header Compression only supported for UTRAN for this Release.

20.5a SGmb specific AVPs

Table 20.5a.1 describes the SGmb specific Diameter AVPs. The Vendor-Id header of all SGmb specific AVPs defined in the present specification shall be set to 3GPP (10415).

The SGmb specific AVPs require to be supported to be compliant with the present specification. All AVPs in table 20.5a.1 are mandatory within SGmb interface unless otherwise stated.

Table 20.5a.1: SGmb specific AVPs

				AVP Flag rules
Attribute Name	AVP Code	Section defined	Value Type	Must	May	Should not	Must not	May Encr.	Applicability (NOTE)
MBMS-Access-Indicator	923	20.5a.1	Enumerated	M.V	P			Y
MBMS-GW-SSM-IP-Address	924	20.5a.2	OctetString	V	P		M	Y
MBMS-GW-SSM-IPv6-Address	925	20.5a.3	OctetString	V	P		M	Y
MBMS-BMSC-SSM-UDP-Port	926	20.5a.4	OctetString	V	P		M	Y
MBMS-GW-UDP-Port	927	20.5a.5	OctetString	V	P		M	Y
MBMS-GW-UDP-Port-Indicator	928	20.5a.6	Enumerated	V	P		M	Y
MBMS-Data-Transfer-Start	929	20.5a.7	Unsigned64	V	P		M	Y
MBMS-Data-Transfer-Stop	930	20.5a.8	Unsigned64	V	P		M	Y
MBMS-Flag	931	20.5a.9	Unsigned32	V	P		M	Y
Restart-Counter	932	20.5a.10	Unsigned32	V	P		M	Y	MBMS Heartbeat
Diagnostic-Info	933	20.5a.11	Unsigned32	V	P		M	Y
MBMS-Cell-List	934	20.5a.12	OctetString	V	P		M	Y	MBMS Cell List
NOTE: AVPs marked with a supported feature are applicable as described in subclause 20.7.

20.5a.1 MBMS-Access-Indicator AVP

The MBMS-Access-Indicator AVP (AVP code 923) is of type Enumerated. It indicates whether the MBMS bearer service will be delivered in UTRAN-only, E-UTRAN-only or both coverage areas. The following values are supported:

UTRAN (0)

The MBMS bearer service shall only be delivered in UTRAN only coverage areas.

E-UTRAN (1)

The MBMS bearer service shall only be delivered in E-UTRAN only coverage areas.

UTRAN-AND-E-UTRAN (2)

The MBMS bearer service shall be delivered both in UTRAN and E-UTRAN coverage areas.

20.5a.2 MBMS-GW-SSM-IP-Address AVP

The MBMS-GW-SSM-IP-Address AVP (AVP code 924) is of type OctetString and contains the Sgi-mb (transport) plane IPv4 destination multicast address used by BM-SC for IP multicast encapsulation of application IP multicast datagrams.

20.5a.3 MBMS-GW-SSM-IPv6-Address AVP

The MBMS-GW-SSM-IPv6-Address AVP (AVP code 925) is of type OctetString and contains the Sgi-mb (transport) plane IPv6 prefix of the destination multicast address used by BM-SC for IP multicast encapsulation of application IP multicast datagrams.

20.5a.4 MBMS-BMSC-SSM-UDP-Port AVP

The MBMS-BMSC-SSM-UDP-Port AVP (AVP code 926) is of type OctetString and contains the Sgi-mb (transport) plane source UDP port number at the BM-SC for IP multicast encapsulation of IP multicast datagrams.

20.5a.5 MBMS-GW-UDP-Port AVP

The MBMS-GW-UDP-Port AVP (AVP code 927) is of type OctetString, and contains the value of the UDP port from which the user plane data will be received in the MBMS-GW.

20.5a.6 MBMS-GW-UDP-Port-Indicator AVP

MBMS-GW-UDP-Port-Indicator AVP (AVP code 928) is of type Enumerated. It indicates that the payload related to the MBMS service is required to be delivered in the MBMS UDP Port assigned by the MBMS-GW.

UDP-PORT-REQUIRED (1)

Value 1 indicates that the user plane data corresponding to the MBMS service shall be delivered on the UDP Port provided by the MBMS-GW.

20.5a.7 MBMS-Data-Transfer-Start AVP

The MBMS-Data-Transfer-Start AVP (AVP code 929) is of type Unsigned64.

This value indicates the time in seconds for the radio resources set up relative to 00:00:00 on 1 January 1900 (calculated as continuous time without leap seconds and traceable to a common time reference) where binary encoding of the integer part is in the first 32 bits and binary encoding of the fraction part in the last 32 bits. The fraction part is expressed with a granularity of 1 /2**32 second.

This AVP is only valid for E-UTRAN access type.

20.5a.8 MBMS-Data-Transfer-Stop AVP

The MBMS-Data-Transfer-Stop AVP (AVP code 930) is of type Unsigned64.

This value indicates the time in seconds for the release of resources relative to 00:00:00 on 1 January 1900 (calculated as continuous time without leap seconds and traceable to a common time reference) where binary encoding of the integer part is in the first 32 bits and binary encoding of the fraction part in the last 32 bits. The fraction part is expressed with a granularity of 1 /2**32 second.

This AVP is only valid for E-UTRAN access type.

20.5a.9 MBMS-Flags AVP

The MBMS-Flags AVP (AVP coce 931) is of type Unsigned32. It provides control indications.

It shall contain a bit mask. The meaning of the bits shall be as defined in table 20.5a.9.1:

Table 20.5a.9.1 : MBMS-Flags

Bit	Name	Description
0	MSRI	MBMS Session Re-establishment Indication : This bit, when set, indicates that the MBMS Session Start Request message is used to re-establish an MBMS session (see 3GPP TS 23.007 [104]).
1	LMBCRI	Local MBMS Bearer Context Release Indication : This bit, when set, indicates that the MBMS Session Stop Request message is used to locally release the MBMS bearer context in the MBMS‑GW and in the associated MME/SGSNs (see3GPP TS 23.007 [104]
NOTE: Bits not defined in this table shall be cleared by the sending BM-SC and ignored by the receiving MBMS GW.

20.5a.10 Restart-Counter AVP

The Restart-Conter AVP (AVP coce 932) is of type Unsigned32. This is a monotonically increasing value that is advanced whenever the MBMS entity restarts with loss of previous state, for example upon restart. The Restart-Counter AVP may be included in any Diameter message over the SGmb reference point, including CER/CEA.

20.5a.11 Diagnostic-Info AVP

The Diagnostic-Info AVP (AVP code 933) is of type Unsigned32.

It shall contain a bit mask. The meaning of the bits shall be as defined in table 20.5a.11.1:

Table 20.5a.11.1 : Diagnostic-Info

Bit

Name

Description

UPFAIL

User Plane Failure:

This bit, when set, indicates the detection of a User Plane Failure by the MBMS GW (see subclause 20.3.2.1 of 3GPP TS 23.007 [104]).

NOTE: Bits not defined in this table shall be cleared by the sending MBMS GW and ignored by the receiving BM-SC.

20.5a.12 MBMS-Cell-List AVP

The MBMS-Cell-List AVP (AVP code 934) is of type OctetString. It contains the MBMS Cell Listthat the E-UTRAN uses 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 AVP shall consist of two octets indicating the number of cell identifiers in the list, followed by a sequence of maximum 4096 cell identifiers, coded as E-CGIs.

Bits

1-16

Number N of ECGI codes coded as:

1 binary value is ‘0000 0000 0000 0000’

4096 binary value is ‘0000 1111 1111 1111’

17-(56*N+16)

A consecutive list of N ECGI codes, each encoded according to subclause 8.21.5 of 3GPP TS 29.274 [81].

The ECGI and its semantics are defined in subclause 19.6 of 3GPP TS 23.003 [40].

20.6 SGmb specific Experimental-Result-Code AVP values

The same codes specified in clause 17.8 apply here except DIAMETER_ERROR_UNKNOWN_MBMS_BEARER_SERVICE (5122)

20.7 Use of the Supported-Features AVP on the SGmb reference point

The Supported-Features AVP is used during session establishment to inform the destination host about the required and optional features that the origin host supports. The client shall, in the first request in a Diameter session indicate the set of supported features. The server shall, in the first answer within the Diameter session indicate the set of features that it has in common with the client and that the server shall support within the same Diameter session. Any further command messages shall always be compliant with the list of supported features indicated in the Supported-Features AVPs during session establishment. Features that are not advertised as supported shall not be used to construct the command messages for that Diameter session. Unless otherwise stated, the use of the Supported-Features AVP on the SGmb reference point shall be compliant with the requirements for dynamic discovery of supported features and associated error handling on the Cx reference point as defined in clause 7.2.1 of 3GPP TS 29.229 [105].

The base functionality for the SGmb reference point is the 3GPP Rel-11 standard and a feature is an extension to that functionality. If the origin host does not support any features beyond the base functionality, the Supported-Features AVP may be absent from the SGmb commands. As defined in clause 7.1.1 of 3GPP TS 29.229 [105], when extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.

As defined in 3GPP TS 29.229 [105], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the SGmb reference point, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the SGmb reference point, the Feature-List-ID AVP shall differentiate those lists from one another.

On receiving an initial request application message, the destination host shall act as defined in clause 7.2.1 of 3GPP TS 29.229 [105]. The following exceptions apply to the initial RAR/RAA command pair:

– If the BM-SC supporting post-Rel-11 SGmb functionality is able to interoperate with a MBMS GW supporting Rel-11, the RAR shall include the features supported by the BM-SC within Supported-Features AVP(s) with the ‘M’ bit cleared. Otherwise, the RAR shall include the supported features within the Supported-Features AVP(s) with the M-bit set.

NOTE 1: One instance of Supported-Features AVP is needed per Feature-List-ID.

– If the RAR command does not contain any Supported-Features AVP(s) and the MBMS GW supports Rel-11 SGmb functionality, the RAA command shall not include the Supported-Features AVP. In this case, both BM-SC and MBMS GW shall behave as specified in the Rel-11 version of this document.

– If the RAR command contains the Supported-Features AVP, the MBMS GW shall include the Supported-Features AVP in the RAA command, with the ‘M’ bit cleared, indicating only the features that both the BM-SC and MBMS GW support.

NOTE 2: The client will always declare all features that are supported according to table 20.7.1. When more than one feature identifying a release is supported by both BM-SC and MBMS GW, the BM-SC will work according to the latest common supported release.

Once the BM-SC and MBMS GW have negotiated the set of supported features during session establishment, the set of common features shall be used during the lifetime of the Diameter session.

The table below defines the features applicable to the SGmb interface for the feature list with a Feature-List-ID of 1.

Table 20.7.1: Features of Feature-List-ID 1 used in SGmb

Feature bit	Feature	M/O	Description
0	MBMS Heartbeat	O	This feature indicates the support of the MBMS Heartbeat functionality, including the AVPs and corresponding procedures.
1	MBMS Cell List	O	This feature indicates the support of providing a MBMS-Cell-List AVP in the MBMS Session Start and MBMS Session Update procedures. For deployments with E-UTRAN access, this feature shall be supported.
Feature bit:The order number of the bit within the Feature-List AVP where the least significant bit is assigned number "0". Feature: A short name that can be used to refer to the bit and to the feature, e.g. "EPS". M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O") in this 3GPP Release. Description: A clear textual description of the feature.

Annex A (informative):
Interworking PCS1900 with PSDNs

Void.

Annex B (normative):
Rate control related to Cellular Internet Of Things (CIoT) optimisations