1.1. MBMS and E-MBMS Interfaces Overview
Gmb: Control Plane between BM-SC and GGSN
Gi: Bearer User Plane between BM-SC and GGSN
Mz; See below - It is used for roaming (roaming variant of the Gmb reference point)
and
M1: It is the reference point between MBMS GW and E-UTRAN/UTRAN for MBMS data delivery.
M2 and M3: See below - due to MCE introduced
S1-MME: It is the reference point between MME and E-UTRAN as specified in TS 23.401. For the purpose of supporting MBMS service, it is a control plane interface for session control.
Sm: It is the reference point for the control plane between MME and MBMS GW.
Sn: It is the reference point for the control plane between MBMS GW and SGSN.
SGi-mb: It is the reference point between BM-SC and MBMS GW function for MBMS data delivery.
SGmb: It is the reference point for the control plane between BM-SC and MBMS GW.
Protocol assumption:
- The Sm and Sn reference points are based on GTPv2-C.
| Gmb | GGSN --- BM-SC | Diameter | | | Used in |
| Gi | GGSN --- BM-SC | | Radius / Diameter | | Used in |
| Mz | BM-SC --- Other PLMN's BM-SC | Diameter | | | |
In the bearer plane, this service provides delivery of IP Multicast datagrams from the Gi reference point to UEs with a specified Quality of Service.
In the control plane, this service provides mechanisms via Gmb (between BM-SC and MBMS-GW, like GGSN) for:
- managing the MBMS bearer service activation status of UEs (in the case of multicast mode);
- outsourcing authorisation decisions to the MBMS User Service (i.e. to the BM-SC) (in the case of multicast mode);
- providing control of session initiation/termination by the MBMS User Service and managing bearer resources for the distribution of MBMS data (in the case of multicast and broadcast modes).
- A particular instance of the MBMS Bearer Service is identified by an IP Multicast Address and an APN Network Identifier.
| M1 | MBMS-GW --- eNB | | SYNC / GTP-U | | MBMS Packet Supported - Bearer / User Plane |
| Sm | MBMS-GW --- MME | GTPv2-C | | | It is the reference point for the control plane between MME and MBMS GW. |
| Sn | MBMS-GW --- SGSN | GTPv2-C | | | It is the reference point for the control plane between MBMS GW and SGSN. |
| SGmb (Gmb) | MBMS-GW --- eBM-SC | CP Supported | | | MBMS Bearer: It is the reference point for the control plane between BM-SC and MBMS GW. |
| SGi-mb (Gmb) | MBMS-GW --- eBM-SC | | UP Supported | | MBMS Bearer: It is the reference point between BM-SC and MBMS GW function for MBMS data delivery. |
| SGi | PDN GW (P-GW) --- BM-SC | | UP Supported | | EPS Bearer: Between BM-SC and PDN-GW (P-GW) |
1.2. E-MBMS Interface – M1, M2 and M3 in LTE (Control Plane) Overview
Figure (M1~M3 Interface): http://docs.google.com/View?id=ddh56dhg_107kv9hmq2q
- 3GPP has defined a SYNC protocol between the E-MBMS gateway and the eNBs to ensure that the same content is sent over-the-air from all the eNBs.
- The E-MBMS gateway is responsible for distributing the traffic to the different eNBs of the MBSFN area.
- IP multicast may be used for distributing the traffic from the E-MBMS gateway (E-MBMS GW) to the different eNBs (eNB).3GPP has defined a control plane entity, known as the MBMS Coordination Entity (MCE) that ensures that the same resource block is allocated for a given service across all the eNBs of a given MBSFN area.
- It is the task of the MCE to ensure that the RLC/MAC layers at the eNBs are appropriately configured for MBSFN operation.
Control Plane Interfaces
“M
- An Application Part is defined for this interface between E-MBMS Gateway and MCE.
- This application part allows for MBMS Session Control Signalling on E-RAB level (i.e. does not convey radio configuration data).
- The procedures comprise e.g. MBMS Session Start and Stop.
- SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.
“M
- An Application Part is defined for this interface, which conveys at least radio configuration data for the multi-cell transmission mode eNBs and Session Control Signalling.
- SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.
User Plane Interface
“M
- This interface is a pure user plane interface. Consequently no Control Plane Application Part is defined for this interface.
- IP Multicast is used for point-to-multipoint delivery of user packets for both single cell and multi-cell transmission.
Figure: Deployment Options: (M1~M3) http://docs.google.com/View?id=ddh56dhg_109cmj7n6cq
- It is not precluded that M3 interface can be terminated in eNBs.
- In the 1st scenario depicted on the left MCE is deployed in a separate node.
- In the 2nd scenario on the right MCE is part of the eNBs.
- These eMBMS architecture deployment alternatives shall be applicable to both multi-cell and single cell transmission mode.
| M1 | MBMS-GW --- eNB | | SYNC / GTP-U | | MBMS Packet Supported - Bearer / User Plane |
| M2 | MCE --- eNB | ??? / SCTP | | | MBMS Supported - Control Plane |
| M3 | MBMS-GW --- MCE | ??? / SCTP | | | MBMS Supported - Control Plane |
MBMS Control plane function
MBMS control plane function supporting for UTRAN:
- The MBMS control plane function is supported by MME for E-UTRAN access and by SGSN for UTRAN access.
- One or more MBMS control plane functional entities are used in a PLMN.
MME supports the following functions in order to enable MBMS support for E-UTRAN:
- Session control of MBMS bearers to the E-UTRAN access (including reliable delivery of Session Start/Session Stop to E-UTRAN);
- Transmit Session control messages towards multiple E-UTRAN nodes;
- It is FFS whether there is a need to filter the distribution of Session Control message to E-UTRAN nodes based on MBMS service area;
- It provides an Sm interface to the MBMS GW function: it receives MBMS service control messages and the IP Multicast address for MBMS data reception from MBMS GW function over the Sm interface.
- NOTE: When a UE leaves or enters MBMS bearer coverage, the service continuity is handled by the Service Layer (in UE and network)
1.3. MBMS Interface – Gmb (UMTS) and SGmb + SGimb (LTE) Overview (Control Plane) (29.061)
Gmb Interface
- The Gmb reference point is between the BM-SC and the GGSN. It is used to give MBMS service information, like QoS and MBMS service area, to the UMTS network.
- This represents the network side boundary of the MBMS Bearer Service from a control plane perspective.
The GGSN uses the Gmb interface
- to request authorization/deactivation of a user for a multicast MBMS service,
- to register/de-register the GGSN for receiving a multicast MBMS service.
- to receive indication of session start, session update and session stop messages, which shall cause the GGSN, SGSN and RAN to set up/tear down the appropriate resources for the service.
- to receive indication if IP multicast distribution to UTRAN should be used for the MBMS user plane data.
- The support of Gmb within the GGSN is optional and needed for MBMS.
- The Gmb application is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP.
- The vendor identifier assigned by IANA to 3GPP is 10415. The Gmb application identifier value assigned by IANA is 16777223.
The BM-SC supports
- BM-SC functions for different MBMS bearer services may be provided by different physical network elements.
- To allow this distribution of BM-SC functions, the Gmb protocol must support the use of proxies to correctly route the different signalling interactions in a manner which is transparent to the GGSN.
MBMS bearer service specific Gmb signalling:
- The GGSN establishes the MBMS bearer context and registers at BM-SC.
- The GGSN or the BM-SC releases the MBMS bearer context and de-registers the GGSN from the BM-SC.
- The BM-SC indicates session start and stop to the GGSN including session attributes like QoS and MBMS service area.
User specific Gmb signalling:
- The BM-SC authorises the user specific MBMS multicast service activation (join) at the GGSN.
- The GGSN reports to the BM-SC the successful user specific MBMS multicast activation (join) to allow the BM-SC to synchronise the BM-SC MBMS UE context with the MBMS UE contexts in the SGSN and GGSN.
- The GGSN reports to the BM-SC when a user specific MBMS multicast service is released or deactivated (e.g. at implicit detach). The GGSN makes this report in order to synchronise the BM-SC MBMS UE context with the MBMS UE contexts in the SGSN and GGSN.
- The BM-SC initiates the deactivation of a user specific MBMS bearer service when the MBMS user service is terminated.
- BM-SC functions for different MBMS bearer services may be provided by different physical network elements.
- To allow this distribution of BM-SC functions, the Gmb protocol must support the use of proxies to correctly route the different signalling interactions in a manner which is transparent to the GGSN.
1.4. MBMS Gmb Interface – Gmb Diameter Message (29.061)
Gmb Diameter messages
| No | Abbr | Diameter Command | Direction |
| 1 | | AA-Request | GGSN to the BM-SC |
| 2 | AAA | AA-Answer | BM-SC to the GGSN |
| 3 | STR | Session-Termination-Request | GGSN to the BM-SC |
| 4 | STA | Session-Termination-Answer | BM-SC to the GGSN |
| 5 | RAR | Re-Auth-Request | BM-SC to the GGSN |
| 6 | RAA | Re-Auth-Answer | GGSN to the BM-SC |
| 7 | ASR | Abort-Session-Request | BM-SC to the GGSN |
| 8 | ASA | Abort-Session-Answer | GGSN to the BM-SC |
1.5. MBMS Gi/SGi Interface – Gi/SGi Diameter Message (29.061)
Gi/SGi Diameter messages
| No | Abbr | Diameter Command | Direction |
| 1 | | AA-Request | GGSN to Diameter server |
| 2 | AAA | AA-Answer | Diameter server to the GGSN/P-GW |
| 3 | ACR | Accounting-Request | GGSN/P-GW to the Diameter server |
| 4 | ACA | Accounting-Answer | Diameter server to the GGSN/P-GW |
| 5 | STR | Session-Termination-Request | GGSN/P-GW to the Diameter server |
| 6 | STA | Session-Termination-Answer | Diameter server to the GGSN |
| 7 | ASR | Abort-Session-Request | Diameter server to the GGSN/P-GW |
| 8 | ASA | Abort-Session-Answer | GGSN/P-GW to the Diameter server |
1.6. MBMS Gi/SGi Interface – Gi/SGi Radius Message (29.061)
- Access-Request message (sent from GGSN/P-GW to AAA server)
- Access-Accept (sent from AAA server to GGSN/P-GW)
- Accounting-Request START (sent from GGSN/P-GW to AAA server)
- Accounting Request STOP (sent from GGSN/P-GW to AAA server)
- Accounting
- Accounting Request OFF (optionally sent from GGSN/P-GW to AAA server)
- Sub-attributes of the 3GPP Vendor-Specific attribute
- Presence of the 3GPP Vendor-Specific attribute in RADIUS messages
- Coding 3GPP Vendor-Specific RADIUS attributes
- Accounting Request Interim-Update (sent from GGSN/P-GW to AAA server)
- Disconnect Request (optionally sent from AAA server to GGSN/P-GW
1.7. MBMS Gmb Interface – Gmb Specific Diameter AVP (29.061)
Gmb specific Diameter AVPs
| Attribute Name | AVP Code | Value Type | Remark |
| TMGI | 900 | OctetString | See Charging Section later |
| Required-MBMS-Bearer-Capabilities | 901 | UTF8String | See Charging Section later |
| MBMS-StartStop-Indication | 902 | Enumerated | (See 29.061) § START (0) § STOP (1) § UPDATE (2) |
| MBMS-Service-Area | 903 | OctetString | See Charging Section later |
| MBMS-Session-Duration | 904 | OctetString | Bit 8 of octet 1 to bit 8 of octet 3 (17 bits) express seconds, for which the maximum allowed value is 86400 seconds. Bits 7 to 1 of octet 3 (7 bits) express days, for which the maximum allowed value is 18 days. |
| 3GPP-IMSI | 1 | UTF8String | |
| Alternative-APN | 905 | UTF8String | BM-SC only includes it if the UE must use a different APN for the MBMS PDP Context from the one used in the Join message. |
| MBMS-Service-Type | 906 | Enumerated | See Charging Section later |
| 3GPP-SGSN-Address | 6 | OctetString | |
| 3GPP-SGSN-IPv6-Address | 15 | OctetString | |
| MBMS | 907 | Enumerated | See Charging Section later |
| MBMS-Session-Identity | 908 | OctetString | See Charging Section later |
| RAI | 909 | UTF8String | See Charging Section later |
| 3GPP-IMEISV | 20 | OctetString | |
| 3GPP-RAT-Type | 21 | OctetString | |
| 3GPP-User-Location-Info | 22 | OctetString | |
| 3GPP-MS-TimeZone | 23 | OctetString | |
| Additional-MBMS-Trace-Info | 910 | OctetString | specified in TS 29.060 |
| MBMS-Time-To-Data-Transfer | 911 | OctetString | the expected time between reception of the MBMS Session Start (RAR(Start) command) and the commencement of the MBMS Data flow |
| MBMS-Session-Repetition-Number | 912 | OctetString | contains the session identity repetition number of the MBMS transmission session on the Gmb interface. The value 0 indicates the first transmission of a session. The values 1 to 255 represents the retransmission sequence number of a session |
| MBMS-Required-QoS | 913 | UTF8String | 1= Allocation/Retention Priority 2~N = QoS Profile as specified by the Quality-of-Service information element, from octet 3 onwards, in 3GPP TS 24.008 |
| MBMS-Counting-Information | 914 | Enumerated | COUNTING-NOT-APPLICABLE (0) COUNTING-APPLICABLE (1) |
| MBMS-User-Data-Mode-Indication | 915 | Enumerated | Unicast (0) Multicast and Unicast (1) |
| MBMS-GGSN-Address (for GGSN) | 916 | OctetString | contains the value of GGSN's IPv4 address for user plane data. IPv4 only or dual stack GGSN includes this AVP in case BM-SC requests GGSN's user plane unicast address |
| MBMS-GGSN-IPv6-Address (for GGSN) | 917 | OctetString | contains the value of GGSN's IPv4 address for user plane data. Dual stack GGSN includes this AVP in case BM-SC requests GGSN's user plane unicast address |
| MBMS-BMSC-SSM-IP-Address (for BM-SC) | 918 | OctetString | contains the value of BM-SC's IPv4 address for Source Specific Multicasting. IPv4 only or dual stack BM-SC includes this AVP |
| MBMS-BMSC-SSM-IPv6-Address (for BM-SC) | 919 | OctetString | contains the value of BM-SC's IPv4 address for Source Specific Multicasting. Dual stack BM-SC includes this AVP |
| MBMS-Flow-Identifier | 920 | OctetString | represents a location dependent subflow of a broadcast MBMS bearer service |
| CN-IP-Multicast-Distribution | 921 | Enumerated | represents an indication if IP multicast distribution to UTRAN should be used for the MBMS user plane data. NO-IP-MULTICAST (0) IP-MULTICAST (1) |
| MBMS-HC-Indicator | 922 | Enumerated | represents an indication if header compression is used by BM-SC when sending for MBMS user plane data. The enumeration values are defined in 3GPP TS 25.413 |
Gmb specific Result-Code AVP values
- There are two different types of errors in Diameter; protocol and application errors.
- Protocol error is one that occurs at the base protocol level, those are covered in the Diameter Base RFC 3588 specific procedures.
- Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application.
- The Result-Code AVP values defined in Diameter Base RFC 3588
Permanent Failures
§ DIAMETER_ERROR_START_INDICATION (5120)
§ DIAMETER_ERROR_STOP_INDICATION (5121)
§ DIAMETER_ERROR_UNKNOWN_MBMS_BEARER_SERVICE (5122)
§ DIAMETER_ERROR_SERVICE_AREA (5123)
Transient Failures
§ DIAMETER_ERROR_OUT_OF_RESOURCES (4121)
1.8. MBMS Interface – Mz (Gmb for roaming) Overview (29.061)
Mz Interface
§ The support of Mz with in BM-SC is needed for MBMS roaming scenario. Mz interface is defined between the visited BM-SC and the home BM-SC.
§ Mz is the roaming variant of the Gmb reference point with the same functionality as described under Gmb, i.e. with MBMS bearer and User specific signalling.
§ MBMS bearer and User specific Mz signalling is used between a BM-SC in the visited PLMN and a BM-SC in the home PLMN when MBMS services from the home PLMN are offered by the visited PLMN.
§ User specific signalling is used between a BM-SC in the visited PLMN and a BM-SC in the home PLMN when the visited PLMN offers MBMS user services to roaming users. This user specific Mz signalling provides home PLMN authorisation for MBMS user services that are provided by the visited PLMN. This mechanism supports only MBMS user service classes that are offered by the visited and by the home PLMN.
§ Mz may use proxying capabilities as described for Gmb, e.g. to proxy signalling between BM-SCs. An APN may be included in the signalling between BM-SCs, which is used to select an appropriate GGSN to access the MBMS service aiming for an optimized routing, resource saving, or operator policy.
§ 3GPP TS 23.246 specifies that when MBMS bearers are used to provide MBMS user services to roaming users, three specific scenarios are used. One uses a GGSN in the Home PLMN, which is not related to Mz interface. The other two are enabled by use of the Mz interface for multicast services.
Mz Message:
§ The Diameter messages used in the Mz protocol, are the same as specified for Gmb interface: AAR Command, AAA Command, STR Command, STA Command, Abort-Session-Request Command and Abort-Session-Answer Command
§ To route Diameter messages from the visited PLMN to the home PLMN, the BM-SC in the visited PLMN shall derive the realm of the home PLMN from the user's IMSI.
§ The derived realm of the home PLMN shall be filled in the Destination-Realm AVP of messages sent from the visited PLMN to the home PLMN, i.e.
§ The Vendor-Id header of all Mz specific AVPs defined in the present specification shall be set to 3GPP (10415).
Mz specific Experimental-Result-Code AVP values
§ There are two different types of errors in Diameter; protocol and application errors.
§ Protocol error is one that occurs at the base protocol level, those are covered in the Diameter Base RFC 3588 specific procedures.
§ Application errors, on the other hand, generally occur due to a problem with a function specified in a Diameter application.
§ Diameter Base RFC 3588 defines a number of Result-Code AVP values that are used to report protocol errors and how those are used. Those procedures and values apply for the present specification.
沒有留言:
張貼留言