1.1. Subscription in Multicast
During the lifetime of subscription to a Multicast Service it shall be possible for the user to declare the service preferences.
- Multicast Subscription Group: A group of users who are subscribed to a certain MBMS in multicast mode and therefore authorised to join and receive multicast services associated with this group.
- Multicast group: A group of users that have an activated MBMS in multicast mode and therefore are ready to or are receiving data transmitted by this service. The multicast group is a subset of the Multicast subscription group.
- Multicast subscription: The process by which a user subscribes or is subscribed to a multicast subscription group and thereby is authorised to join certain multicast services. Multicast subscription is performed either upon user selection or due to home environment initiation.
Subscription Overview:
- The user subscribes or is subscribed to a multicast subscription group which is uniquely identified and thereby becomes a member of that group. The subscription may be continuous (e.g. as defined by the subscriber's contract), time-limited, or generated by the subscriber on a one-time basis. The subscription to multicast services shall not be further standardized.
- Subscription establishes the relationship between the user and the service provider, which allows the user to receive the related MBMS multicast service
- Service Subscription is the agreement of a user to receive service(s) offered by the operator.
- The phases subscription - joining and leaving - are performed individually per user.
- Also subscription, joining, leaving, service announcement as well as MBMS notification may run in parallel to other phases.
- Service Subscription can be done anytime before or after Service announcement.
- The user discovers, or becomes aware (e.g. via service announcements), that there are multicast services currently active, or multicast services that will become active at some time later, at the user's current location.
- The user selects a multicast service and hence the user joins the corresponding multicast group. The user should be able to join a multicast service as soon as possible after announcement of the service.
Subscription Information:
- Subscription information is recorded in the BM-SC.
- Subscription information and other BM-SC functionality may be on separate entities, which is enabled by proxy capability of the Gmb interface.
- It shall be possible for the network to store the user settings (Subscription) e.g. using GUP.
Subscription in BM-SC, SGSN, GGSN, HLR
- The Membership function in BM-SC may have subscription data of MBMS service users, and is used to verify the subscription information in MBMS Multicast Mode
- The SGSN authenticates users based on subscription data from HLR and authorises the usage of services/resources based on subscription data from HLR, and performs a subscription check for the requested MBMS multicast service identified by the IP multicast address and APN or whether another network entity performs this check before the SGSN creates an UE specific MBMS context.
- Also the GGSN or another network entity may perform a subscription check for the requested MBMS multicast service identified by the IP multicast address and APN.
- Third parties and VASP should not be aware about user IDs for MBMS subscriptions unless explicitly allowed by the operator.
Subscription from UE or HE
- The UE starts receiving the multicast data associated with the multicast group(s) it has joined
- The user may choose to stop receiving a selected multicast service and thereby leaves the multicast group. The user may also select to continue (or not) to receive service announcements for this multicast subscription group.
- The user may unsubscribe or be unsubscribed from the multicast subscription group and stop receiving both the multicast data and future service announcements for this multicast subscription group.
- The Home Environment can join the user to the selected multicast group on behalf of the user, that has previously subscribed to this multicast group.
- The home environment shall be able to remove a user from a multicast group (deactivation) and if required remove the subscriber from the multicast subscription group (un-subscription).
- This is required to allow the operator to bar service.
The MBMS User Service shall support the following charging mechanisms:
The user service shall be charged either by subscription or as a one time event charge (e.g. key management).
- Charging on a subscription basis
- Charging for keys that that allow the user access to the data
- Subscription Id: described in TS 32.299 and as a minimum the IMSI and the MSISDN have to be included for subscriber charging.
1.2. Service Discovery and Announcement
Service Announcements/Discovery: The mechanisms should allow users to request or be informed about the range of MBMS services available
MBMS user service discovery/announcement:
- The user service discovery refers to methods for the UE to obtain the list of available MBMS user services along with information on the user service, and
- The user service announcement refers to methods for the MBMS service provider to make the list of available MBMS user services along with information on the user service available to the UE
- User Service Discovery/Announcement providing service description material to be presented to the end-user as well as application parameters used in providing service content to the end-user.
- The service description information may be delivered via the Session and Transmission function or via the Interactive Announcement function in BM-SC. This includes information, which is necessary to initiate an MBMS user service
The
- provides all necessary information about available services and needed parameters to become member of a service. User Service Discovery / Announcement mechanism can provide information on available MBMS User services
§ in pull mode, via the Web or WAP Portals, or
§ in push mode, via SMS or MBMS Download based User Service.
- provides all necessary information for the
- Service Discovery includes DRM/Security descriptions.
Service Discovery Mechanisms
- Operators/Service Providers may consider several service discovery mechanisms. This could include standard mechanisms such as SMS, or depending on the capability of the terminal, applications that encourage user interrogation. Users who have not already subscribed to a MBMS service should also be able to discover MBMS services.
- The method chosen to inform users about MBMS services may have to account for the users location, (e.g. current cell, in the HPLMN or VPLMN). Users who have not already subscribed to a MBMS service should also be able to discover MBMS services.
- The following could be considered useful for MBMS service discovery mechanisms (not exhaustive): -
- SMS -CB
- MBMS Broadcast mode to advertise MBMS Multicast Services
- PUSH mechanism (WAP, SMS-PP)
- Web URL
UE capabilities described in documents for Service Discovery:
- A set of PSS and MBMS UE capabilities is required to personalize and operate PSS and MBMS user services. These capabilities are described in 2 documents:
- The PSS and MBMS UE Capabilities XML document defined in Annex G of TS 26.237.
- The RDF/XML document for the PSS base vocabulary specified in Annex F of TS 26.234.
- These 2 documents are sent during the Service Discovery procedure
User Service Discovery/Announcement Procedure (in 26.346)
- User Service Announcement over a MBMS bearer
- User Service Announcement using Interactive Announcement Function
- User Service Announcement over point-to-point push bearers
- Metadata Fragment Encapsulation to aggregate Service Announcement Documents
- Registration and Deregistration Procedure for MBMS User Service Consumption
SDF: Service Discovery Function (SDF):
This function provides an entry point to SSF for the IMS client to attach to the service provided by the service provider.
1.3. Service Initiation and Termination
- MBMS shall be able to authorize this service provision (Authentication and Authorization of Content Provider) with the requested parameters prior to service initiation.
- MBMS user service initiation: MBMS user service initiation refers to the UE mechanism to set up the reception the MBMS user service data. The initiation procedure takes place after the discovery of the MBMS user service.
- For MBMS User service activation, the UE needs to perform a security function and the MBMS Bearer Service activation procedures.
- In the case of MBMS Multicast Mode, an IGMP or MLD message is sent via a
- In the case of MBMS Broadcast Mode, network-side elements establish the MBMS BS context without requiring user initiated messaging.
UE: The UE contains an GBA/IMS/PSS/MBMS client, which performs service discovery and selection, handles service initiation, modification and termination, receives and present the content to the user.
- The PSS & MBMS client, located in the UE, performs service selection and initiation, receives and present the content to the user.
- The UE shall be able to enable and disable broadcast service reception.
- The UE shall be able to join and leave multicast groups.
- Roaming users should be able to join and leave multicast groups in the home or visited network.
User Service Initiation/Termination Procedure (in 26.346)
- Initiation of MBMS Bearer Service based Services
- Termination of MBMS Bearer Service based Services
- Initiation of Unicast Bearer Service based Services
- Termination of Unicast Bearer Service based Services
- Scalable Service Initiation and Termination for MBMS Services
Service Deactivation of the MBMS service in the BM-SC shall result in the CDR (S-BMSC-CDR) being closed. The trigger condition covers:
- UE initiated deactivation;
- termination of the MBMS User Service
- any abnormal release.
Service Deactivation of the MBMS service in the BM-SC shall result in the CDR (C-BMSC-CDR) being closed. The trigger condition covers:
- MBMS Session Stop;
- termination of the MBMS User Service
- any abnormal release.
1.4. Notification Mechanism and required capabilities
- MBMS Notification: The mechanism, which informs the UEs about the availability or coming availability of a specific MBMS RAB data in one given cell and informs the UEs about forthcoming (and potentially about ongoing) MBMS broadcast or multicast data transfer
- Dedicated MBMS Notification: A mechanism in the network that allows the network to notify mobile stations in dedicated mode of starting MBMS multicast sessions.
- While receiving PS or CS services, it shall be possible for the user to receive notification of MBMS multicast sessions.
- 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)
- Session Start may be triggered by an explicit notification from the BM-SC
- 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
- Temporary Mobile Group Identity (TMGI) is used for MBMS notification purpose
- 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. Further, upon BM-SC notification the GGSN shall be able to tear down the established bearer plane.
- The GGSN receives the IGMP Join request from UE and sends an MBMS notification request to the SGSN. The SGSN sends an MBMS Notification Response to the GGSN that sent the MBMS Notification Request.
- A notification procedure shall be used to indicate the start of MBMS data transmission. This procedure shall contain MBMS RB information. (See Procedure Section later)
- The UE capabilities (e.g. memory size) required to receive a particular transmission shall be notified in advance by the network or service centre.
The following requirements for MBMS notification mechanism(s) have been identified and currently agreed:
1 MBMS notification shall be transmitted within the MBMS service area.
2 MBMS notification shall be sent so it could be received by all UEs with an activated MBMS service, regardless of their RRC state or the lack of an RRC connection.
3 MBMS notification should maximise the reuse of existing channels.
4 MBMS notification should allow terminals to minimise their power consumption, meaning that UEs with an activated MBMS service should not listen permanently, but at regular intervals to MBMS notification.
5 Reception of MBMS notification cannot be guaranteed.
6 UEs may receive MBMS notification and simultaneously monitor other occasions, e.g. UE dedicated paging and CBS messages. The avoidance of collisions cannot be guaranteed. If collisions occur, the UE dedicated Paging has higher priority (UE requirement)
1.5. Efficient Routing and Resource Usage
- The MBMS shall be able to efficiently route multicast and broadcast over the radio interface and within the radio network.
- Efficient routing within the core-network is desired as well.
- In Multicast mode, MBMS should support multicast resource allocation where-by data transmission to a multicast group is carried out in certain cell only if multicast group members are to be found in that cell.
- Hierarchically structured networks can provide coverage for a given location using multiple carrying frequencies or multiple cells of varying sizes.
- Provisioning and efficient delivery of MBMS services within hierarchical network architectures should be considered.
1.6. Pre-Delivery verification
- It is required that the operator can verify the number of active MBMS users when service commences.
- The UE shall provide a secure means to inform the network of the start of services by pre-delivery verification transmitted over a point-to-point connection to the home/visited network. This pre-delivery verification may be relayed to the service provider.
- The pre-delivery verification shall also support the carriage of bearer specific non-real time information, i.e. previously stored in the UE, to the BM-SC. Such bearer specific information may, for example, include historic C/I measurements for the serving cell.
- It should be noted that pre-delivery verification by point-to-point mechanisms partially reduces the resource-efficiency of the underlying broadcast services. Sacrificing resource-efficiency due to requirements of UE reporting may be necessary but should be kept as minimal as possible to minimize congestion.
1.7. Delivery verification
- For some MBMS user services it is required that the operator can verify that the content conveyed by the service has been received by the UE.
- The UE shall provide a secure means to provide such delivery verification transmitted over a point-to-point connection to the home/visited network. This delivery verification may be relayed to the service provider.
- The delivery verification shall also support the carriage of bearer specific non-real time information, i.e. previously stored in the UE, to the BM-SC. Such bearer specific information may, for example, include historic C/I measurements for the serving cell.
- It should be noted that delivery verification by point-to-point mechanisms partially reduces the resource-efficiency of the underlying broadcast services. Sacrificing resource-efficiency due to requirements of UE reporting may be necessary but should be kept as minimal as possible to minimize congestion.
1.8. MBMS Session Management (MBMS-SM) – Session Start and Stop
To be completed later
1.9. Service Interworking
- shall be able to manipulate content delivered over MBMS and forward it using other services (e.g. MMS, Speech Call- and IMS signalling, Hyperlinks, ….).
- should be taken in order to fulfil requirements concerning DRM and respective barring and charging capabilities.
- When interacting with user profiles, MBMS User Services shall use the mechanisms via GUP described in TS 22.240 (Generic User Profile).
1.10. User Profile description for PSS and MBMS
§ The PSS and MBMS user profile data contains all information required to operate PSS and MBMS user services.
§ The part of the PSS & MBMS user profile used for On Demand (CoD in TISPAN) and Live (BC in TISPAN) services shall be as defined in TISPAN TS 183 063, Annex C.
1.11. Information Storage for MBMS (UE) Context and MBMS Bearer Context
§ MBMS Context
§ In MBMS it is necessary for the SGSN and GGSN to maintain data for each UE that has requested to join each Multicast service the MBMS context. This context information is passed from one SGSN to another during inter-SGSN Routing Area Update procedure and Inter SGSN SRNS relocation procedures.
The MBMS (UE) Context information includes:
§ IP Multicast Address.
§ APN. (Access Point Name)
§ TMGI. (Temporary Mobile Group Identify)
§ Linked NSAPI. (Network Service Access Point Identifier)
§ TI. (Transaction Identifier)
§ MBMS NSAPI.
§ This context information is derived from the MBMS Context Activation procedure.
§ Hence the CN is required to store this information as described in 3GPP TS 23.246 [3], but it has no impact on the SM procedures over and above those defined for the MBMS context activation procedure.
MBMS Bearer Context
§ The MBMS Bearer Context contains all information describing a particular bearer of a Multicast service and is created in each node involved in the delivery of the MBMS data.
§ An MBMS Bearer Context is created in the SGSN and GGSN when the first MBMS Context is created in the node or when a downstream node requests it. An MBMS Bearer Context, once created, can be in one of two states (Standby or Active) reflecting the activity status of the corresponding MBMS bearer.
§ 'Active' reflects the state of an MBMS Bearer Context in which user plane resources are established in the network for the transfer of MBMS data. This state is maintained as long as there is data pending for a corresponding MBMS session.
§ 'Standby' reflects the state of an MBMS Bearer Context in which no user plane resources are established in the network for the transfer of MBMS data. This state is maintained as long as there is data pending for a corresponding MBMS session.
The MBMS Bearer Context information can include, dependent on state:
§ IP Multicast Address.
§ APN. (Access Point Name)
§ TMGI. (Temporary Mobile Group Identify)
§ State.
§ QoS (if Active state).
§ MBMS Service Area (if Active state).
§ List of Downstream Nodes.
§ Number of UEs per RA list (SGSN only, Optional). (RA = Routing Area)
§ Required MBMS Bearer Capabilities.
§ Number of UEs.
1.12. Digital Rights Management - DRM
The MBMS User Service shall be able to control content distribution as defined in 3GPP TS 22.242. MBMS content providers shall be able to invoke DRM to prevent unauthorized copying and forwarding of content.
§ The traffic for a particular MBMS User Service may require some protection depending on the sensitivity of the data being transmitted (e.g. it is possible that the data being transmitted by the MBMS User Service is actually protected by the DRM security method and hence might not require additional protection. However, MBMS protection is independent of DRM protection).
§ If this DRM protection is required, it will be either confidentiality and integrity or confidentiality only, or integrity only. The protection is applied end-to-end between the BM-SC and the UEs and will be based on a symmetric key shared between the BM-SC and the UEs that are currently accessing the service.
§ The actual method of protection specified may vary depending on the type of data being transmitted, e.g. media streaming application or file download.
§ Service Discovery includes DRM/security descriptions.
§ DRM may be applicable to User Charging, and should be taken in order to fulfil requirements concerning DRM and respective barring and charging capabilities.
§ UEs stores MBMS data and may have functionality for DRM (Digital Rights Management).
§ Usage of OMA DRM DCF (DRM Content Format) – to be studied later
沒有留言:
張貼留言