MBMS OV - (15) UE Requirements and Functions in MBMS

1.1. UE Function Overview in MBMS

Terminal Equipment

- 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.

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 - shall offer the following functions to applications:

- 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 (for example the user can originate or receive a call or send and receive messages whilst receiving MBMS video content). Reception of this paging or announcements may however, create losses in the MBMS data reception. The MBMS user service should be able to cope with such losses.

- 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, but 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)

1.2. UE Capability for PSS and MBMS

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

1.3. UEs Counting with activated MBMS service(s) within a cell

- Identification of the number of UEs with activated MBMS service(s) in a cell

- Some architectural solutions for MBMS require that the RAN can identify (counting) the number of UEs (or at least whether a minimum number of UEs) that have activated particular MBMS services are present in a cell.

- This function may be used, in conjunction with discontinuous MBMS services, to identify whether the service should be established in the cell and whether p-t-p or p-t-m radio access bearers should be used.

1.4. Identification of MBMS parameters to UEs

- The RAN shall provide mechanisms whereby the RAN indicates to the UE the physical, transport and logical channel parameters that are associated with radio bearers that carry specific MBMS data streams within specific cells.

1.5. Alerting UEs that MBMS data is to be transmitted

- For discontinuous MBMS services radio bearers may be established only during those periods when there is data to be transferred.

- The RAN shall be required to alert the UE that the service is about to be re-established.

1.6. Power control

- The power level shall be set for p-t-p and p-t-m bearers.

1.7. Content Storage in the UE

- It shall be possible for the UE to store content delivered to it over MBMS and provide it to the user at a later time.

1.8. Time synchronization between the BM-SC and MBMS UEs

- A number of MBMS metadata fragments and File Delivery Table (FDT) contain NTP encoded time values.

- NTP uses UTC as reference time and is independent from time zones.

- In order to process the time information from the BM-SC correctly, the MBMS UEs shall be time synchronized with the BM-SC with a UE tolerance of 10 seconds.

- The BM-SC shall offer an SNTP time server.

- The MBMS UEs should use SNTP to synchronize the time with the BM-SC.

- The MBMS UE should not use the SNTP time synchronization service more often than once in 30 days to avoid scalability issues.

- The BM-SC shall support the SNTP anycast mode.

- An anycast client in the MBMS UE sends a request to a designated IPv4 or IPv6 local broadcast address or multicast group address.

- One or more SNTP anycast servers reply and include a timestamp with their current time and its precision.

- BM-SC SNTP servers shall only respond if they have a valid synchronisation time and shall not leave the timestamp blank, such that the SNTP Leap Indicator (LI) field shall not use the value 3 (warning: unsynchronised).

- Any MBMS SNTP client shall perform use the anycast mode each time it performs SNTP synchronisation; the client does not need to keep server address state data and changes in the SNTP server addressing will not effect each subsequent synchronisation operation.

- For IPv4, the IANA has assigned the multicast group address 224.0.1.1 for NTP, which is used both by multicast servers and any cast clients.

- For IPv6, the IANA has assigned the multicast group address FF0X:0:0:0:0:0:0:101.

- These NTP assignments apply to SNTP usage as well.

- The SNTP server will join these IP Multicast groups

1.9. MBMS UE Context (23.246)

- The MBMS UE Context contains UE-specific information related to a particular MBMS bearer service that the UE has joined.

- An MBMS UE Context is created in the UE, SGSN, GGSN and BM-SC Membership function when the UE joins an MBMS bearer service.

- In the SGSN, an MBMS UE Context is also created as a result of an inter-SGSN routing area update after the transfer of the MBMS UE Context from the old SGSN.

- In Iu mode, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism to the BSC/SRNC at least when the first PS RAB is established for the UE, or when the UE performs MBMS Multicast Service Activation.

- MBMS UE Contexts are provided to the Iu mode BSC/SRNC regardless whether MBMS Sessions are ongoing or not (i.e. before, between and after Sessions).

- In addition, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism when a UE, which has an MBMS UE Context active, moves to PMM-Connected state via the MBMS Service Request procedure for the purpose of MBMS.

- In the UE and SGSN, the MBMS UE Context is stored as part of the MM Context for the UE.

- The MBMS UE Context is stored in the GGSN (as MBMS GW).

- There is one MBMS UE Context per MBMS bearer service that the UE has joined.

- In the Iu mode BSC/RNC, the MBMS UE Contexts are stored as part of the UE Context of the BSC/RNC.

§ Table 1: MBMS UE Context

