Enhanced Function supported for MBMS or E-MBMS:
1. MBMS Data Sources
2. eBM-SC (since
3. MCE (from LTE)
4. MBMS-GW (from LTE)
5. GGSN (as MBMS GW since
6. E-UTRAN eNB (from LTE)
7. GERAN/UTRAN (since
8. SGSN a (since
9. UE (since
10. Optional Network Elements Overview (CAMEL, CBC, OSA)
- The architecture allows for other MBMS broadcast/multicast data sources.
- Internal data sources may directly provide their data.
- Data delivery by external sources is controlled by Border Gateways (BG) which may allow for example data from single addresses and ports to pass into the PLMN for delivery by an MBMS service.
- The architecture assumes the use of IP multicast at the reference point Gi.
- The MBMS data source has only one connection to the IP backbone.
- The reference point from the content provider to the BM-SC is not standardised. It might become too complex or too restrictive for service creation.
- The same architecture provides MBMS broadcast services mainly by using the transport functions. The each user individual broadcast service is configured in the SGSN.
The Gmb reference point between BM-SC and GGSN enables the BM-SC to exchange MBMS service control information with the GGSN. BM-SC functional structure by using Gi (bearer/user plane) and Gmb (control plane) interfaces.
- The Broadcast-Multicast Service Centre (BM-SC) is an MBMS data source.
- MBMS data may be scheduled in the BM-SC, e.g. for transmission to the user every hour.
- It offers interfaces over that content provider can request data delivery to users.
- The BM-SC may authorize and charge content provider.
Broadcast-Multicast Service Centre (BM-SC)
- The BM-SC is a functional entity, which must exist for each MBMS User Service.
- The BM-SC provides functions for MBMS user service provisioning and delivery.
- It may serve as an entry point for content provider MBMS transmissions, used to authorize and initiate MBMS Bearer Services within the PLMN and can be used to schedule and deliver MBMS transmissions.
BM-SC should provide the following functions for MBMS:
- Authorization and authentication of content providers.
- Verify integrity of data received from content provider.
- Determine quality-of-service (QoS) for MBMS transmissions (within operator configured QoS bounds).
- MBMS data repetition and error resilient schemes to cope with possible transmission loss.
- Content provider charging.
- Support functions to allow a content provider to select from operator defined broadcast or multicast areas for a MBMS service.
- Be able to support several MBMS services taking into account their respective delivery constraints.
- Provide functions to produce service announcements for the UE.
- Provide functions to schedule MBMS data
- Be able to support one or more service providers
In addition, for EPS the BM-SC consists of the following additional functions (broadcast mode only):
- Content synchronization for MBMS in UTRAN.
- Content synchronization for MBMS in E-UTRAN.
- Header compression for MBSFN MBMS data.
The BM-SC consists of five sub-functions:
1. Session and Transmission function;
2. Service Announcement function;
3. Security function.
4. Proxy and Transport function;
5. Membership function;
BM-SC Functional Diagram: refer to
http://docs.google.com/View?id=ddh56dhg_113dmpm22fj
http://docs.google.com/View?id=ddh56dhg_115wfnvwtjj
(1). Session and Transmission Function
a). MBMS-based delivery function of data/content from the BM-SC to the UE over IP multicast or over IP unicast.
- The data/content is optionally confidentiality and/or integrity protected
- The data/content is optionally protected by an forward error correction code
b). Associated Delivery functions are invoked by the UE in relation to the MBMS data transmission. The following associated delivery functions are available:
- File repair for download delivery method used to complement missing data.
- Delivery verification and reception statistics collection procedures.
- The BM-SC Session and Transmission Function shall be able to schedule MBMS session transmissions.
- The BM-SC Session and Transmission Function allocates TMGIs.
- is user service level function and it triggers bearer level functions when MBMS sessions are scheduled
- shall be able to provide the GGSN with transport associated parameters such as quality-of-service and MBMS service area.
- shall be able to initiate and terminate MBMS bearer resources prior to and following transmission of MBMS data.
- should be able to send MBMS data. It could also apply favourable error resilient schemes e.g. specialized MBMS codecs or Forward Error Correction schemes.
- should be able to authenticate and authorize external sources and accept content from them.
- should be able to schedule MBMS session retransmissions, and label each MBMS session with an MBMS Session Identifier to allow the UE to distinguish the MBMS session retransmissions.
- Each transmission and subsequent retransmission(s) of a specific MBMS session are identifiable by a common MBMS Session Identifier (2-3 Octets) passed at the application layer in the content, and also passed in a shortened form. The full MBMS Session Identifier should be used by the UE to identify an MBMS session when completing point-to-point repair, while the shortened MBMS Session Identifier is included by the RANs in the notification messages for MBMS
- transfers the actual MBMS session data to the group of MBMS UEs using either MBMS Bearer Services or unicast bearer services.
- interacts with the GGSN through the Gmb Proxy function to activate and release the MBMS transmission resources.
- may compress headers of MBMS data in some cases.
- may need to add synchronization information for the MBMS payload e.g. in case of MBSFN transmissions.
- contains the MBMS delivery methods, which use the MBMS bearer service for distribution of content.
- contains a set of Associated-Delivery Functions may be invoked by the UE in relation to the MBMS data transmission (e.g. after the MBMS data transmission)
- MBMS user services data may be integrity and/or confidentiality protected as specified within 3GPP TS 33.246, and protection is applied between the BM-SC and the UE. This data protection is based on symmetric keys, which are shared between the BM-SC and the UEs accessing the service.
- MBMS user services may also be protected against packet loss between BM-SC and UE using a forward error correction code
(2). Service Announcement Function
a). User Service Discovery/Announcement provides service description material to be presented to the end-user as well as application parameters used in providing service content to the end-user. This includes information, which is necessary to initiate an MBMS user service
b). Interactive Announcement Function may offer alternative means to provide service descriptions to the UE using HTTP or be distributed through other interactive transport methods
- The Service Announcement Function is a user service level function.
- shall be able to provide service announcements for multicast and broadcast MBMS user services.
- shall be able to provide the UE with media descriptions specifying the media to be delivered as part of an MBMS user service (e.g. type of video and audio encodings).
- shall be able to provide the UE with MBMS session descriptions specifying the MBMS sessions to be delivered as part of an MBMS user service (e.g. multicast service identification, addressing, time of transmission, etc.).
- shall be able to deliver media and session descriptions by means of service announcements using IETF specified protocols over MBMS multicast and broadcast bearer services.
The following mechanisms should be supported for service announcement. Service announcements may be triggered by the BM-SC but are not necessarily sent by the BM-SC:
- MBMS bearer capabilities to advertise MBMS user Services;
- PUSH mechanism (WAP push);
- URL (WAP, HTTP);
- SMS (point-to-point);
- SMS-CB cell broadcast.
- Other mechanisms could be considered in future releases
(3). MBMS Security Function
a). Key Request and Registration procedure for receiving keys and key updates.
b). Key distribution procedures whereby the BM-SC distributes key material required to access service data and delivered content.
- MBMS user services may use the Security functions for integrity and/or confidentiality protection of MBMS data.
- The MBMS Security function (MBMS Key Management function) is used for distributing MBMS keys (Key Distribution sub-function) to authorized UEs.
- Before the UE can receive MBMS keys, the UE needs to register to the Key Request sub-function of the Key Management function by indicating the MBMS User
- In order for the UE to stop the BM-SC to send MBMS key updates a de-registration with the MBMS User Service Id is needed.
- If the MBMS User Service does not require any MBMS data protection, then the UE shall not register for key management purposes.
- Description of the security functions and key management procedures are provided in TS 33.246
(4). Proxy and Transport Function
- The
- The BM-SC Proxy and Transport Function is an MBMS bearer service function
- is a Proxy Agent for signalling over Gmb reference point between GGSNs and other BM-SC sub-functions, e.g. the BM-SC Membership Function and the BM-SC Session and Transmission Function.
- shall also be able to handle when BM-SC functions for different MBMS services are provided by multiple physical network elements. Routing of the different signalling interactions shall be transparent to the GGSN.
- shall be able to generate charging records for content provider charging of transmitted data. Content provider name is provided to BM-SC Proxy and Transport function over Gmb at session start.
- may act as an intermediate device for the MBMS data sent from the BM-SC Session and Transmission function to the GGSN.
- may be divided further into a Proxy function managing the control plane (Gmb) and a Transport function managing the multicast payload (Gi).
(5). Membership Function
- The Membership function is used to verify if a user is authorized to register, receive keys or to establish a MBMS bearer for MBMS Multicast Mode.
- The Membership function is defined only for MBMS Multicast Mode in TS 23.246
- The BM-SC Membership function provides authorization for UEs requesting to activate an MBMS service.
- is an MBMS bearer service level function, but it may also provide user service level functions e.g. membership management etc. It does also have a Gi interface
- may have subscription data of MBMS service users.
- may generate charging records for MBMS service users.
Other 1: Content Provider / Multicast Broadcast Source Function:
- The Content Provider/Multicast Broadcast Source function may provide discrete and continuous media, as well as service descriptions and control data, to the BM-SC to offer services at a time.
- may be a 3rd Party Content Provider/Multicast Broadcast Source.
- may reside within the operator's network or may be provided from outside the operator's network. The Content Provider/Multicast Broadcast Source can also configure the Session and Transmission functions (e.g. delivery or associated delivery).
- The interface between the Content Provider/Multicast Broadcast Source and the BM-SC is to be studied and defined further.
- An MBMS User Service may use one or several MBMS delivery methods simultaneously.
Other 2: MBMS UE (receiver function)
- The MBMS UE hosts the MBMS User Services receiver function.
- The MBMS receiver function may receive data from MBMS bearer services or from unicast bearer services.
- The MBMS receiver function may receive data from several MBMS User Services simultaneously.
- According to the MBMS UE capabilities, some MBMS UEs may be able to receive data, belonging to one MBMS User Service from several MBMS Bearer Services simultaneously. The MBMS receiver function uses interactive bearers for user service initiation / termination, user service discovery and associated delivery procedures.
- In case the MBMS user service is secured, the UE needs one or more cryptographic MBMS service keys, therefore the UE requests the relevant cryptographic MBMS service keys using the BM-SC Key Request function.
- The received keys (i.e. MSK) are then used for securing the MBMS session.
- Security and Key Management will be studied further and later.
Multi-cell/multicast Coordination Entity (MCE)
- 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.
The MCE is a logical entity whose functions are
- the allocation of the radio resources used by all eNBs in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation.
- Besides allocation of the time/ frequency radio resources this also includes deciding the further details of the radio configuration e.g. the modulation and coding scheme.
- The MCE is involved in MBMS Session Control Signaling. The MCE does not perform UE - MCE signaling.
E-MBMS Gateway (MBMS GW) Overview
- One or more MBMS GW function entities may be used in a PLMN.
Note that MBMS GW may be stand alone or co-located with other network elements such as BM-SC or combined S‑GW/PDN GW.
- 3GPP has currently assumed that header compression for MBMS services will be performed by the E-MBMS gateway
The MBMS GW is a logical entity between the BMSC and eNBs whose principal functions are
- the sending/broadcasting of MBMS packets with the SYNC protocol to each eNB transmitting the service.
- The MBMS GW hosts the PDCP layer of the user plane and uses IP Multicast as the means of forwarding MBMS user data to the eNB.
- The MBMS GW performs MBMS Session Control Signaling (Session start/stop) towards the E-UTRAN.
- MBMS GW supports fall back to point to point mode where applicable for UTRAN access;
- In case of mobility in or out from an MBMS service area, the service continuity is handled by the Service Layer (in UE and network).
MBMS GW User and Control Plane:
- It provides an interface for entities using MBMS bearers through the SGmb (control plane) reference point;
- This IP Multicast address is provided to the eNodeB via MME and to the RNC via SGSN;
- It allocates an IP Multicast address to which the eNodeB/RNC should join to receive the MBMS data.
- MBMS GW can communicate with multiple control plane entities (i.e. MME, SGSN and BM-SCs)
- It provides an interface for entities using MBMS bearers through the SGi-mb (user plane) reference point;
- IP multicast distribution of MBMS user plane data to eNodeBs (M1 reference point);
- IP multicast distribution of MBMS user plane data to RNCs (M1 reference point);
- The GGSN terminates the MBMS GTP tunnels from the SGSN and links these tunnels via IP multicast with the MBMS data source.
- The GGSN role within the MBMS architecture is to serve as an entry point for IP multicast traffic as MBMS data.
- Upon notification from the BM-SC, the GGSN shall be able to request the establishment of a bearer plane for a broadcast or multicast MBMS transmission.
- Upon BM-SC notification, the GGSN shall be able to tear down the established bearer plane. Bearer plane establishment for multicast services is carried out towards those SGSNs that have requested to receive transmissions for the specific multicast MBMS bearer service.
- The GGSN shall be able to receive MBMS specific IP multicast traffic and to route this data to the proper GTP tunnels set-up as part of the MBMS bearer service.
The functions a GGSN could provide for MBMS are:
- Most of the GGSN functions described below do not add any functionality useful for MBMS. Only for provision of HPLMN MBMS services to roaming users a GGSN is added to the architecture. The same approach is used for provision of MBMS services within one PLMN to avoid two different architectures.
1. Message Screening
2. Charging Data Collection
3. Mobility management
4. Tunnelling of data
5. Service (QoS) negotiation
6. Policing
- Message screening is not needed if the MBMS sources are internal in the PLMN or it is provided by the BM-SC or the BG which are gateways to external MBMS data sources.
- Charging data may be collected for the MBMS data sources. But, the potential existing sources like ESS or MMS provide charging information and very likely also the BM-SC. User individual charging information is collected by the SGSN. It is not favourable to keep user individual contexts per multicast service in the SGSN and in the GGSN in parallel under the assumption that such user individual contexts are stored as long as the user is attached.
- The mobility management of the GGSN can not support MBMS as the GTP tunnels would be fixed. These tunnels are used by multiple UEs in parallel and can not move with UEs.
- The tunnelling seems the most important GGSN function for MBMS. It allows the provision of HPLMN MBMS multicast services to users roaming in a VPLMN. The tunnelling separates the traffic of the different MBMS services from each other and allows therefore the use of the same addresses in HPLMN and VPLMN. A co-ordination of addresses between different PLMNs is not needed.
- Service (QoS) negotiation: A GGSN could simplify O&M when used to provide the parameters for the individual MBMS services at the service negotiation when the GTP tunnels are established.
- Policing: The GGSN could police the traffic of the individual MBMS services. But most MBMS data sources are allocated within the PLMN and therefore under control of the operator. In addition, the QoS profile is very likely configured on the SGSN. And the RAB will limit the possible throughput to the maximum bit-rate and inherently police the traffic.
The GGSN may also provide features that support the MBMS bearer service that are not exclusive to MBMS. Examples are:
- Message Screening (not needed if the MBMS sources are internal in the PLMN);
- Charging Data Collection;
- Flow Based Charging
MBMS control & functions in E-UTRAN (eNB)
- The E-UTRAN supporting MBMS comprises eNBs and coordinating functions.
The functions hosted by the eNB may be:
- Scheduling and transmission of MBMS control information;
- Scheduling of single-cell MBMS transmissions;
- Transmission of single-cell and multi-cell MBMS services;
- Radio bearer control for MBMS.
The coordinating functions in multi-cell may include:
- Distribution of MBMS services;
- Coordination of multi-cell MBMS transmissions;
- MBMS E-RAB control.
The radio access network (UTRAN/GERAN) shall provide the following functionality for efficient support of MBMS for Multicast Mode
- responsible for establishment of point to multipoint or point to point channels on the air interface to support MBMS.
- capable of routing MBMS traffic over either a point to multipoint channel or over a point to point channel.
- capable of discovering the number of MBMS users within a cell
- makes the decision to select channel type (point to multipoint or point to point) based on the number of users within a cell receiving MBMS service. The threshold value for this is operator defined
UTRAN/GERAN
- responsible for efficiently delivering MBMS data to the designated MBMS service area.
- Efficient delivery of MBMS data in multicast mode may require mechanisms in the UTRAN/GERAN, e.g. the number of users within a cell prior to and during MBMS transmission could be used to choose an appropriate radio bearer.
- The UTRAN/GERAN shall support the initiation and termination of MBMS transmissions by the core-network. The UTRAN/GERAN shall be able to receive MBMS data from the core-network over Iu bearers shared by many UEs.
- The UTRAN/GERAN shall support both intra-RNC/BSC and inter-RNC/BSC mobility of MBMS receivers. Mobility is expected to cause limited data loss. Therefore, MBMS user services should be able to cope with potential data loss caused by UE mobility.
- The UTRAN/GERAN shall be able to transmit MBMS user service announcements, paging information (non MBMS specific) and support other services in parallel with MBMS (for example depending on terminal capabilities the user could originate or receive a call or send and receive messages whilst receiving MBMS video content)
After activation of a MBMS service, the UE shall be able to receive MBMS data without explicit user request.
- UEs, which store MBMS data, may have functionality for DRM (Digital Rights Management).
- The UE shall be able to receive indications for other services e.g. paging in CS. However, this may create losses for which the MBMS applications shall cope with.
- The UE shall allow reception of MBMS service announcements while receiving MBMS data.
- The UE shall provide the functions to activate/deactivate MBMS data reception.
- The UE should support security functions for the provision of MBMS service.
User Equipment
- The UE shall support functions for the activation/deactivation of the MBMS bearer service.
- Once a particular MBMS bearer service is activated, no further explicit user request is required to receive MBMS data although the user may be notified that data transfer is about to start.
- The UE shall support security functions as appropriate for MBMS.
- The UE should, depending on terminal capabilities, be able to receive MBMS user service announcements, paging information (non MBMS specific) and support simultaneous services.
- The UE shall be able to synchronise with the SGSN, which of its MBMS UE contexts are still active.
- Depending upon terminal capability, UEs may be able to store MBMS data. This may involve DRM.
- The MBMS Session Identifier contained in the notification to the UE shall enable the UE to decide whether it needs to ignore the forthcoming transmission of MBMS session (e.g. because the UE has already received this MBMS session)
The UE shall offer the following functions to applications:
- The UE shall support functions for the activation/deactivation of the MBMS bearer service.
- TE request to perform MBMS broadcast activation for a given broadcast service and to receive service related data.
- TE request to perform MBMS multicast activation (join) for a given multicast service and to receive service related data.
- TE request to perform MBMS broadcast deactivation for an activated broadcast service and to cease service-related data reception.
- TE request to perform MBMS multicast deactivation for an activated multicast service and to cease service related data reception.
- All these functions may be used in an MBMS architecture (potentially with modifications) and perform for user individual control of MBMS multicast services, i.e. to activate, deactivate, authorize, ... the MBMS services for individual users.
- concentrates all individual users of the same MBMS service into a single MBMS service
- maintains a single connection with the source of the MBMS data
- The mechanisms for provision of RABs on demand when data is to transfer may need extensions to provide shared resources for MBMS.
SGSN
- The SGSN's role within the MBMS architecture is to perform MBMS bearer service control functions for each individual UE and to provide MBMS transmissions to UTRAN/GERAN.
- The SGSN shall provide support for intra-SGSN and inter-SGSN mobility procedures. The SGSN is to store a user-specific MBMS UE context for each activated multicast MBMS bearer service and to pass these contexts to the new SGSN during inter-SGSN mobility procedures.
- The SGSN shall be able to indicate its MBMS support to the UE as well as it shall be able to synchronise with the UE, which of the UE's MBMS UE contexts are still active.
- The SGSN shall be able to generate charging data per multicast MBMS bearer service for each user. The SGSN does not perform on-line charging for either the MBMS bearer service or the MBMS user service (this is handled in the BM-SC).
- The SGSN shall be able to establish Iu and Gn bearers shared by many users upon receiving a session start from the GGSN. Likewise, the SGSN shall be able to tear down these bearers upon instruction from the GGSN.
- When MBMS in EPS for UTRAN access is supported, the SGSN shall support the necessary control plane functions provided via Sn interface to/from MBMS GW in LTE (Sn: MBMS-GW --- SGSN)
A number of functions provided by the SGSN for ptp bearer services may be used to provide MBMS:
- The SGSN authenticates users based on subscription data from HLR
- The SGSN authorises the usage of services/resources based on subscription data from HLR
- The SGSN provides user individual service control (ptp services)
- The SGSN provides user individual mobility management
- The SGSN may limit the service area per individual user
- The SGSN stores contexts per activated service per individual user
- The SGSN generates charging data per service for each user
- The SGSN provides CAMEL functions (e.g. prepaid)
- The SGSN establishes RABs on demand when data has to be transferred to the users
- The SGSN may use CAMEL to handle pre-paid services, e.g. credit checking for on-line charging.
- The Cell Broadcast Centre (CBC) may be used to announce MBMS services to the users. How this is accomplished is FFS.
- The BM-SC may use OSA-SCS to interact with third parties.
沒有留言:
張貼留言