3GPP2 Broadcast Multicast Services

. Slide #1[OMA-Template-SlideDeck-20050101-I]

3GPP2 Broadcast Multicast Services


Outline• BCMCS Standard Status and Schedule• BCMCS Overview

• Architecture• Capabilities

• BCMCS Security Framework Overview• Review of CDMA 1x and HRPD BCMCS Radio Capabilities• BCMCS Phase II Work Items• OMA BCAST Overview• Conclusion and Recommendation


3GPP2 BCMCS Current Status and Schedule

• Stage 1 Document (S.P 0030-A): Published • Security Framework Document

• S.P 0083: Published• S.S 0083-A: Published in September 04

• Over-the-Air document: • 3G1x: C.S0001-D through C.S0006-D, published in February 04• 3G HRPD: C.S0054, published in February 04

• BCMCS in cdma2000 wireless IP network (X.S0022)• Publication Version ready by pending 3 RFC numbers from IETF

• IOS BCMCS (A.S 0019) • Published in November 04

• IS-683-C Support: Published at Oct 02• R-UIM Support (C.S0023-C v1.0/IS-820-C)

• Currently in ballot process• Expected publication in June 05


Overview

• Optimize use of the cdma2000 radio interface over the air

• BCMCS provides delivery of the IP flows that comprise BCMCS Programs (content) to one or more terminals in one or more regions of the 3GPP2 network.

• The 3GPP2 operator has control of:• Transmission Areas of BCMCS IP flows• Billing of the user and/or content provider• Encryption of the IP flows

• Examples: weather, stock, news, pay per view movies, sport events etc.


BCMCS Overview - Architecture

BCMCSSubscriber

ProfileManager

SubscriberProfile

Database

HAAA

SAAA

PDSN

BSN

BSC/PCF

MS/UIM

BCMCSController

BCMCSContentServer

BCMCSContentProvider


MR


SignalingBearer Path (Original content)Bearer Path (Content may be reformatted)Out of Scope of this document

Home Network

Serving Network

Third party

XML overHTTP

RADIUS

RADIUS

A11 Signaling

IGMP for IPv4MLD for IPv6


Protocol Stack - Bearer Path(Segment Based Framing)

MSBSC/PCF

BSN Router(s)

BCMCSContentServer

IP

PPP-likeEncapsulation

Framing

Link LayerEncription

Mux

Physical Layer

UDP

Encryption

RTP

Application(ex. MPEG-4)

PhysicalLayer

Mux


Framing

L1

R-P

IP


R-P

L1

L1

L2

IP

L1

L2

IP

L1

L2

IP

UDP

Encryption

RTP



Protocol Stack - Bearer Path (HDLC-like Framing)

MSBSC/PCF

BSN Router(s)

BCMCSContentServer

IP


Framing


Mux

Physical Layer

UDP

Encryption

RTP


PhysicalLayer

Mux


L1

R-P

IP


Framing

R-P

L1

L1

L2

IP

L1

L2

IP

L1

L2

IP

UDP

Encryption

RTP



Basic Procedures• Service Discovery/Announcement

• Used to find out available BCMCS service• Distribute information about the service, parameters required for information acquisition and

program schedule• Via out of band mechanisms

• Content Subscriptions• Subscriptions to BCMCS• RK (Registration Key) is provisioned• Via out of band mechanisms

• Information Acquisition• Obtain BCMCS Session related info from Controller (BCMCS_FLOW_ID, header compression etc) • Obtain Security Parameters (BAK etc)

• Content Availability Determination• Determines whether a Multicast IP flow is available in a particular sector and the BCMCS radio

configuration information • Via the overhead messages from a BS

• BCMCS Registration• Request for delivering the IP flows in a particular sector• The first user may trigger the Bearer Path establishment• Notify where to page the MS

• Reception of the Content• BCMCS Deregistration


Major Capabilities in X.S0022

