16 June Lucent Technologies grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Lucent Technologies is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by Lucent Technologies to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Lucent Technologies. Lucent Technologies specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Lucent Technologies other than provided in the copyright statement above. TITLE: 3GPP2 BCMCS Feature SOURCE: Mike Dolan – Work ABSTRACT: This presentation provides a description of the current state of the BCMCS work and possible implications for the cdma2000 ® radio interface. RECOMMENDATION: FYI. TSG-C SWG 2.3 C

16 June Outline Feature Description Service Examples User Experience Architecture Sample Scenarios BCMCS Impacts on the Radio Interface Security Architecture Security Keys Security Implications for the Radio Interface

16 June Feature Description BCMCS provides delivery of the IP flows that comprise BCMCS Programs to one or more users in one or more parts of the 3GPP2 network. The operator has control of: –Which IP flows are delivered to which parts of the network; –Billing of the user and/or content provider; and –Encryption of the IP flows. Using these three orthogonal controls, the operator can generate a wide spectrum of services for their customer base.

16 June Service Examples The operator might provide: –Traffic and weather with embedded advertising to defined regions of the network. The content would not be encrypted, and the advertisers would be billed. –Pay-per-view movies. The content would be encrypted and would be delivered to all subscribers requesting it, regardless of their location in the network. Subscribers would be billed. –Sporting events with “instant replay” in and around a sporting facility. This service might be free in the vicinity of the sporting facility, but charged to users outside that area. –Favorite mid-day TV shows that subscribers would otherwise miss. Content would be encrypted and subscribers would be billed. –Streaming stock prices. “Platinum” users would receive the service free; “Gold” users would receive it free in specific areas; “Silver” users would be billed for the service.

16 June User Experience The user: –Obtains a mobile device capable of receiving BCMCS. –Obtains subscriptions for desired billed BCMCS programming. Subscriptions may also be obtained in an ad hoc manner, depending on operator choices, e.g., pay per view subscriptions may be very ad hoc. –Receives information about scheduled BCMCS programming via web page/ /SMS/MMS/… –Selects desired programming from a menu or other user interface on their terminal device. –Receives (watches/listens) the desired BCMCS programming. –Receives billing for BCMCS services.

16 June Architecture

16 June Architecture BCMCS Controller: –Communicates with the mobile to provide detailed information necessary to choose and receive a BCMCS program. May also provide lists of available programs. –Communicates with the BCMCS Content Provider to control the ability of a Content Provider to send BCMCS programs to a BCMCS Content Server. –Generates and distributes BCMCS Access Keys (BAKs) to encrypt BCMCS program content. –Communicates via the AAA with the PDSN to provide IP multicast addressing and flow treatment information to the PDSN.

16 June Architecture BCMCS Content Provider: –Is the source of BCMCS programs sent to users. –Communicates with the BCMCS Controller to arrange the delivery of a program to a BCMCS Content Server. –May be a corporate entity providing encryption of programs prior to sending the programs to the operator’s network. BCMCS Content Server: –Is the last application that manipulates the BCMCS IP flows before they are sent to the PDSNs. –May combine several input programs from BCMCS Content Providers, e.g., traffic + weather + advertising combining. –Provides upper layer encryption of BCMCS programs when so chosen by the operator.

16 June Architecture BCMCS Client on the mobile: –Communicates with the BCMCS Controller via normal IP methods in a client-server relationship to obtain detailed information necessary to receive desired BCMCS programs.

16 June Sample Scenarios - Service Discovery, Information Acquisition

16 June Sample Scenarios - Bearer Path Setup – First User

16 June Sample Scenarios - Request for Multicast IP Flow(s) Available in the Access Network

16 June Sample Scenarios - Authorization without PPP session

16 June Sample Scenarios - Bearer Path Release

16 June BCMCS Impacts on the Radio Interface Radio interface must support efficient resource utilization via shared radio channels. Overhead channel – may need to consider: –Shared channel radio configuration. (Need to consider that there may be more than one type of shared radio channel.) –Mapping of IP flows to shared radio channels. –Indication that an IP flow is/is not being currently transmitted. –BCMCS registration requirements per IP flow. Layer 3 Signaling – may need to consider: –BCMCS registration to request specific IP flows (using BCMCS_FLOW_IDs). –BCMCS registration responses – positive to include radio channel info; negative to include reason for rejection. –Ability to move mobiles between shared and dedicated radio channels. –Explicit BCMCS deregistration is optional, not required.

16 June Security Architecture

16 June Security Keys BAK (BCMCS Access Key) – Generated in the network for each BCMCS Program. SK (Session Key) – Generated from the BAK and a random value (SK-Rand) and used to encrypt the content of a multimedia IP flow. RK (Root Key) – Contained in the UIM logical component of the mobile device. Used to generate temporary keys (TK). TK (Temporary Key) – Generated from the RK and a random value (TK-Rand) and used to encrypt the BAK for transmission to the mobile.

16 June Security Implications for the Radio Interface The BCMCS Framework allows encryption at the link layer (radio interface level). –The BSC/ANC would receive the BAK from the core network. The BSC/ANC would generate SK-Rand values and from those values generate SKs (Session Keys). –The BSC/ANC may need to signal to the mobile that link layer encryption is being used. The mobile would already have the BAK. –The BSC/ANC would need to signal to the mobile the SK-Rand values used to generate the SKs. It has not been determined whether this should be in-band or out-of-band with the encrypted BCMCS content. –Soft handoff would not be possible for BCMCS between portions of the network that use link layer encryption and those that use higher layer encryption. –The RAN and the Core Network would need to coordinate BCMCS content encryption to avoid double-encrypting content. This may be an operational burden for the network operator.