Parameter	Description	UE	SGSN	GGSN	RNC	BSC	BM-SC
IP multicast address	IP multicast address identifying an MBMS bearer that the UE has joined.	X	X	X	X	Iu - X Gb - none	X
APN	Access Point Name on which this IP multicast address is defined.	X	X	X	X	Iu - X Gb – none	X
GGSN Address in Use	The IP address of the GGSN currently used		X
SGSN address	The IP address of SGSN			X
TMGI	Temporary Mobile Group Identity allocated to the MBMS bearer.	X	X		X	Iu - X Gb – none
RAI	The Routing Area Identity		(5)
Linked NSAPI	NSAPI of the PDP context used by the UE to carry IGMP/MLD signalling.	X	X
IMSI	IMSI identifying the user.	(1)	(1)	X	(2)	Iu – (2) Gb – (3)	X
TI	Transaction Identifier	X	X
TEID for Control Plane	The Tunnel Endpoint Identifier for the control plane between SGSN and GGSN.		X	X
MBMS_NSAPI	Network layer Service Access Point Identifier which identifies an MBMS UE Context.	X	X	X	X
Additional MBMS Trace Info	Identifies additional information required to perform trace.		(4)	(4)			(4)
Trace Reference	Identifies a record or a collection of records for a particular trace.		(4)	(4)	(4)	(4)
Trace Type	Indicates the type of trace.		(4)	(4)	(4)	(4)
Trigger Id	Identifies the entity that initiated the trace.		(4)	(4)	(4)	(4)
OMC Identity	Identifies the OMC that shall receive the trace record(s).		(4)	(4)	(4)	(4)
(1) In the UE and SGSN, the IMSI is available within the MM Context which contains the MBMS UE Context. (2) The IMSI is available within the UE Context which contains the MBMS UE Context. (3) IMSI availability does not depend on MBMS. (4) Trace parameters are only stored if trace is activated. (5) RAI is available within the MM Context of the UE.

1.10. MBMS UE Context Synchronization (23.246)

- The Routing Area Update procedure transfers the MBMS UE Context status between UE and SGSN.

- This MBMS UE Context status identifies MBMS UE contexts, which are lost or deactivated only on one side.

- All MBMS UE Contexts, which are active on one side only shall be deactivated locally.

- If the UE wishes to re-activate the related MBMS bearer service, it shall join the MBMS bearer service again.

1.11. MBMS UE Architecture for Security and Key Management

- It is assumed that the UE includes a secure storage (MGV-S).

- This MGV-S may be realized on the ME or on the UICC.

- MGV-S stores the MBMS keys

- In particular in ME based key management, it shall be ensured that the keys are not exposed to unprotected parts of the ME when they are transmitted from the UICC to the MGV-S or during the key derivations.

- The MGV-F is implemented in a protected execution environment to prevent leakage of security sensitive information such as MBMS keys.

- MGV-F performs the functions that should not be exposed to unprotected parts of the ME.

- MGV-S = MBMS key Generation and Validation Storage

- MGV-F = MBMS key Generation and Validation Function

Overview of ME-based and UICC-based key managements in UE is described in figures below.

1). For ME based key management:

- All MBMS keys (MUK, MRK, MSK and MTK) shall be deleted from the ME when a different UICC or SIM is inserted.

- Therefore the ME needs to store in non-volatile memory the last inserted UICC or SIM identity to be able to compare that with the used UICC or SIM identity at card insertion and power on.

- All MBMS keys (MRK, MSK and MTK) may be deleted from the ME when the ME is powered down.

- If the ME does not delete the MBMS keys at power down, then the MBMS keys need to be stored in non-volatile memory.

- The ME should store the MUKs in non-volatile memory in order to be able to authenticate the first MIKEY message of a BM-SC solicited pull procedure

- If the ME deletes the MSK at power down, then the MBMS client would need to request MSK to the BM-SC and may need to run GBA to reconvene an MBMS session.

- GBA_ME = ME-based GBA

- GBA_U = GBA with UICC-based enhancements

- Ks_NAF = Derived key in GBA_ME of 3G GBA or in 2G GBA

- A UICC that contains MBMS key management functions shall implement GBA_U;

- When a UICC is used, the keys MSK and MUK may be stored within the UICC or the ME depending on the UICC capabilities.

Figure: ME based key management in UE

http://docs.google.com/View?id=ddh56dhg_155djr4zmct

2). For UICC-based key management:

- When a MSK delivery procedure has to be performed and the corresponding Ks_int_NAF (GBA NAF key) is no longer available in the UICC, the UE shall re-generate a Ks_int_NAF key.

- If the received MSK delivery procedure refers to a Ks_int_NAF key no longer available and if the bootstrapped key Ks is associated to the same B-TID, then the ME should re-generate Ks_int_NAF with a GBA NAF derivation procedure.

- In case that the bootstrapped key Ks has been updated, the ME should take the new B-TID into use and run the MSK request procedure towards the BM-SC which retrieves the latest Ks_int_NAF from the BSF.

- The ME shall control the deletion of MUKs stored on the UICC.

- When the ME wants to free up storage in the UICC for new MUK, the ME selects the MUK no longer needed to be deleted.

- If a MUK is deleted then the corresponding GBA NAF Keys (i.e. GBA NAF Keys with same NAF-ID) shall be deleted; the bootstrapped key Ks shall also be deleted if Ks is present and associated to the same B-TID.

- BSF= Bootstrapping server function

- Ks_ext_NAF = Derived key in GBA_U

- Ks_int_NAF = Derived key in GBA_U, which remains on UICC

Figure: UICC based key management in UE

http://docs.google.com/View?id=ddh56dhg_157d9v8jsdz

- An MBMS User Service is composed of one or more MBMS Streaming Sessions and/or MBMS Download Sessions.

- An MBMS Streaming Session is composed of one or more RTP sessions

- An MBMS Download Session is composed of one or more FLUTE channels as defined in TS 26.346.

- MBMS streaming/download sessions may be transported over one or more MBMS Transport Services. Transport Services are defined in TS 22.246.

- MBMS security is used to protect RTP sessions and FLUTE channels.

As such MBMS User Service protection is Transport Service independent, in particular, it is independent on whether it is carried over point-to-point bearer or MBMS bearer (in multicast mode or in broadcast mode).