• BCMCS Controller Discovery (via DHCP)• Information acquisition using HTTP

• HTTP Digest is used for Information Acquisition Authentication• Program based authorization

• Both Static and Dynamic Broadcast• Registration authorization (BAK Hash based mechanism)• Segment based Framing or HDLC like Framing• Optional Encryption (Link layer or high layer)

• SRTP is used for high layer encryption at Content Server• Link layer encryption at the RAN only applies to HRPD

• Header Compression (ROHC U mode)• BSN/RAN session discovery (Query/Response Model)• Accounting

• BAK Lifetime based accounting (for charging the MS user)• Octet based accounting (for charging the content provider)


Key Hierarchy for CS-MS Security

SK (Session Key)• Used to decrypt content.• Changes frequently to discourage session theft• Generated by the UIM

BAK (BCMCS Access Key)• Used to generate SK• Provides access to program/multicast IP flow• Decrypted and stored in the UIM

TK (Temporary Key)• Used to encrypt/decrypt the BCMCS Access Key (BAK) for transmission to the MS• Generated from RK• Stored in the UIM

RK (Registration Key)• Used to generate TK• RK is obtained when user subscribes to broadcast services• Stored in the UIM


Authentication for Information Acquisition

• When the MS requests Security Information (BAK etc), the BCMCS Controller shall initiate authentication and program authorization procedures with Home RADIUS server

• Authentication using IETF RADIUS Extension for Digest Authentication • Authorization using program names

• Auth-Key generation:• Auth-key shall be set to the computed 128-bit output of f3• The input parameters of f3 shall be set as follows:

• The K parameter shall be set to RK. • The fi parameter shall be set to 0x45. • The RAND parameter shall be set to H( H(entity -body) | timestamp). MD5 shall be used for hashing.

• The Fmk parameter shall be set to 0x42494141 ("BIAA").


BCMCS Security Functional Architecture

RK provisioned

RK provisioned

Provisioned RK

Provisioned RKContent BAK_ID, SK_RAND[encrypted content, SK_RAND, BAK_ID]

Content is encrypted by SK

[SK, SK_RAND, BAK_ID, BAK_Expire]

SK is derived from BAK

BAK

BAK

BAK is encrypted by TK

TK is derived from RK

TK is derived from RK

SK

2

2

7

BAK Is encrypted by TK


SRTP (High Layer Encryption)• SRTP (RFC3711) framework is used• BAK is used as SRTP Master Key• SK_RAND (32 bits) is extended to 112 bits by left-padding with zeros to form the SRTP

Master Salt• Key Derivation Function is AES in Counter Mode • The SRTP encryption transform is the AES in Counter Mode • The Key Derivation Rate (KDR) is set to zero • MKI is used for distributing SK_RAND and included in every encrypted RTP packet• PI (ROC+ Received Seq) is used for calculating IV (Initialization Vector)• Decrypt contents by using IV and SRTP session Key (SK)

Key DerivationFunction

Packet Index

SRTP Master Key

SRTP Master Salt

SRTP SessionEncryption Key

Reserved(4 bits)

BAK_ID(4 bits)

SK_RAND(32 bits)

ROC(32 bits)


Accounting

• Collected accounting data should be able to help service provider:• Billing on BCMCS Originators/Content Provider• Billing on BCMCS viewers/subscribers

• Accounting type:• Flat fee (e.g., monthly payment)• Pay per view (BAK Lifetime based accounting)• Octet Based Accounting• Usage Based (FFS)

• Accounting data may be collected by:• RAN • BSN• BCMCS Controller

• Accounting data should send to HAAA/LAAA.


CDMA 1x and HRPD BCMCS Radio Capabilities

• Support both Idle State and Traffic State BCMCS • Support concurrent services (Simultaneous unicast and broadcast or

multiple broadcast)• Page Set Maintenance (Be able to receive incoming calls and MS directed

message during monitoring BCMCS) • Dynamic BCMCS (Based on User presence to decide whether transmitting

the BCMCS IP flow) • Autonomous Request BCMCS flows that are not advertised by the

current sector• Support autonomous soft combining and Reed Solomon code to improve

performance• Registration Authorization (BAK Hash Based)• Support of scheduled program• Support of group paging• Support both BCMCS Streaming and Push To Talk


BCMCS Phase II

• Over the Air Enhancement:• Add Platinum BCMCS support in HRPD:

• C.S0054-A will be changed to support Platinum BCMCS (No network impact)• File Distribution Protocol• BCMCS Codec

• Network Enhancement:• Open Interface between the BCMCS Controller and Content Server• Duration/Usage Based Accounting• Additional QoS Parameters Support• Network/BCMCS Controller Initiated Bearer Path Establishment • Localized Programs• BCMCS Program categories• Preview of BCMCS Programs


OMA BCAST Scope

• Current OMA BCAST Scope includes:• Stream Distribution• File Distribution• Service and Content Protection• Service/Terminal Provisioning• Service Discovery and Service Guide• Notification• Interaction Function

• 3GPP2 View of OMA BCAST Scope• OMA BCAST Scope should focus on Application Layer

• No need to specify Network/Transport Layer• OMA BCAST should avoid overlapping work/activities with 3GPP/3GPP2 whenever

possible• If overlap occurs, the mechanisms from 3GPP/3GPP2 should be adopted


Current OMA BCAST Protocol Model

DVB-T/H ATSC

3GPP2 BCMCS

3GPP MBMS

・・・

IP

Multiplex (MPEG2-TS, etc.)

Interaction Channels

FLUTE, NORM, etc

File Format: mp4, 3gp, etc

Files, Objects

XML, SDP, etc

RTP, RTCP, MPEG-4 system, etc

Streams

Green Box shows OMA BCAST Enabler Functions

Yellow Box shows OMA BCAST related protocols

Stream Distribution

File Distribution

Service Protection

Content Protection

Service Provisioning

Service Discovery and Service Guide

Notification

Interaction Function

File R

epair

Protocol Stack

Interaction Bearer

OMA BCAST Functions

Terminal Provisioning


Proposed OMA Protocol Stack

DVB-T/H ATSC

3GPP2BCMCS

3GPP

MBMS

...

IP

Multiplex (MPEG2-TS, etc.)

InteractionChannels

File Distribution Protocol

File Format: mp4, 3gp, etc

Files,Objects

XML,SDP,etc

RTP, RTCP, MPEG-4 system, etc

Streams

Green Box shows OMA BCAST Enabler Functions

Yellow Box shows OMA BCAST related protocols

Stream Distribution

File Distribution

Service Protection

Content Protection

Service Provisioning

Service Discoveryand Service Guide

Notification

Interaction Function

File R

epair

Protocol Stack

InteractionBearer

OMA BCASTFunctions

Terminal Provisioning

Link Layerand Lower

Link Layerand Lower

Pink Box shows OMA BCAST related protocols or 3GPP2 BCMCS/3GPP MBMS protocols

Some OMA BCAST Functions overlap with BCMCS Functions, such as service protection, file distribution, interaction function etc.


Conclusion and Recommendation

• 3GPP2 has completed BCMCS Phase I work• 3GPP2 BCMCS Phase II work is on going• 3GPP2 would welcome continuing communications and coordination regarding

broadcast activities between OMA and 3GPP2 towards greater reuse of mechanisms and protocols and less work duplication

• Specific 3GPP2 Recommendations:• Service Protection should be bound to the subscription • Coordinated effort for specifying appropriate content protection mechanism(s)• Coordinated effort for specifying appropriate File Distribution Protocol• It would be desirable for OMA BCAST and 3GPP2 to avoid overlapping

work/activities wherever if possible• OMA BCAST should Focus on Application Layer Enablers agnostic to underlying

BDS

Documents

3GPP2 Broadcast Multicast Services