Broadcast and Multicast Service in cdma2000 Wireless IP Network

Transcription

1 GPP X.S00-A Version.0 May 0 Broadcast and Multicast Service in cdma000 Wireless IP Network Revision A 0 GPP GPP and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the GPP Secretariat at secretariat@gpp.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See for more information.

2 REVISION HISTORY Revision Description of Changes Date Rev A V.0 Rev A V.0 Initial Publication February, 00 Rev A Point Release April, 0 Rev A V.0 Rev A Point Release Re-publication version editorial changes made to the April 0 document. May, 0

3 GPP X.S00-A v CONTENTS Broadcast and Multicast Service in cdma000 Wireless IP Network Introduction Glossary and Definitions. Acronyms. Definitions References. Normative References. Informative References Protocol Reference Model. Network Reference Model. Protocol Stack. BCMCS Flow ID Structure BCMCS Service Description. Service Discovery/Announcement. Content Subscriptions. BCMCS Information Acquisition. Content Availability Determination. BCMCS Registration. BCMCS Content Delivery. BCMCS De-registration BCMCS Controller Discovery. Static BCMCS Controller Discovery. Dynamic BCMCS Controller Discovery.. BCMCS Controller DHCP Option MS Requirements PDSN Requirements DHCP Server Requirements..... BCMCS Controller DHCPv Option MS Requirements PDSN Requirements DHCPv Server Requirements... BCMCS Information Acquisition. MS Requirements. BCMCS Controller Requirements. Home RADIUS Server Requirements 0 i

4 GPP X.S00-A v Protocol and Message Format. Message-body Tag Definitions. MIME Type.. HTTP Information Acquisition Request..... HTTP Information Acquisition Response..... HTTP Information Acquisition Reject..... XML Elements <BCMCS> <Request> <Response> <Reject>.... XML Schema BCMCS Controller and Content Server Interface. BCMCS Flow Life Cycle.. Inactive State..... {Active, Idle} State..... {Active, Busy} State.... CS-BCMCS Control Protocol. CS-BCMCS Control Protocol Messages.. CS-BCMCS Control Protocol Message Procedures Add BCMCS Flow CS Functional Requirements BCMCS Controller Functional Requirements Modify BCMCS Flow CS Functional Requirements BCMCS Controller Functional Requirements Remove BCMCS Flow CS Functional Requirements BCMCS Controller Functional Requirements State Synchronization Refresh Keys CS Functional Requirements BCMCS Controller Functional Requirements FlowInformation CS Functional Requirements BCMCS Controller Functional Requirements..... Message Format AddFlowRequest AddFlowResponse ModifyFlowRequest ModifyFlowResponse RemoveFlowRequest RemoveFlowResponse RefreshKeyRequest RefreshKeyResponse... ii

5 GPP X.S00-A v FlowInformation FlowInformationResponse ResetRequest ResetResponse..... Information Elements AuthenticationExtension BAKParameter BCMCSFlowHandle ContentProviderID ContentTunnelProtocolOption DelayOffset EndTime FailedParameter QoSParameters LTunnelDestinationAddress LTunnelSourceAddress MulticastFlowAddress_BCMCSFlowHandle ResultCode SDPParameters StartTime... BCMCS Bearer Path Setup. Bearer Path Setup between MS and BSN. Join Multicast Group from BSN.. IGMP Support..... MLD Support.... BSN-Content Server Unicast Tunnel 0 BSN Session Management 0. Session Discovery Triggered by the BSN 0.. BSN Requirement SAAA/BCMCS Controller Requirement Session Information Triggered by the BCMCS Controller 0.. SAAA/BCMCS Controller Requirement BSN Requirement Session Termination Triggered by the BCMCS Controller 0.. SAAA/BCMCS Controller Requirements BSN Requirements... BCMCS Security. Authentication, Authorization and Integrity Check.. Information Acquisition BCMCS Controller Requirement Home RADIUS Server Requirement MS Requirement..... Registration... iii

6 GPP X.S00-A v BSN Requirements SAAA/BCMCS Controller Requirements.... Key Management. Encryption.. Link Layer Encryption..... Higher Layer Encryption Authentication Tag... Header Compression. MS Requirements. BCMCS Controller Requirements. BSN Requirements Accounting. General.. BAK Based Accounting BCMCS Controller Usage Data Record (UDR) Accounting Formats BCMCS Controller Procedure RADIUS Server Procedure..... Octet Count Based Accounting BCMCS Airlink Records BCMCS A0 Connection Setup Airlink Record BCMCS Active Start Airlink Record BCMCS Active Stop Airlink Record BSN Usage Data Record (UDR) Accounting Formats BSN Procedures A0 Connection Setup Airlink Record Arrives Arrival of Forward Link Direction BCMCS Flow Active Start Airlink Record Arrives Active Stop Airlink Record Arrives Interim-Update Record Trigger Stop Record Trigger Time of Day Timer Expires RADIUS Server Procedure... BCMCS RADIUS Vendor Specific Attribute A List of GPP VSAs between the BSN and SAAA/BCMCS Controller 0 A List of GPP VSAs between the BCMCS Controller and HAAA Annex A: Call Flows (Informative) Annex B: Sample XML Output (Informative) B. BCMCS Information Acquisition Request iv

7 GPP X.S00-A v.0 B. BCMCS Information Acquisition Response B. BCMCS Information Acquisition Reject Annex C: XML Data Structure (Normative) Annex D: The Example of The usage of Reserved Program ID (Informative) v

8 GPP X.S00-A v LIST OF FIGURES Figure - Network Reference Model... Figure - Protocol Reference Model for BCMC Bearer Path (when Segment-based framing is applied)...0 Figure - Protocol Reference Model for BCMC Bearer Path (when HDLC-Like Framing is applied)...0 Figure - An Example of the BCMCS Flow ID Structure... Figure - BCMCS Flow Handle States... Figure - Common Header Format and Body Format... Figure - AuthenticationExtension...0 Figure - BAKParameter...0 Figure - Field format for Port number and IP address... Figure - BCMCSFlowHandle... Figure - ContentProviderAddress... Figure - ContentTunnelProtocolOption... Figure - DelayOffset... Figure -0 EndTime... Figure - FailedParameter... Figure - QoSParameters... Figure - LTunnelDestinationAddress... Figure - LTunnelSourceAddress... Figure - MulticastFlowAddress_BCMCSFlowHandle... Figure - ResultCode... Figure - SDPParameters... Figure - StartTime... Figure - SRTP Key Derivation... Figure - MKI Format... Figure - BCMCS SRTP Authentication Tag format... Figure - Octet Count Based Accounting Architecture... Figure - Per BAK based Accounting Architecture... Figure - GPP BCMCS RADIUS Attribute Format... Figure - Authorization Parameters VSA Format... Figure - BCMCS Capability VSA Format...00 Figure - Common Session Info VSA Format...0 Figure - BSN Session Info VSA Format...0 Figure - RAN Session Info VSA Format...0 Figure - Subnet VSA Format...0 Figure - TK Info VSA Format...0 Figure - BAK_ID VSA Format...0 Figure -0 Content Provider ID format...0 vi

9 GPP X.S00-A v Figure A - Registration Authorization, Bearer... Figure A - HTTP Authentication and Integrity Protection... Figure A - Network Initiated Flow... Figure A - Success Add Flow Scenario... Figure A - Successful Modify Flow Scenario...0 Figure A - Successful Remove Flow Scenario... Figure C- XML Overall Structure... Figure C- XML Data Structure: Request... Figure C- XML Data Structure: PgmInfo under Request... Figure C- XML Data Structure: ReqSysInfo under Request... Figure C- XML Data Structure: Response... Figure C- XML Data Structure: GenInfo under Response and BCMCSInfo... Figure C- XML Data Structure: PgmInfo under Response and BCMCSInfo... Figure C- XML Data Structure: Reject... Figure D- Static Mapping Reserved Group IDs in IPv Multicast Address Space... Figure D- Static Mapping Reserved Flow IDs in bit BCMCS Flow ID... Figure D- Static Mapping Reserved Flows IDs in bit BCMCS Flow ID...0 Figure D- Static Mapping Reserved Flows IDs in bit BCMCS Flow ID...0 vii

10 GPP X.S00-A v LIST OF Tables Table - CS-BCMCS Control Protocol Message... Table - Message Type Values... Table - Definition of Mandatory, Conditional, Optional... Table - AddFlowRequest... Table - AddFlowResponse... Table - ModifyFlowRequest... Table - ModifyFlowResponse... Table - RemoveFlowRequest... Table - RemoveFlowResponse... Table -0 RefreshKeyRequest... Table - RefreshKeyResponse... Table - FlowInformation... Table - FlowInformationResponse... Table - RestRequest... Table - RestResponse... Table - Information Element Identifiers... Table - CharacterSetValues... Table - ContentTunnelProtocolOption Values... Table - IP Version Values... Table -0 ResultCode Values... Table 0- Occurrence of RADIUS Attributes for Session Discovery... Table 0- Occurrence of RADIUS Attributes for Session Information... Table 0- Occurrence of RADIUS Attributes for Session Information... Table - Occurrence of RADIUS Attributes for Information Acquisition... Table - Complete BCMCS Controller UDR... Table - BCMCS Controller Accounting Parameter Attribute RADIUS Definitions...0 Table - A0 Connection Setup Airlink Fields... Table - BCMCS Active Start Airlink Fields... Table - BCMCS Active Stop Airlink Fields... Table - Complete BSN UDR... Table - BCMCS Accounting Parameter Attribute RADIUS Definitions... Table - GPP VSA Table between BSN and SAAA/BCMCS Controller...0 Table - GPP VSA Table for BCMCS between the BCMCS Controller and HAAA... Table D- IP Address - BCMCS Flow ID Mapping Table... viii

11 GPP X.S00-A v.0 0 FOREWORD (This foreword is not part of this document) This document was prepared by GPP TSG-X. This document is a point release specification of X.S00-A. This document is subject to change following formal approval. Should this document be modified, it will be re-released with a change of release date and an identifying change in version number as follows: X.S00-X version n.0 where: X an uppercase numerical or alphabetic character [0, A, B, C, ] that represents the revision level. For X.S00, the revision 0 has never been published. n a numeric string [,,, ] that indicates an point release level. ix

12

13 GPP X.S00-A v.0 0 Introduction This document defines core network protocols and procedures for support of the Broadcast-Multicast Service (BCMCS) for cdma000 networks. This document defines the BCMCS services and architecture. The Stage requirements for the Broadcast-Multicast Service are specified in []. The major purpose of the BCMCS is to allow optimization of the cdma000 radio interface for delivery of BCMCS content stream(s) to one or more terminals in one or more regions of an operator s network. The network operator can control each BCMCS Content Stream with regard to accounting aspects, regions of the network where the BCMCS Content Streams are available to various users, and encryption of the content of Multicast IP Flow(s) to protect against unauthorized reception. IETF protocols are widely employed whenever possible to minimize the number of new protocols required and to maximize the utilization of well accepted standards. 0. Scope This specification covers the followings to support BCMCS in cdma000 networks: BCMCS Network Architecture and protocol stacks; The interface between the MS and the BCMCS Controller for BCMCS information acquisition; The interface between the BCMCS Controller and the Content Server; The BCMCS bearer path establishment procedures; The interface between the BSN and the BCMCS Controller for BCMCS session management; The BCMCS Security; The BCMCS Accounting procedures. 0. Document Convention Shall and shall not identify requirements to be followed strictly to conform to the standard and from which no deviation is permitted. Should and should not indicate that one of several possibilities is recommended as particularly suitable, without mentioning or excluding others, that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. May and need not indicate a course of action permissible within the limits of the standard. Can and cannot are used for statements of possibility and capability, whether material, physical, or causal. cdma000 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of GPP. Geographically (and as of the date of publication), cdma000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.

14 GPP X.S00-A v.0 Glossary and Definitions Acronyms AAA AES BCMCS BSC BSN BAK CE CID CS DHCP FCS FQDN HAAA HRPD HTTP IEI IGMP IP IR IR-DYN MIME MKI MR MS MSB MRRU NAI NID OAM OTA PCF PDSN PZID RADIUS RK RAN ROC ROHC RTCP RTP SAAA Authentication, Authorization, and Accounting Advanced Encryption Standard Broadcast and Multicast Service Base Station Controller Broadcast Serving Node Broadcast Access Key Content Encryption Context Identifier Content Server Dynamic Host Configuration Protocol Frame Check Sequence Fully Qualified Domain Name Home AAA High Rate Packet Data Hyperlink Text Transfer Protocol Information Element Identifier Internet Group Management Protocol Internet Protocol Initialization and Refresh Initialization and Refresh-Dynamic Multipurpose Internet Mail Extensions Master Key Identifier Multicast Router Mobile Station Most Significant Bit Maximum Reconstructed Reception Unit Network Address Identifier Network IDentifier Operation And Maintenance Over The Air Packet Control Function Packet Data Serving Node Packet Zone IDentfier Remote Authentication Dial In User Service Registration Key Radio Access Network Rollover Counter Robust Header Compression Real-time Transport Control Protocol Real-time Transport Protocol Serving AAA

15 GPP X.S00-A v.0 0 SID SK SMS SRTP TK UDP UDR UIM UTC VSA WAP XML System IDentifier Short-term Key Short Message Service Secure Real-time Transport Protocol Temporary Key User Datagram Protocol Usage Data Record User Identity Module Universal Coordinated Time Vendor Specific Attribute Wireless Application Protocol extensible Markup Language. Definitions 0 BCMCS Content Stream. A single BCMCS broadcast program identified by Program Name. A BCMCS Content Stream can contain one or more IP multicast data flows. BCMCS_FLOW_ID. A value used for identification of a BCMCS Multicast IP Flow. BCMCS User Profile. The user profile indicates if the user is authorized to use cdma000 BCMCS network capability and identifies the BCMCS programs that the user is allowed to receive/view. It may also include a user Registration Key that is specified in []. Dynamic Broadcast. The broadcast service wherein the bearer path can be established dynamically based on a MS s request. Multicast IP Flow. Similar to an ordinary IP flow, with the exception that the destination address is a Multicast IP address. The flow can be identified by source address, source port, destination Multicast IP address, and destination port. Program ID. An identifier for a program that consists of one or more flows. Program Name. The name associated with the Program ID. There is a one to one relationship between a Program ID and a Program Name. Static Broadcast. The broadcast service wherein the bearer path is statically provisioned by the operator (e.g., via OAM) regardless of a MS s request.

16 GPP X.S00-A v.0 References The following documents contain provisions, which, through reference in this text, constitute provisions of this document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a GPP document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document Normative References [] GPP: S.R000-A ver..0, Broadcast/Multicast Services - Stage, Revision A, February 00. [] GPP: S.S00-A, Broadcast-Multicast Service Security Framework, September 00. [] GPP: X.S00, cdma000 Wireless IP Network Standard. [] GPP: A.S00-A v.0, Interoperability Specification (IOS) for Broadcast Multicast Services (BCMCS), April, 00. [] GPP: C.S00-A v.0, cdma000 High Rate Broadcast-Multicast Packet Data Air Interface Specification, March 00. [] GPP: C.S000-E v.0, Upper Layer (Layer ) Signaling Standard for cdma000 Spread Spectrum Systems, June 00. [] IETF: RFC, Simpson, The Point-to-Point Protocol (PPP), July. [] IETF: RFC, Simpson, PPP in HDLC-like Framing, July. [] IETF: RFC, Baugher, et al, The Secure Real-time Transport Protocol (SRTP), March 00. [0] IETF: RFC 0, Schulzrinne, et al. RTP: A Transport Protocol for Real-Time Applications, July 00. [] IETF: RFC 0, Chowdhury, et al. Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers, November 00. [] IETF: RFC, Fielding, et al, Hypertext Transfer Protocol -- HTTP/., June. [] IETF: RFC, Franks, et al, HTTP Authentication: Basic and Digest Access Authentication, June. [] IETF: RFC 0, Sterman, et al. RADIUS Extension for Digest Authentication, July 00. [] WC: XML Schema Part : Datatypes Second Edition, WC Recommendation, October 00. [] IETF: RFC, Hinden, et al, IP Version Addressing Architecture, July. [] GPP: C.S00-A, cdma000 High Rate Packet Data Air Interface Specification, April 00. [] IETF: RFC, Handley, SDP: Session Description Protocol, April.

17 GPP X.S00-A v [] IETF: RFC, Fenner, Internet Group Management Protocol, Version, November. [0] IETF: RFC Cain, et al, Internet Group Management Protocol, Version, October 00. [] IETF: RFC 0, Deering, et al, Multicast Listener Discovery (MLD) for IPv, October. [] IETF: RFC 0, Vida, et al, Multicast Listener Discovery Version (MLDv) for IPv, June 00. [] IETF: RFC, Rigney, et al, Remote Authentication Dial In User Service (RADIUS), June 000. [] IETF: RFC, Rigney, et al, RADIUS Extensions, June 000. [] FIPS: FIPS PUB 0-, Federal Information Processing Standards Publication 0-, Secure Hash Standard. [] IETF: RFC 0, Borman, et al, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, July 00. [] IETF: RFC, Bormann and Bremen, Robust Header Compression (ROHC) over PPP, April 00. [] IETF: RFC, Rigney, RADIUS Accounting, June 000. [] IETF: RFC, Aboba, et al, RADIUS and IPv, August 00. [0] IETF: RFC 0, Mills, et al, Network Time Protocol (Version ) Specification, Implementation and Analysis, March. [] IETF: RFC, Chiba, et al, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), July 00. [] IETF: RFC, Meyer, et al, Administratively Scoped IP Multicast, July. [] IETF: RFC, Perkins, IP Mobility Support for IPv, August 00. [] IETF: RFC, Lehtovirta, et al, Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol, January 00. [] GPP: C.R00-E v.0, Administration of Parameter Value Assignments for cdma000 Spread Spectrum Standards, October 00. [] IETF: RFC, Deering, Host Extensions for IP Multicasting, August. [] IETF: RFC, Eronen, et al, Pre-Shared Key Ciphersuites for Transport Layer Security (TLS), December 00. [] IETF: RFC, TRANSMISSION CONTROL PROTOCOL, September [] GPP: C.S000-0 v.0, BCMCS Codecs and Transport Protocols, January 0 0. Informative References. GPP: C.S000-D, Introduction for cdma000 Spread Spectrum Systems, March 00.. GPP: C.S000-D, Physical Layer Standard for cdma000 Spread Spectrum Systems, March 00.

18 GPP X.S00-A v.0. GPP: C.S000-D, Medium Access Control (MAC) Standard for cdma000 Spread Spectrum Systems, March 00.. GPP: C.S000-D, Signaling Link Access Control (LAC) Standard for cdma000 Spread Spectrum Systems, March 00.

19 GPP X.S00-A v.0 Protocol Reference Model. Network Reference Model BCMCS Subscriber Profile Manager Subscriber Profile Database H-AAA BCMCS Content Provider Third party Home Network Serving Network S-AAA BCMCS Controller BCMCS Content Provider PDSN MS/ UIM BSC/ PCF BSN MR BCMCS Content Server 0 Signaling Bearer Path (Original content) Bearer Path (Content may be reformatted) Out of Scope of this document Figure - Network Reference Model The function of each entity is listed below: BCMCS Content Provider BCMCS Controller This entity is a core network function that is responsible for managing and providing the BCMCS session information to the BSN (via the SAAA), the BCMCS Content Server, the MS (via the PDSN function) and the RAN (via the BSN function). The BCMCS Controller serves the function of BAK Distributor and may serve the function of BAK Generator (see []). The BCMCS Controller may perform discovery operations to assist the MS to find desired content. BCMCS Content Server This entity is a function that makes BCMCS content available within an IP Multicast stream. The BCMCS Content Server in the serving network is not necessarily the creator or source of the

20 GPP X.S00-A v content. It is the last application level entity to manipulate (e.g., reformat) the content prior to the content reaching the BSN. The BCMCS Content Server may store and forward the content from the BCMCS Content Provider, and/or merge the content from the multiple content providers. If higher layer encryption is enabled, the BCMCS Content Server encrypts the stream content. In this case, the BCMCS Content Server also serves the function of SK manager (see []). BCMCS Content Provider This entity is the creator or source of the content. BCMCS Subscriber Profile Manager This entity is an application that updates the subscriber profile in the Databases regarding subscribed BCMCS services. The user may interface to this application directly, or the operator may reserve access to this application to their customer service agents. The interface between the user and the BCMCS Subscriber Profile Manager, and the interface between the BCMCS Subscriber Profile Manager and the Subscriber Profile Database are outside the scope of this Document. AAA This entity is responsible for BCMCS authentications, authorizations, and accounting. It accesses the Subscriber Profile Database to obtain information from the BCMCS user profile. Subscriber Profile Database This entity is responsible for storing the BCMCS user profile. The interface between the Subscriber Profile Database and the HAAA is outside the scope of this Document. PDSN The PDSN communicates with the MS using the unicast packet data service for packet data session establishment, to add and remove IP flows, etc. as described in []. The PDSN function acts as the first-hop router for IP traffic to and from the MS. BSN The BSN communicates with the BSC/PCF to add and remove Multicast IP Flows. It may use IP multicast protocols to manage bearers supporting Multicast IP Flow between itself and the nearest router connecting back to the BCMCS Content Server. It also applies the flow treatment received from the BCMCS Controller to the Multicast IP Flows. The procedure for selecting BSN is specified in []. MR This optional entity is a multicast router. If the content is transmitted over a provisioned tunnel between the BSN and the BCMCS Content Server, this entity is omitted. MS In adding to the requirements specified in [] and [], this entity is responsible for performing the BCMCS Information Acquisition, BCMCS registration, and receiving Multicast IP flows. BSC/PCF These entities are responsible for signaling, establishing, and tearing down bearer channels between the BSN and the MSs. If the link layer encryption is enabled, the BSC also serves the

21 GPP X.S00-A v function of SK manager []. The BSC chooses the best bearer channel to the MS based on considerations such as optimization of resources, required QoS, etc. Within the BCMCS architecture, the following interfaces are defined: The interface between BCMCS Controller and BSN via SAAA This interface provides BCMCS session related information such as Flow Treatment (e.g., Header Compression), relevant QoS parameters such as required bandwidth, the mapping between BCMCS Flow ID and Multicast IP address and port number from the BCMCS Controller to the BSN via RADIUS protocol. This interface also exchanges the BCMCS authorization information for BCMCS registration. The SAAA is shown as an example of the first hop of RADIUS proxy. Use of proxy is optional. If it is used, it may be different from the one that is used by the PDSN. The interface between BSN and SAAA This interface allows the BSN to generate accounting information for the content flows. The interface between BCMCS Controller and SAAA This interface provides the BCMCS Controller with authentication and authorization information. The SAAA may send BCMCS user profile received from the HAAA to the BCMCS Controller during BCMCS Information Acquisition triggered by the MS. The BCMCS Controller may send accounting information to the SAAA. The SAAA may also be used to relay the BCMCS session related information between the BSN and BCMCS Controller. The interface between BCMCS Controller and BCMCS Content Provider This interface exchanges information including Content Provider Name, Program Name, session description (e.g., codec type), and security information etc. This interface may also exchange the start time of the BCMCS session and duration of the BCMCS session. This interface is outside the scope of this document. The interface between BCMCS Controller and BCMCS Content Server This interface may exchange the security information, multicast IP Address and port number, and content management information (e.g., the start time of the BCMCS session and duration of the BCMCS session). The BCMCS Controller uses this interface to add, modify, or remove BCMCS flows. The CS uses this interface to provide BCMCS flows information. This interface also provides a mechanism for message authentication of the CS and BCMCS controller and protects integrity of its messages. The interface between BCMCS Controller and MS/UIM This interface provides the BCMCS client application in the MS with access to information about available BCMCS sessions: including Program Name, BCMCS Flow ID(s), BAK(s) and BAK Expiry time if the Multicast IP Flow(s) are encrypted, start time of the BCMCS session, duration of the BCMCS session, flow treatment (e.g., header compression), and session description (e.g., codec type), etc. 0. Protocol Stack The BCMCS Controller provides protocol options and miscellaneous parameters to the MS during the BCMCS Information Acquisition (see section ). The MS shall use those protocol options and parameters without negotiation. Figure - and Figure - show the protocol reference model for BCMCS.

22 GPP X.S00-A v.0 MS Application (ex. MPEG-) BSC/ PCF BSN Router(s) BCMCS Content Server Application (ex. MPEG-) RTP RTP Encryption (Optional) Encryption (Optional) UDP UDP IP IP IP IP IP PPP-like Encapsulation Framing Framing PPP-like Encapsulation L L L Link Layer Encryption (Optional) Link Layer Encryption (Optional) A0 A0 Mux Mux L L L Physical Layer Figure - Physical Layer L L Protocol Reference Model for BCMC Bearer Path (when Segment-based framing is applied) MS Application (ex. MPEG-) BSC/ PCF BSN Router(s) BCMCS Content Server Application (ex. MPEG-) RTP RTP Encryption (Optional) Encryption (Optional) UDP UDP IP IP IP IP IP PPP-like Encapsulation Framing PPP-like Encapsulation Framing L L L Link Layer Encryption (Optional) Mux Link Layer Encryption (Optional) Mux A0 A0 L L L Physical Layer Physical Layer L L Figure - Protocol Reference Model for BCMC Bearer Path (when HDLC-Like Framing is applied) As shown in Figure - and Figure -, the PPP control protocol is not needed for BCMCS. However PPP-like encapsulation (see [] section ) shall be supported by both the MS and the 0

23 GPP X.S00-A v BSN to distinguish IP packets with or without header compression, and indicate which header compression algorithm if header compression is used. The BSN shall not send the address and the control field (FF0), see []. The BSN may encode Protocol ID as one byte or two bytes as specified in []. Broadcast Framing uses the segment-based framing [] or HDLC-like framing []. The framing is performed either in BSN or RAN, but not both. The BSN shall support the HDLC-like framing with 0x ACCM if it interoperates with PCFs using []. The BSC/PCF may support the segment-based framing. The BSN shall use an operator-configured policy to determine which framing method to use for the program per PCF when both framing capabilities are available. In a given GRE frame over the A0 connection, the BSN shall include octets from only one IP packet or one PPP frame. If the size of the GRE frame doesn't exceed the MTU of the A0 connection, the BSN shall not split one IP packet or one PPP frame across two GRE frames; otherwise, the BSN shall use GRE segmentation as specified in [] to carry the IP packet or the PPP frame. The MS shall support both the segment-based framing and the HDLC-like framing with 0x ACCM. All flows in a specific RAN shall use the same framing mechanism (i.e., either segment-based framing or HDLC-like framing, but not both). When the BSN and the MS use the HDLC-like framing, they shall use a default Frame Check Sum (FCS) length of octets. If encryption is applied, encryption may be performed either in link layer or higher layer, but not both. If higher layer encryption is applied, SRTP [] shall be used. The BCMCS Content Server may send RTCP sender reports. The MS shall not send RTCP receiver reports (see [0]). The BCMCS codec and transport protocol is specified in [] BCMCS Flow ID Structure A pair of {Multicast IP Address and Transport Layer Port Number} identifies the destination multicast IP address and the destination transport layer (e.g., UDP) port number for a BCMCS IP flow. BCMCS Flow ID is an alias for a {Multicast IP Address and Transport Layer Port Number} pair. A BCMCS Flow ID is efficiently transported over the air (see [] and []), in contrast to the lengthy format of the {Multicast IP Address and Transport Layer Port Number}. Within the scope of a BCMCS Controller, there is a to K mapping from a Program Name to a set of BCMCS Flow ID, where K is an integer equal to or greater than. There is to mapping between a BCMCS Flow ID and a {Multicast IP Address and Transport Layer Port Number}. For example, an audiovisual program can have one Program Name and one or more BCMCS Flow ID(s). It could have one BCMCS Flow ID for the audio stream and a different BCMCS Flow ID for the video stream. BCMCS Flow ID has a length of bits, bits, or bits. It consists of the following three components: MSBs that is an identifier for the length of the Flow Discriminator; Variable length Program ID that is an identifier for the BCMCS program; Flow Discriminator that is an identifier for the BCMCS IP flow.

24 GPP X.S00-A v.0 Figure - shows an example of the structure of BCMCS Flow ID. When there is only one flow in a program, Flow Discriminator is not present in the BCMCS Flow ID and the value of the MSB of the BCMCS Flow ID shall be set to 000. Within the scope of an Operator s Network for a given program, the length of BCMCS_FLOW_ID and the length of Flow Discriminator shall be fixed for all flows. The integer value of the Program ID shall uniquely identify a program under a BCMCS Controller. For a given program, the integer value of the Flow Discriminator shall uniquely identify a flow. The Program ID values from to 0, from to, and from 0 to 0 are reserved. (Example with Flow Discriminator Length of bits). Example uses BCMCS Flow ID length of bits.. MSB's shall include the length in bits of the Flow Discriminator field. Boundary between BCMCS Program ID and Flow Discriminator fields indicated by valueof the MSB's. Structure allows upto ^ different Flow Discriminators per BCMCS Program ID Value of implies bits for Flow Discriminator Length of Flow Discriminator BCMCS Program ID Flow Discriminator Bit Bit Bit Bit Bit Bit 0 Bit Bit Bit Bit Bit Bit Bit Bit Bit Bit 0 0 BCMCS Flow ID Figure - An Example of the BCMCS Flow ID Structure The BCMCS Controller shall not change the mapping among the BCMCS Flow ID, {Multicast IP Address and Transport Layer Port Number} pair and other BCMCS session related parameters unless the program has ended or BAK lifetime expires.

25 GPP X.S00-A v.0 BCMCS Service Description BCMCS includes Service Discovery/Announcement, content subscriptions, BCMCS Information Acquisition, content availability determination, BCMCS registration, BCMCS content delivery, and BCMCS deregistration. 0. Service Discovery/Announcement BCMCS service announcement/discovery mechanisms allow users to request or be informed about available BCMCS services. The mobile users who desire BCMCS service may discover the BCMCS content and schedule via a BCMCS Controller acting as a server in communication with a client application on the user s terminal. Various other mechanisms such as advertisements, SMS, WAP, etc., may also be used to provide the MS with information on BCMCS contents and schedules. Service Discovery/Announcement is used to distribute to users information about the service, parameters required for Information Acquisition (e.g., Program Name) and possibly other service related parameters (e.g., service start time). 0. Content Subscriptions The user may subscribe to one or more BCMCS programs with the BCMCS Subscriber Profile Manager via out of band mechanisms that are outside the scope of this document. Note that for certain BCMCS, this step may not always be required and may occur prior to Service Discovery/Announcement. For encrypted service, a Registration Key (RK) (see []) is provisioned in both the UIM and the Subscription Profile Database. This may be done with OTA provisioning. After the RK is provisioned, the MS users who desire BCMCS programs requiring subscription can subscribe to them at any time via out of band mechanisms. Content subscriptions are outside the scope of this document.. BCMCS Information Acquisition The MS communicates with the BCMCS Controller to acquire the session related information such as the mapping between Multicast IP address/port and BCMCS Flow ID, the security level information, etc. See section for the details of the BCMCS Information Acquisition from the BCMCS Controller. 0. Content Availability Determination The MS determines whether a particular Multicast IP flow identified by a BCMCS_FLOW_ID is available, and if available, the BCMCS radio configuration parameters via over the air signaling messages[][]. Content availability determination is specified in []and [].. BCMCS Registration The MS may perform the BCMCS Registration to request delivery of one or more multicast IP flows identified by the BCMCS_FLOW_ID(s) or Program ID(s). The MS performs

26 GPP X.S00-A v.0 (re-)registrations, notifying the RAN of the BCMCS_FLOW_ID(s) or Program ID(s) that the MS is (continuing) to monitor. The operator may configure network parameters to notify the MS whether BCMCS registration and re-registration are required. BCMCS registration is specified in [], [] and [].. BCMCS Content Delivery Upon establishment of the bearer path as specified in section, the BCMCS content is delivered to the MS. Encryption and IP header compression may be applied prior to delivering the content to the MS. 0. BCMCS De-registration The MS may explicitly or implicitly perform BCMCS de-registration to notify the BS that the MS is no longer monitoring the Multicast IP Flow(s) identified by the BCMCS_FLOW_ID(s) or Program ID. BCMCS de-registration may occur via timeout at the BS if the lifetime of the BCMCS registration has expired and BCMCS re-registration has not been received. BCMCS de-registration is specified in[], [] and [].

27 GPP X.S00-A v.0 BCMCS Controller Discovery. Static BCMCS Controller Discovery The BCMCS Controller IP address or identifier (FQDN) may be provisioned in the MS Dynamic BCMCS Controller Discovery The MS may discover the BCMCS Controller via []. This section defines requirements for the Dynamic BCMCS Controller Discovery. Upon discovery of a BCMCS Controller, the MS uses the BCMCS Controller for BCMCS Information Acquisition (see section )... BCMCS Controller DHCP Option The MS uses the DHCPINFORM message to acquire BCMCS Controller IP address(es) and/or domain name(s) as specified in []. The DHCP server includes Broadcast Service Controller Domain Name list Option and/or Broadcast Service Controller IPv address option in the DHCPACK message to send BCMCS Controller IPv address(es) and/or BCMCS Controller Domain Name(s) to the MS as specified in [].... MS Requirements See [] for DHCP requirements on the MS. The MS shall support [] if the Dynamic BCMCS Controller Discovery is used to discover BCMCS Controller IPv addresses or domain names. The MS shall use the DHCPINFORM message to acquire the IP address and/or domain name of the BCMCS Controller as per []. If the MS acquires domain names according to [], the MS shall form SRV format as follows for DNS query: _bcmcs._tcp.domain... PDSN Requirements See [] for DHCP requirements on the PDSN.... DHCP Server Requirements Upon receiving a Relay message containing a DHCPINFORM message, if the DHCP server is configured with the BCMCS Controller information, the DHCP server shall include the BCMCS Controller IPv address and/or BCMCS Controller Domain Name(s) in a DHCPACK. The DHCP Server shall support []. The DHCP server shall send the DHCPACK to the MS.

28 GPP X.S00-A v BCMCS Controller DHCPv Option The MS uses Option-Request-Option in the INFORMATION-REQUEST message with option code set for requesting BCMCS Controller IP address/domain name (see []). The DHCPv server includes Broadcast Service Controller Domain Name list Option and /or Broadcast Service Controller IPv address option in the REPLY message to send BCMCS Controller IP address(es) and/or BCMCS Controller Domain Name(s) to the MS as specified in[].... MS Requirements The MS shall support [] if the Dynamic BCMCS Controller Discovery is used to discover BCMCS Controller IPv addresses and/or domain names. See [] for additional DHCPv requirements for the MS. If the MS sends INFORMATION-REQUEST message to request BCMCS Controller IP address(es) and/or BCMCS Controller Domain Name(s), the MS shall use Option-Request-Option in the INFORMATION-REQUEST message with option-code set for requesting BCMCS Controller IP address/domain name (see []). If the MS acquires domain names according to [], the MS shall form SRV format as follows for DNS query: _bcmcs._tcp.domain... PDSN Requirements See [] for additional DHCPv requirements for the PDSN.... DHCPv Server Requirements See [] for additional DHCPv server requirements. Upon receiving a Relay-Forward message containing an Information-Request message containing an option request option indicating BCMCS Controller IPv address and/or domain name (see[]), the DHCPv server shall include in a Reply the BCMCS Controller IP address and/or BCMCS Controller Domain Name(s).

29 GPP X.S00-A v BCMCS Information Acquisition After the MS discovers the BCMCS Controller s IP address, the MS acquires the following for each program or each multicast flow: Flow Identity Information, BCMCS Application Information, BCMCS Link Layer Information, and/or BCMCS Security Parameters. The MS can acquire information for one or more programs/flows at the same time. The Flow Identity Information returned from the BCMCS Controller in the BCMCS Information Acquisition Response includes the following: The mapping between Multicast IP address/port and BCMCS_FLOW_ID, Program allowed registration time (It indicates a time period in which the MS is not allowed to register on a BCMCS program. In other words, the MS is only allowed to register on a BCMCS program in the time period between the specified allowed registration time and the program end time.). The BCMCS Application Information returned from the BCMCS Controller in the BCMCS Information Acquisition Response includes the following: Program Name, Program Description, Program Schedule Time (the program start time and end time), A list of the following information corresponding to each IP flow: - Flow Description, - Multicast IP address/port number, - Transport Protocol: e.g., RTP/UDP etc, - Application Protocol: e.g., MPEG. The BCMCS Link Layer Information returned from the BCMCS Controller to the MS includes the following: Encryption Type (Link Layer or High Layer Encryption), Header Compression information: Algorithm (ROHC U mode, etc.), and parameters configuration. If the Link Layer information is provided to the MS via over-the-air signaling, it shall have precedence over the link layer information provided by the BCMCS Controller. The BCMCS Security Parameters returned from the BCMCS Controller to the MS includes the following: TK_RAND, Reduced Key Strength related parameters,

30 GPP X.S00-A v.0 A list of the following information corresponding to each IP flow which needs to be encrypted: - BAK_ID, BAK, and BAK Expiry time, - Registration Authorization Required Indicator MS Requirements The MS shall use HTTP [] to perform BCMCS Information Acquisition. The MS shall support the protocol and message format specified in section.. When the MS requests the BCMCS information from the BCMCS Controller, the MS shall include its NAI, time stamp, and the MS may send the system identity (i.e., SID/NID/PZID or Subnet) where the MS requests the BCMCS session information. To request information for a particular BCMCS Program/flow, the MS may use one of the following as an index to request the information. Program Name, Multicast IP address and port number, Program ID, BCMCS_FLOW_ID, Specific time (for example by specifying a start time and end time). The MS may request all programs available by not including any index described above. If the MS is requesting information for more than one BCMCS Program/flow in a single BCMCS Information Acquisition Request, the different index type may be used for requested BCMCS Program/flows. The MS may also indicate the types of information it wants to receive in the message, for example, BCMCS Application Information, BCMCS Link Layer Information, and/or BCMCS Security Parameters. The MS shall use the local time and shall include the time zone when specifying the StartTime or EndTime. The MS may fetch other BCMCS Information before fetching the BCMCS Security Parameters Information specified in section... If the MS receives a HTTP 0 with a WWW-Authenticate header in response to the Information Acquisition Request message, the MS should send a new Information Acquisition Request message containing an Authorization header as specified in []. If the 0 response contains the same challenge as the prior response, and the MS has already attempted authentication at least once, then the MS shall not re-attempt to send another Information Acquisition Request message with the same credentials. If the MS receives an HTTP 00 OK in response to the Information Acquisition Request message and it contains an Information Acquisition Reject, the MS may send a new Information Acquisition Request message to the BCMCS Controller to request new information.

31 GPP X.S00-A v.0 If the MS receives an HTTP 00 OK in response to the Information Acquisition Request message and it contains an Information Acquisition response for some but not all of the requested programs, the MS shall treat the programs that are not included as either unavailable or unauthorized in the network. If the MS receives an HTTP 00 OK in response to the Information Acquisition Request message and the response does not contain a required element or if the response is malformed, the MS shall silently discard the response. The MS may send a new Information Acquisition Request message to the BCMCS Controller. The MS shall use the message format specified in section BCMCS Controller Requirements The BCMCS Controller shall use HTTP to perform BCMCS Information Acquisition. The BCMCS Controller shall support [] and [] for HTTP transactions. The BCMCS Controller shall support the protocol and message format specified in section.. Upon receiving a BCMCS Information Acquisition Request message from the MS containing a request for BCMCS Flow Identity Information, Application Information, Security Information and/or Link Layer Information, the BCMCS Controller shall determine the availability of all the requested information and shall send a BCMCS Information Acquisition Response message that shall contain at least the Flow Identity Information (after authenticating and authorizing the MS if Security Information is required for a program). The BCMCS Controller may include a list of SID/NID/PZID or Subnet that share the same BCMCS session information. If the BCMCS Controller is required to perform security and accounting functions based on the user identity and the BCMCS Controller cannot resolve the user and domain based on the NAI element received in the BCMCS Information Acquisition Request message, then the BCMCS Controller shall send the BCMCS Information Acquisition Reject to the MS in an HTTP 00 OK indicating Invalid Request. If the Acquisition Request message from the MS does not request information for a particular flow or program, the BCMCS Controller shall include information about available programs based on the operator s policy in the BCMCS Information Response Message. If none of the requested programs are available, the BCMCS Controller shall send the BCMCS Information Acquisition Reject to the MS in an HTTP 00 OK to indicate the requested program(s) are not available. If the request includes Security Parameters Information, the BCMCS Controller shall initiate the user authentication and authorization with the RADIUS server to request Key information (Auth-Key and TK)[] and authorized program(s) information. Otherwise, the BCMCS Controller may initiate the user authentication and authorization with the RADIUS server based on local policy. If the BCMCS Controller performs the authorization, the BCMCS Controller shall include the Program Name in the RADIUS Access Request message. If the BCMCS Controller decides to initiate the user authentication and authorization, the BCMCS Controller shall determine the Program Names associated with the request. If the Program ID or the BCMCS_FLOW_ID is included in the request information, the BCMCS Controller shall convert the Program ID or BCMCS_FLOW_ID to the Program Name(s). The BCMCS Controller shall include Program Name(s) VSA in the RADIUS Access-Request message to the RADIUS server. If the

32 GPP X.S00-A v BCMCS Controller receives a RADIUS Access-Accept message from the RADIUS Server, the BCMCS Controller shall perform the following: If the Program Name VSA is included in the RADIUS Access-Accept message, the BCMCS Controller shall retrieve the authorized Program Name(s) from the Program Name VSA(s) included in the RADIUS Access-Accept message. Subsequently, the BCMCS Controller shall send the BCMCS Information Acquisition Response to the MS containing the BCMCS program information for the authorized and available program(s) in an HTTP 00 OK. For each encrypted flow of the authorized programs, the BCMCS Controller shall generate a BAK and may generate an additional BAK for subsequent use, and shall encrypt each BAK using the temporary key TK received in the RADIUS Access-Accept message. The BCMCS Controller shall send each encrypted BAK and the TK_RAND to the MS in a BCMCS Information Acquisition Response message. If the Program Name VSA is not included in the RADIUS Access-Accept message, the BCMCS Controller shall send the BCMCS Information Acquisition Reject to the MS in an HTTP 00 OK indicating Authorization has failed. If the BCMCS Controller decides to initiate the user authentication only for the MS that does not request the Security Parameters information, the BCMCS Controller shall not include Program Name(s) VSA in the RADIUS Access-Request Message to the RADIUS server. In this case, if the BCMCS Controller receives a RADIUS Access-Accept message from the RADIUS Server, the BCMCS Controller shall send the BCMCS Information Acquisition Response to the MS containing the BCMCS program information for the available programs in an HTTP 00 OK. If the BCMCS Controller receives a RADIUS Access-Reject message from the RADIUS server, the BCMCS Controller should send an HTTP 0 to the MS. If the MS requests both current BAK and subsequent BAK for a given flow, the BCMCS Controller may include both BAKs in the BCMCS Information Acquisition Response message. The BCMCS Controller may use the system identity (i.e., SID/NID/PZID or Subnet ID) received from the MS in the BCMCS Information Acquisition Request to send the information requested to the MS. If the BCMCS Controller uses the system identity received from the MS to determine that the requested program(s) are not available in the requested system, the BCMCS Controller shall use the Reason Code (see section...). The BCMCS Controller may specify a list of SID/NID/PZID or Subnet that share the same BCMCS session information in the BCMCS Information Acquisition Response message. If the BCMCS Controller receives a request with no time zone specified in the StartTime or EndTime, it shall send a BCMCS Information Acquisition Reject with the RejReason set to and the ReasonString set to Missing Timezone. If the BCMCS Controller sends an error indication in the BCMCS Information Acquisition Reject, the BCMCS Controller may terminate the TCP session to the MS. The BCMCS Controller shall use the message format specified in section.. 0. Home RADIUS Server Requirements See section... The Home RADIUS server shall support [] and [] to authenticate the user. If authentication fails, the Home RADIUS server shall send a RADIUS Access-Reject message back to the BCMCS Controller. If authentication is successful, the Home RADIUS server shall generate an Auth-Key. The Home RADIUS server shall distribute the Auth-Key to the BCMCS Controller in 0

33 GPP X.S00-A v.0 the RADIUS Access-Accept message for integrity protection of the BCMCS Information Acquisition Response message. The Home RADIUS server determines via the subscriber profile database if the user is allowed to use the cdma000 BCMCS network capability and is subscribed to the requested program included in the RADIUS Access-Request message. Upon receiving the RADIUS Access-Request message including the Program Name VSA(s), the Home RADIUS server shall include the Program Name VSA for each authorized programs within the requested Program Name list in the RADIUS Access-Accept message Protocol and Message Format The MS shall support [] and [] for HTTP transactions. BCMCS Information Acquisition Request/Response/Reject messages shall be coded using XML and transported via HTTP/TCP. If the MS cannot dynamically discover the port number of the BCMCS controller, the MS shall use port 0 for BCMCS Information Acquisition. The MS shall set the absolute path in the Request-URI to: /bcmcs/bcmcsinfo. The MS shall set the host header to the IP address or the FQDN of the BCMCS Controller. The MS shall use HTTP POST to provide client specific information to the BCMCS Controller. The message body of the POST message shall contain the Request element under the BCMCS tag. If the BCMCS Controller requires the authentication and integrity check, the BCMCS Controller shall send HTTP 0 Unauthorized with a WWW-Authenticate Header to the MS (see section 0..). Upon successful authentication from the Home RADIUS server, the BCMCS Controller shall respond to the MS s query using 00 OK where the message body of the 00 OK message shall contain either a Response or a Reject element under the BCMCS tag. 0. Message-body Tag Definitions Tags XML token defined by < >. For example <BCMCS> is a tag. Element basic unit of XML data, which is composed of a start-tag and end-tag with an optional content section. The data type of each element is given in the schema in section.. Each data type is represented in XML text according to existing XML schema standards []. Empty Element An element without a content section. (e.g., <TagExample></ TagExample>) Block A general term used to identify all of the contents within an element including any additional tags defined within the content.. MIME Type XML use with HTTP allows for multiple definitions of MIME type; for BCMCS Information Acquisition, the MIME type of application/vnd.gpp.bcmcsinfo+xml shall be used... HTTP Information Acquisition Request POST /bcmcs/bcmcsinfo HTTP/.

34 GPP X.S00-A v Host: BCMCS Controller IP address or FQDN Content-Type: application/vnd.gpp.bcmcsinfo+xml Content-Length: nnn <?xml version=.0?> Annex B. gives an example of the request body including BCMCS Information Acquisition Request... HTTP Information Acquisition Response HTTP/. 00 OK Content-Type: application/ vnd.gpp.bcmcsinfo+xml Content-Length: nnn <?xml version=.0?> Annex B. gives an example of the response body including BCMCS Information Acquisition Response... HTTP Information Acquisition Reject HTTP/. 00 OK Content-Type: application/ vnd.gpp.bcmcsinfo+xml Content-Length: nnn <?xml version=.0?> Annex B. gives an example of the response body including BCMCS Information Acquisition Reject... XML Elements This section specifies XML elements that are used by the MS and the BCMCS Controller to retrieve and response to Flow ID information, Application layer, link layer, and/or Security parameter information. The four blocks are identified by the FlowIDInfo, AppInfo, LinkInfo, and SecInfo elements respectively. Usage of Required Required is used to indicate that the element is required in a request from the MS to the BCMCS Controller or a response from the BCMCS Controller to the MS. Usage of Parent Parent is used to indicate the element to which the specified element is subordinate. The MS and the BCMCS Controller shall follow the semantics specified in this section and shall follow the syntax of the schema specified in section.. The descriptions under Parent and Required are only informative.

35 GPP X.S00-A v <BCMCS> Parent: None (root element) Required: Yes (All requests from the MS and responses from the BCMCS Controller) This element contains the following blocks for BCMCS Information Acquisition Request, Response, and Reject. This is the master block tag, all BCMCS specific elements/tags shall be contained within this tag.... <Request> Parent: BCMCS Required: No This element shall contain at least one of the following blocks for BCMCS Information Acquisition Request.... <NAI> Parent: Request Required: Yes The element shall contain the user NAI. For Example: <NAI>name@carrier.com</NAI>... <PgmInfo> Parent: Request Required: No This element may contain the characteristics of the media stream that is requested by the MS. Lack of this element implies that the MS request all flows information for all types that are available in the BCMCS Controller.... <RequestType> Parent: PgmInfo Required: Yes This element shall contain the RequestTypeVal requested by the MS from the BCMCS Controller.... <RequestTypeVal> Parent: RequestType Required: Yes This element shall contain the information type requested by the MS from the BCMCS Controller. At least one of AppInfo, LinkInfo, SecInfo, FlowIDInfo shall be specified. Flow information is automatically included when AppInfo, LinkInfo or SecInfo is specified. Therefore, if the MS only request flow information, the FlowIDInfo shall be used. All is used to get all information. When All is specified, any other value is ignored. Example :

36 GPP X.S00-A v <RequestType> <RequestTypeVal>All</RequestTypeVal> </RequestType> Example : <RequestType> <RequestTypeVal>AppInfo</RequestTypeVal> <RequestTypeVal>LinkInfo</RequestTypeVal> <RequestTypeVal>SecInfo</RequestTypeVal> </RequestType>... <BAKReq> Parent: PgmInfo Required: No This element shall only be present if the MS sets the RequestTypeVal to All or SecInfo. This element shall indicate whether the MS requests the current BAK, Subsequent BAK, or both from the BCMCS Controller. Example : <BAKReq>CurrentBAK</BAKReq> Example : <BAKReq>SubsequentBAK</BAKReq> Example : <BAKReq>BothBAK</BAKReq>... <ReqInfo> Parent: PgmInfo Required: No This element shall contain an index that is used by the MS to acquire the BCMCS session information. Lack of this element implies that the MS requests all flows information for the requested types that are available in the BCMCS Controller. If this element is present, the MS shall include only one of the elements specified in the following subsections under section <PgmName> Parent: ReqInfo Required: No This element shall contain the BCMCS Program Name associated with the application content. For example: <PgmName>TV-Channel-News</PgmName>... <IPPort> Parent: ReqInfo Required: No

37 GPP X.S00-A v This element shall contain the multicast group and port associated with the application content by way of IP address (IPv or IPv) and port number.... <IPAddress> Parent: IPPort Required: Yes This element shall contain either IPv or IPv address of the BCMCS Controller.... <IPv> Parent: IPAddress Required: No This element shall contain the IPv address. For example: <IPv>.0.0.</IPv>... <IPv> Parent: IPAddress Required: No This element shall contain the IPv address. The IPv Address syntax shall conform to [] except :: is not used in this document. IPv representation supports an alternative form that is sometimes more convenient when dealing with a mixed environment of IPv and IPv nodes. An IPv address is specified as x:x:x:x:x:x:d.d.d.d, where the x s are the hexadecimal values of the six high-order -bit pieces of the address, and the d s are the decimal values of the four low-order -bit pieces of address (standard IPv representation). Example : <IPv>0:FEDC:0:0:0:0:0:FFEDC</IPv> Example : <IPv>0:FEDC:0:0:0:0:.0..0</IPv>... <Port> Parent: IPPort Required: Yes This element shall contain the IP port with the range from 0 to inclusive. If the MS requests all ports associated with the IP address, the MS shall set the value of this element to 0. Example : <Port></Port> Example : <Port>0</Port>... <FlowID> Parent: ReqInfo Required: No

38 GPP X.S00-A v This element shall contain the hex representation of the BCMCS_FLOW_ID. The length of the BCMCS_FLOW_ID can be determined by the representation. Example : <FlowID>00B</FlowID> (Example for bits length) - this indicates BCMCS_FLOW_ID as binary representation of ' '. Example : <FlowID>00000B<FlowID> (Example for bits length) - this indicates BCMCS_FLOW_ID as binary representation of ' '.... <PgmID> Parent: ReqInfo Required: No This element shall contain the Program ID. For example: <PgmID></PgmID>... <PgmSched> Parent: ReqInfo Required: No This element shall contain the program schedule for the program that the MS requests from the BCMCS Controller. The MS can indicate that it requests all flows that occur from StartTime to EndTime. If this element is present, it shall contain either StartTime or EndTime, or both elements.... <StartTime> Parent: PgmSched Required: No This element shall contain the program start time for the program that the MS requests from the BCMCS Controller. If the MS requests all programs that are available from any start time until the specified end time, this field shall be omitted. The Date-Time representation shall be immediately followed by either Z, to indicate that the local time is the same as UTC, or a time zone which contains a sign, + or -, followed by the difference between the local time and UTC represented as hh:mm. Example : <StartTime>00-0-0T::.000Z</ StartTime>- If the MS is in UTC time zone, it represents the time zone with Z. Example : <StartTime>00-0-0T:0:00-0:00</StartTime> - This indicates that the start time is :0 pm on May 0, 00 Eastern Standard Time (which is hours behind UTC).... <EndTime> Parent: PgmSched Required: No

39 GPP X.S00-A v This element shall contain the program end time for the program that the MS requests from the BCMCS Controller. If the MS requests all of the programs that are available from the specified start time until any end time, this field shall be omitted. The Date-Time representation shall be immediately followed by either Z, to indicate that the local time is the same as UTC, or a time zone which contains a sign, + or -, followed by the difference between the local time and UTC represented as hh:mm. Example : <EndTime>00-0-0T::.000Z</EndTime> - If the MS is in UTC time zone, it represents the time zone with Z. Example : <EndTime>00-0-0T:0:00-0:00</EndTime> - This indicates that the end time is :0 pm on May 0, 00 Eastern Standard Time (which is hours behind UTC).... <TimeStamp> Parent: Request Required: Yes This element shall contain the time stamp with a value indicating the time that the MS sends the Information Acquisition Request message to prevent replay attack by a rogue BCMCS Controller on the link. This element shall be set to a value in seconds since January, 0 00:00 UTC. For example: <TimeStamp>00000</TimeStamp>... <ReqSysInfo> Parent: Request Required: No This element shall contain the system identity from which the MS requests BCMCS session information.... <SystemInfo> Parent: ReqSysInfo Required: No This element shall contain the general system identity from which the MS requests BCMCS session information.... <SID> Parent: SystemInfo Required: Yes This element shall contain the system identity (SID) from which the MS requests BCMCS session information. For Example: <SID>0</SID>

40 GPP X.S00-A v <NID> Parent: SystemInfo Required: No The element shall contain the network identity (NID) from which the MS requests BCMCS session information. Lack of this element implies the MS requests information in all NIDs under the SID specified in... For example: <NID>0</NID>... <PZID> Parent: SystemInfo Required: No The element shall contain the packet zone identity (PZID) from which the MS requests BCMCS session information. Lack of this element implies the MS requests information in all PZIDs under the SID specified in... or the NID specified in... For example: <PZID>0</PZID>... <SubnetInfo> Parent: ReqSysInfo Required: No The element shall contain the subnet information from which the MS requests BCMCS session information.... <SubnetLen> Parent: SubnetInfo Required: Yes The element shall contain the number of bits in the subnet identifier. These bits shall form the most significant bits of any sector identifier within the subnet (see []). For example: <SubnetLen>0</SubnetLen>... <SubnetID> Parent: SubnetInfo Required: Yes The element shall contain a decimal representation of the subnet value for the subnet from which the MS requests the BCMCS session information. For example: <SubnetID></SubnetID>

41 GPP X.S00-A v <Response> Parent: BCMCS Required: No This Element shall contain at least one of the responses from the BCMCS Controller for BCMCS Information Acquisition.... <BCMCSInfo> Parent: Response Required: Yes This Element shall contain the BCMCS session information that is requested by the MS.... <GenInfo> Parent: BCMCSInfo Required: No The element shall contain the general system identifiers where the BCMCS block is valid. If the element is omitted, it means the information is valid for the whole system.... <SysInfo> Parent: GenInfo Required: No The element shall contain the general system identifiers where the BCMCS block is valid.... <SID> Parent: SysInfo Required: Yes This element shall contain the system identifiers where the BCMCS block is valid. For Example: <SID>0</SID>... <ID> Parent: SysInfo Required: No The element shall contain the network identifiers and/or packet data zone identifiers where the BCMCS block is valid. If this element is omitted, it means the BCMCS block is valid under the system specified by SID.... <NID> Parent: ID Required: No The element shall contain the network identifiers where the BCMCS block is valid. If the BCMCS block is valid for all NID under the specified SID, this element shall be omitted.

42 GPP X.S00-A v For Example: <NID>0</NID>... <PZID> Parent: ID Required: No The element shall contain the packet zone identifiers where the BCMCS block is valid. If the BCMCS block is valid for all PZID under specified SID or NID, this element shall be omitted. For Example: <PZID>0</PZID>... <SubnetInfo> Parent: GentInfo Required: No The element shall contain the subnet information where the BCMCS block is valid. If the BCMCS block is valid for all subnets, this element shall be omitted.... <SubnetLen> Parent: SubnetInfo Required: Yes The element shall contain the number of bits in the subnet identifier. These bits shall form the most significant bits of any sector identifier within the subnet (see []). For Example: <SubnetLen>0</SubnetLen>... <SubnetID> Parent: SubnetInfo Required: Yes This element shall contain a decimal representation of the subnet value for the subnet where the BCMCS block is valid. For Example: <SubnetID></SubnetID>... <PgmInfo> Parent: BCMCSInfo Required: Yes This element shall contain the characteristics of the BCMCS program that is requested by the MS. The PgmInfo element contains FlowIDinfo, AppInfo, LinkInfo, and/or SecInfo.... < FlowIDInfo> Parent: PgmInfo Required: Yes 0

43 GPP X.S00-A v This element shall contain the BCMCS flow identity information that is requested by the MS.... <FlowID> Parent: FlowIDInfo Required: Yes The element shall contain the BCMCS FLOW ID. It shall be the hex representation of the BCMCS_FLOW_ID. The length of the BCMCS_FLOW_ID can be determined by the representation. Example : <FlowID>00B</FlowID> (Example for bits length) - this indicates BCMCS_FLOW_ID as binary representation of ' '. Example : <FlowID>00000B</FlowID> (Example for bits length) - this indicates BCMCS_FLOW_ID as binary representation of ' '.... <IPPort> Parent: FlowIDInfo Required: Yes This element shall contain the multicast IP address associated with the application content by way of IP address (IPv or IPv) and port number.... <IPAddress> Parent: IPPort Required: Yes This element shall contain the multicast group and port associated with the application content by way of IP address (IPv or IPv).... <IPv> Parent: IPAddress Required: No This element shall contain the IPv address. For example: <IPv>.0.0.</IPv>... <IPv> Parent: IPAddress Required: No This element shall contain the IPv address. The IPv Address syntax shall conform to [] except :: is not used in this document. IPv representation supports an alternative form that is sometimes more convenient when dealing with a mixed environment of IPv and IPv nodes. An IPv address is specified as x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order -bit pieces of the address, and the 'd's are the decimal values of the four low-order -bit pieces of the address (standard IPv representation). Example :

44 GPP X.S00-A v <IPv>0:FEDC:0:0:0:0:0:FEDC</IPv> Example : <IPv>0:FEDC:0:0:0:0:.0..0</IPv>... <Port> Parent: IPPort Required: Yes This element shall contain the IP port with the range from 0 to inclusive. For example: <Port></Port>... <AllowRegTime> Parent: PgmIDInfo Required: No This element shall contain the allowed registration time by the MS. This element shall be set to the period before program start time in units of seconds. For example: <AllowRegTime>00</AllowRegTime>... <AppInfo> Parent: PgmInfo Required: No This element shall contain the information that is specific to the application such as program name, program schedule, and media format etc. If this element is present, it shall only contain the application information for the flows that are specified in FlowIDInfo under the given PgmInfo.... <SDP> Parent: AppInfo Required: Yes This element shall contain the application information using the format specified in []. The application information may include the program name, program description, program start time, end time, multicast IP address/port, transport protocol, and media format etc.... <LinkInfo> Parent: PgmInfo Required: No This element shall contain the link layer information required by the MS to receive the BCMCS transmission. If the MS requests link layer information and this element is omitted, the MS shall use the following default link layer information: The MS shall not apply the header compression. The MS shall use the encryption indicated by the over the air signaling message if received; otherwise, the MS shall not apply the encryption.

45 GPP X.S00-A v If this element is present, it shall contain the link information for all flows that are specified in the FlowIDInfo under the given PgmInfo.... <EncType> Parent: LinkInfo Required: Yes This element shall indicate whether link layer encryption or high layer encryption is used For example: < EncType>LinkLayer</EncType>... <HeadComType> Parent: LinkInfo Required: No This element shall contain the header compression information. If this element is omitted, it means no header compression is performed. For example: <HeadComType>ROHC-U</HeadComType>... <ROHC-U> Parent: HeadComType Required: No This element shall contain the header compression information for ROHC U mode.... <CID> Parent: ROHC-U Required: Yes This element shall contain CID related parameters.... <MaxCID> Parent: CID Required: No This element indicates the maximum number of contexts used. For example: <MaxCID>0</MaxCID>... <CIDType> Parent: CID Required: Yes This element indicates whether large CID or small CID is used. For example: <CIDType>Large</CIDType>

46 GPP X.S00-A v <ComProfile> Parent: ROHC-U Required: Yes This element shall contain the compression profile used. It shall be the hex representation of the compression profile. The length of the compression profile can be determined by the representation. For example: <ComProfile>000</ComProfile>... <MaxHeadSize> Parent: ROHC-U Required: No This element shall contain the maximum header size, in octets, that can be compressed. For example: <MaxHeadSize></MaxHeadSize>... <MRRU> Parent: ROHC-U Required: No This element shall contain the size of the Maximum Reconstructed Reception Unit, in octets, that the decompressor is expected to reassemble from segments. Value 0 or lack of the element means that no segment headers are allowed on the channel. For example: <MRRU>00</MRRU>... <SecInfo> Parent: PgmInfo Required: No The element shall contain the security parameters associated with the BCMCS Flow. If this element is present, it shall only contain the security information for the flows that are specified in FlowIDInfo under the given PgmInfo.... <TK_RAND> Parent: SecInfo Required: Yes This element shall contain the TK_RAND []: For example: <TK_RAND></TK_RAND>... <RedKeyStren> Parent: SecInfo Required: No

47 GPP X.S00-A v This element shall contain the parameters used for reduced key strength.... <SaltLen> Parent: RedKeyStren Required: No This element shall contain the length of the salt, in units of bits.... <Salt> Parent RedKeyStren Required: No This element shall contain the value of salt.... <KeyEntropy> Parent: RedKeyStren Required: No This element shall contain the key entropy.... <SecFlowInfo> Parent: SecInfo Required: Yes This element shall contain the security flow information.... <FlowID> Parent: SecFlowInfo Required: Yes This element shall contain the BCMCS FLOW ID. It shall be the hex representation of the BCMCS_FLOW_ID. The length of the BCMCS_FLOW_ID can be determined by the representation. Example : <FlowID>00B</FlowID> (Example for bits length) - this indicates BCMCS_FLOW_ID as binary representation of ' '. Example : <FlowID>00000B</FlowID> (Example for bits length) - this indicates BCMCS_FLOW_ID as binary representation of ' '.... <BAK_ID> Parent: SecFlowInfo Required: Yes This element shall contain the BAK_ID[]. For example: <BAK_ID></BAK_ID>... <EncrBAK>

48 GPP X.S00-A v Parent: SecFlowInfo Required: No This element shall contain the BAK that is encrypted by TK[].... <BAKExpTime> Parent: SecFlowInfo Required: Yes This element contains the BAK expiry time. The Date-Time representation shall be immediately followed by either Z, to indicate that the local time is same as UTC, or a time zone which contains a sign, + or -, followed by the difference between the local time and UTC represented as hh:mm. Example : <BAKExpTime>00-0-0T::.000Z</BAKExpTime> If the BCMCS Controller is in UTC time zone, it represents the time zone with Z. Example : <BAKExpTime>00-0-0T:0:00-0:00</BAKExpTime> - This indicates that the end time is :0 pm on May 0, 00 Eastern Standard Time (which is hours behind UTC).... <AuthReq> Parent: SecFlowInfo Required: Yes This element shall indicate whether the corresponding flow requires authorization signature from the MS. This requirement shall override the requirement received from over the air signaling (see [] and []). For example: <AuthReq>True</AuthReq>... <Reject> Parent: BCMCS Required: No This element shall contain the following blocks for BCMCS Information Acquisition Reject.... <RejReason> Parent: Reject Required: Yes This element shall contain the reject reason for BCMCS Information Acquisition Reject. The reject reason is specified as follows:. Authorization has failed.. Requested program(s) or flow(s) is not available.. The schema version is not supported.. Requested program(s) or flow(s) is not available in the requested system.

49 GPP X.S00-A v Missing Timezone.. Invalid Request.. Request Information is not available.. Unknown Reason. For example: <RejReason></RejReason>... <ReasonString> Parent: Reject Required: Yes This element shall contain the reason string for BCMCS Information Acquisition Reject. The reason string gives the reason corresponding to the reject reason value. For example: <ReasonString>The schema version is not supported</reasonstring>... <ListSchemaVerSup> Parent: Reject Required: No This element shall contain the schema versions that the BCMCS Controller supports. This element is present only when the Reject reason is.... <SchemaVer> Parent: ListSchemaVerSup Required: Yes This element shall list the schema versions that the BCMCS Controller supports. This element shall be coded as {Major Version.Minor Version}. The Major Version may not be backward compatible. The Minor Version shall be backward compatible for the same Major Version. For example: <ListSchemaVerSup> <SchemaVer>.0</SchemaVer> <SchemaVer>.</SchemaVer> </ListSchemaVerSup>

50 GPP X.S00-A v XML Schema <?xml version=".0" encoding="utf-"?> <xs:schema targetnamespace=" xmlns:gpp=" xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="bcmcs"> <xs:annotation> <xs:documentation>bcmcs Information</xs:documentation> </xs:annotation> <xs:complextype> <xs:choice> <xs:element name="request"> <xs:complextype> <xs:sequence> <xs:element name="nai" type="xs:string"> <xs:annotation> <xs:documentation>nai of the user making the request</xs:documentation> </xs:annotation> </xs:element> <xs:element name="pgminfo" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="requesttype"> <xs:complextype> <xs:sequence> <xs:element name="requesttypeval" type="gpp:requesttypeenum" maxoccurs=""/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="bakreq" minoccurs="0"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="bothbak"/> <xs:enumeration value="subsequentbak"/> <xs:enumeration value="currentbak"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="reqinfo" minoccurs="0"> <xs:complextype> <xs:choice> <xs:element name="pgmname" type="xs:string">

51 GPP X.S00-A v <xs:annotation> <xs:documentation>program Name</xs:documentation> </xs:annotation> </xs:element> <xs:element name="ipport" type="gpp:ipaddressandport"/> <xs:element name="flowid" type="gpp:flowid"> <xs:annotation> <xs:documentation>bcmcs_flow_id of the content</xs:documentation> </xs:annotation> </xs:element> <xs:element name="pgmid" type="xs:unsignedint"/> <xs:element name="pgmsched"> <xs:complextype> <xs:sequence> <xs:element name="starttime" type="xs:datetime" minoccurs="0"/> <xs:element name="endtime" type="xs:datetime" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="timestamp" type="xs:unsignedlong"/> <xs:element name="reqsysinfo" minoccurs="0"> <xs:complextype> <xs:choice> <xs:element name="systeminfo"> <xs:complextype> <xs:sequence> <xs:element name="sid" type="xs:unsignedshort"/> <xs:element name="nid" type="xs:unsignedshort" minoccurs="0"/> <xs:element name="pzid" type="xs:unsignedshort" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="subnetinfo" type="gpp:subnetinfo"/> </xs:choice> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element>

52 GPP X.S00-A v <xs:element name="response"> <xs:complextype> <xs:sequence> <xs:element name="bcmcsinfo" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="geninfo" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="sysinfo" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="sid" type="xs:unsignedshort"/> <xs:element name="id" minoccurs="0" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="nid" type="xs:unsignedshort" minoccurs="0"/> <xs:element name="pzid" type="xs:unsignedshort" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="subnetinfo" type="gpp:subnetinfo" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="pgminfo" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="flowidinfo" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="flowid" type="gpp:flowid"/> <xs:element name="ipport" type="gpp:ipaddressandport"/> <xs:element name="allowregtime" type="xs:unsignedshort" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="appinfo" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="sdp" type="xs:anytype"/> </xs:sequence> 0

53 GPP X.S00-A v </xs:complextype> </xs:element> <xs:element name="linkinfo" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="enctype"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="linklayer"/> <xs:enumeration value="upperlayer"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="headcomptype" minoccurs="0"> <xs:complextype> <xs:choice> <xs:element name="rohc-u"> <xs:complextype> <xs:sequence> <xs:element name="cid"> <xs:complextype> <xs:sequence> <xs:element name="maxcid" type="xs:unsignedshort" minoccurs="0"/> <xs:element name="cidtype"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="small"/> <xs:enumeration value="large"/> </xs:restriction> </xs:simpletype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="compprofile" type="xs:hexbinary"/> <xs:element name="maxheadsize" type="xs:unsignedshort"/> <xs:element name="mrru" type="xs:unsignedint" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype>

54 GPP X.S00-A v </xs:element> <xs:element name="secinfo" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="tk_rand" type="xs:unsignedlong"/> <xs:element name="redkeystren" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="saltlen" type="xs:unsignedint"/> <xs:element name="salt" type="xs:unsignedint"/> <xs:element name="keyentropy" type="xs:unsignedint"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="secflowinfo" maxoccurs="unbounded"> <xs:complextype> <xs:sequence> <xs:element name="flowid" type="gpp:flowid"/> <xs:element name="bak_id"> <xs:simpletype> <xs:restriction base="xs:unsignedbyte"> <xs:mininclusive value="0"/> <xs:maxinclusive value=""/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="encrbak" type="xs:positiveinteger"/> <xs:element name="bakexptime" type="xs:datetime"/> <xs:element name="authreq" type="xs:boolean"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="reject">

55 GPP X.S00-A v <xs:complextype> <xs:sequence> <xs:element name="rejreason" type="xs:unsignedbyte"/> <xs:element name="reasonstring" type="xs:string"/> <xs:element name="listschemaversup" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="schemaver" type="gpp:ver" maxoccurs=""/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> <xs:attribute name="ver" type="gpp:ver" use="required" fixed=".0"/> </xs:complextype> </xs:element> <xs:simpletype name="requesttypeenum"> <xs:annotation> <xs:documentation>enumeration of types of information that can be requested</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value="all"/> <xs:enumeration value="appinfo"/> <xs:enumeration value="linkinfo"/> <xs:enumeration value="secinfo"/> <xs:enumeration value="flowidinfo"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="ver"> <xs:annotation> <xs:documentation>indicates the schema version</xs:documentation> </xs:annotation> <xs:restriction base="xs:decimal"> <xs:pattern value=" d{,}. d{,}"/> </xs:restriction> </xs:simpletype> <xs:complextype name="subnetinfo"> <xs:annotation> <xs:documentation>subnet Info</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="subnetid" type="xs:positiveinteger"/> <xs:element name="subnetlen">

56 GPP X.S00-A v <xs:simpletype> <xs:restriction base="xs:unsignedbyte"/> </xs:simpletype> </xs:element> </xs:sequence> </xs:complextype> <xs:simpletype name="ipvaddresstype"> <xs:annotation> <xs:documentation>ipv address plus port</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minlength value=""/> <xs:maxlength value=""/> <xs:pattern value="([ d]{,}.){}[ d]{,}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="ipvaddresstype"> <xs:annotation> <xs:documentation>ipv address as per RFC "::" not supported</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:minlength value=""/> <xs:maxlength value=""/> <xs:pattern value="([ da-fa-f]{,}:){}(([ da-fa-f]{,}:[ da-fa-f]{,}) (([ d]{,}.){}[ d]{,}))"/> </xs:restriction> </xs:simpletype> <xs:complextype name="ipaddressandport"> <xs:annotation> <xs:documentation>ip address (IPv or IPv) and port</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="ipaddress"> <xs:complextype> <xs:choice> <xs:element name="ipv" type="gpp:ipvaddresstype"/> <xs:element name="ipv" type="gpp:ipvaddresstype"/> </xs:choice> </xs:complextype> </xs:element> <xs:element name="port"> <xs:simpletype> <xs:restriction base="xs:integer"> <xs:mininclusive value="0"/> <xs:maxinclusive value=""/> </xs:restriction>

57 GPP X.S00-A v </xs:simpletype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="utcdatetime"> <xs:annotation> <xs:documentation>date and Time interpreted as UTC</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="date"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:length value="0"/> <xs:pattern value="([0-]){}-(([0][-]) ([][0-]))-(([0][-]) ([-][0-]) ([][0-]))"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="time"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:length value=""/> <xs:pattern value="(([0-][0-]) ([][0-])):[0-][0-]:[0-][0-]"/> </xs:restriction> </xs:simpletype> </xs:element> </xs:sequence> </xs:complextype> <xs:simpletype name="flowid"> <xs:restriction base="xs:hexbinary"> <xs:minlength value=""/> <xs:maxlength value=""/> </xs:restriction> </xs:simpletype> </xs:schema>

58 GPP X.S00-A v.0 BCMCS Controller and Content Server Interface The interface between the BCMCS Controller and the Content Server uses the CS-BCMCS Control Protocol that provides a mechanism for the BCMCS Controller to provision BCMCS Flows on the CS, and for the CS to provide BCMCS Flows information to the BCMCS Controller BCMCS Flow Life Cycle When provisioning a BCMCS Flow for a multicast address/port the BCMCS Controller chooses a BCMCS Flow Handle that the BCMCS Controller and CS use to reference the flow. A BCMCS Flow Handle references a unique BCMCS Flow provisioning on the Content Server and has a BCMCS Flow ID associated with it. The same BCMCS Flow ID may be provisioned in multiple ways, as long as they do not overlap in time. Consequently, different BCMCS Flow Handles may have the same associated BCMCS Flow ID. Each BCMCS Flow Handle shall be in one of the three states described below. Reception of messages or events, such as moving past the StartTime or EndTime of a BCMCS Flow, shall trigger transitions between these states. A BCMCS Flow Handle is defined to be active at a point in time if it is assigned to a BCMCS Flow provisioned with an end time in the future. When the end time of a provisioned BCMCS Flow is passed, the BCMCS Flow Handle shall be returned to the inactive state. Inactive BCMCS Flow Handles are available for assignment to a new BCMCS Flow provisioning. The BCMCS Controller may change the start and end times of a BCMCS Flow Handle. The BCMCS Controller may remove a provisioned BCMCS Flow before scheduled end time. When a flow is removed, the BCMCS Flow Handle shall return to the Inactive state.

59 GPP X.S00-A v.0 Inactive Unsuccessful AddFlowRequest Successful AddFlowRequest Successful RemoveFlowRequest Flow Removal caused by SuccessfulResetRequest Flow Removal caused by Successful ResetRequest Successful RemoveFlowRequest Flow EndTime Reached Active, Idle (Flow not started) Successful/Unsuccessful ModifyFlowRequest Flow StartTime Reached Active, Busy (Flow started) Successful/Unsuccessful ModifyFlowRequest Note: Not all state transitions for unsuccessful cases are shown. Figure - BCMCS Flow Handle States 0.. Inactive State This is the initial state of BCMCS Flow Handle. The BCMCS Controller shall maintain a pool of unassigned BCMCS Flow Handles to facilitate provisioning of BCMCS Flows. When a BCMCS Flow is created by a successful AddFlowRequest, the BCMCS Flow Handle shall transition to the {Active, Idle} state... {Active, Idle} State In this state the resources for corresponding BCMCS Flow are provisioned at the BCMCS controller and CS but the BCMCS Flow is not actively transmitted from the CS. When a BCMCS Flow is removed by a successful RemoveFlowRequest, the BCMCS Flow Handle shall transition to the Inactive state and the BCMCS Flow shall be removed from the BCMCS Controller and CS. A successful or unsuccessful ModifyFlowRequest shall maintain the BCMCS Flow Handle in the {Active, Idle} state. If a successful ResetRequest requires the provisioned BCMCS Flow Handle to be removed, the BCMCS Flow Handle shall transition to the Inactive state. If the start time for BCMCS Flow is reached, then the BCMCS Flow Handle shall transition to the {Active, Busy} state.

60 GPP X.S00-A v.0.. {Active, Busy} State In this state, the corresponding BCMCS Flow is actively transmitted. When a BCMCS Flow is removed by a successful RemoveFlowRequest, the BCMCS Flow Handle shall transition to the Inactive state. The provisioned BCMCS Flow is removed from the BCMCS Controller and CS. A successful or unsuccessful ModifyFlowRequest shall maintain the BCMCS Flow Handle in the {Active, Busy} state. If a successful ResetRequest requires the provisioned BCMCS Flow Handle to be removed, the BCMCS Flow Handle shall transition to the Inactive state. If the end time for the BCMCS Flow is reached, then the BCMCS Flow Handle shall transition to the Inactive state. 0. CS-BCMCS Control Protocol The CS-BCMCS Control messages shall use the TCP [] as a transport protocol. TCP port number is configurable.. CS-BCMCS Control Protocol Messages Table - lists the CS-BCMCS Control Protocol message types. Table - CS-BCMCS Control Protocol Message Message Type Description Valid state AddFlowRequest Sent by the BCMCS Controller to request adding Inactive one or more BCMCS Flows associated with one program. AddFlowResponse Sent by the CS with result of AddFlowRequest Inactive message. ModifyFlowRequest Sent by the BCMCS Controller to request {Active, Idle}, modifying parameters of one or more {Active, Busy} provisioned BCMCS Flows. ModifyFlowResponse Sent by the CS with result of {Active, Idle}, ModifyFlowRequest message. {Active, Busy} RemoveFlowRequest Sent by the BCMCS Controller to request {Active, Idle}, RemoveFlowResponse FlowInformation FlowInformationResponse ResetRequest ResetResponse RefreshKeyRequest removing one or more BCMCS Flow(s). Sent by the CS with result of RemoveFlowRequest message. Sent by the CS to provide the flow information associated with one program. Sent by the BCMCS Controller with result of FlowInformation message. Sent by either CS or BCMCS Controller to synchronize the flow state. Sent by either CS or BCMCS Controller in response to the ResetRequest message. Sent by the CS to the BCMCS Controller to request the BAK related to one or more existing Flow Handles(s). {Active, Busy} Inactive, {Active, Idle}, {Active, Busy} Inactive Inactive Inactive, {Active, Idle}, {Active, Busy} Inactive, {Active, Idle}, {Active, Busy} {Active, Idle}, {Active, Busy}

61 GPP X.S00-A v.0 RefreshKeyResponse Sent by the BCMCS Controller to the CS to provide the new BAK(s) related to Flow Handle(s), either in response to the RefershKeyRequest message or autonomously sent before the BAK expiry time. {Active, Idle}, {Active, Busy} The messages shall be exchanged only in the valid state. If a message is received in Invalid state, the receiver (either the CS or BCMCS Controller) shall send the corresponding response message corresponding to that flow with ResultCode set to INVALID_STATE... CS-BCMCS Control Protocol Message Procedures Add BCMCS Flow The AddFlowRequest message is sent by the BCMCS Controller to the CS to request provisioning at the CS for one or more BCMCS Flows associated with one program. The CS can accept or deny the request through the AddFlowResponse message.... CS Functional Requirements If the AddFlowRequest is accepted, the CS shall send an AddFlowResponse message with the ReasonCode IE set to SUCCESS to the BCMCS Controller. The CS shall initiate BCMCS Flow of content at the scheduled start time. If the CS receives an AddFlowRequest with End Time earlier than Start Time for a particular flow, it shall reject that flow and shall set the ResultCode corresponding to that flow to INVALID_PARAMETER_VALUE and add the EndTime and StartTime IEIs (Information Element Identifiers, see section..), in the FailedParameter element for that flow. If the CS receives an AddFlowRequest with parameters outside their defined range for a particular flow, it shall set the ResultCode corresponding to that flow to INVALID_PARAMETER_VALUE and add their IEIs in the FailedParameter element for that flow.... BCMCS Controller Functional Requirements When the BCMCS Controller provisions one or more BCMCS Flows, it shall send an AddFlowRequest message to the CS. All BCMCS Flows in an AddFlowRequest message shall be associated with one program. The BCMCS Controller shall set StartTime greater than current time and EndTime grater than StartTime. The BCMCS Controller shall send an AddFlowRequest T RECV seconds start of the flow(s). in advance before the 0 The BCMCS Controller shall allocate a multicast IP address/port associated with the flow. The BCMCS Controller is the central entity managing the multicast IP address/ports allocation to flows. The value of T RECV is an implementation specific value or configurable by the operator.

62 GPP X.S00-A v If the BAKParameter IE is included in the AddFlowRequest, the BCMCS Controller should use TLS-PSK [] as a secure channel between the BCMCS Controller and CS. If the BCMCS Controller receives the AddFlowResponse with the ResultCode set to other than SUCCESS, it shall remove the BCMCSFlowHandle(s).... Modify BCMCS Flow The ModifyFlowRequest message is sent by the BCMCS Controller to the CS to modify start time and/or end time of one or more BCMCS Flows provisioned through an AddFlowRequest message. Two types of modifications are allowed: Changing the start and/or end times. Extending the end time of a BCMCS Flow(s) in progress.... CS Functional Requirements The CS shall send a ModifyFlowResponse message to a BCMCS Controller within T resp milliseconds of receiving a ModifyFlowRequest message. If the ModifyFlowRequest is accepted, the CS shall send a ModifyFlowResponse message with the ReasonCode IE set to SUCCESS to the BCMCS Controller. If the CS receives a ModifyFlowRequest message with one of the following conditions: StartTime grater than EndTime, StartTime earlier than the current time and the StartTime is not equal to the actual start time of the BCMCS Flow. Then, the CS shall send the ModifyFlowResponse message with the ReasonCode IE set to INVALID_PARAMETER_VALUE and add the StartTime IE in the FailedParameter. If the CS receives a ModifyFlowRequest message with an EndTime earlier than the current time, the CS shall send the ModifyFlowResponse message with the ReasonCode IE set to INVALID_PARAMETER_VALUE and add the EndTime IEI in the FailedParameter. If the CS receives a ModifyFlowRequest message with a StartTime that cannot be supported due to resource limitations, the CS shall send the ModifyFlowResponse message with the ReasonCode IE set to RESOURCES_NOT_AVAILABLE and add the StartTime IEI in the FailedParameter. If the CS receives a ModifyFlowRequest message with an EndTime that cannot be supported due to resource limitations the CS shall send the ModifyFlowResponse message with the ReasonCode IE set to RESOURCES_NOT_AVAILABLE and add the EndTime IEI in the FailedParameter.... BCMCS Controller Functional Requirements The BCMCS Controller may send the ModifyFlowRequest message to the CS to change the start time and/or end time of the flow(s) that have not started. The BCMCS Controller may send the ModifyFlowRequest message to the CS to change the end time of the flow(s) that have started. The value of T resp is set to implementation specific. 0

63 GPP X.S00-A v The BCMCS Controller shall not send the ModifyFlowRequest message to change the start time of the flow(s) that have started. The StartTime for the flows that have not started shall be set value grater than the current time. The StartTime for the flows that have already started shall be set equal to the actual start time for the flows. The EndTime shall be set grater than the current time. If both StartTime and EndTime parameters are included in the ModifyFlowRequest message, the BCMCS Controller shall set the StartTime earlier than EndTime. In a ModifyFlowRequest message, the BCMCS Controller shall include at least one of the StartTime or EndTime.... Remove BCMCS Flow The RemoveFlowRequest message is sent by the BCMCS Controller to the CS to remove provisioned BCMCS Flow(s). The Active BCMCS Flows that are either Idle or Busy can be removed. The CS sends the RemoveFlowResponse message to indicate the result of the RemoveFlowRequest message.... CS Functional Requirements If the CS accepts the RemoveFlowRequest message, the CS shall send the RemoveFlowResponse with the ReasonCode IE set to SUCCESS to the BCMCS Controller. The CS shall make the specified BCMCS Flow Handle inactive and release all state and resources associated with that flow before sending the RemoveFlowResponse message. If the CS receives a RemoveFlowRequest message including an unknown BCMCS Flow Handle, the CS shall return a RemoveFlowResponse message with the ResultCode set to INVALID_PARAMETER_VALUE for the corresponding BCMCS Flow Handle, and include the BCMCSFlowHandle IEI in the FailedParameter element.... BCMCS Controller Functional Requirements The BCMCS Controller may send the RemoveFlowRequest message to the CS to remove one or more BCMCS flows.... State Synchronization State Synchronization is achieved through the ResetRequest and ResetResponse messages. The CS or BCMCS Controller may send a ResetRequest message to synchronize the state with its peer. The ResetRequest message shall contain zero or more BCMCS Flow Handles that indicate that the sender (X) has state information for zero or more BCMCS Flow reservations. Upon receipt of the ResetRequest message, the receiver (Y) shall compare the received list of flow handles with its own list and remove state for any flow handles that are not included within the received message. Y shall acknowledge the receipt of the ResetRequest with the ResetResponse message including its own remaining list of active Flow Handles. Upon receipt of the ResetResponse, X shall compare the received list of flow handles with its own list and removes state for any flow handles

64 GPP X.S00-A v that are not included within the received message. At the end of the transaction for the ResetRequest/ResetResponse, X and Y have state for the same BCMCS Flow Handles (which is the common subset of original BCMCS Flow Handles present in X and Y). The events that trigger the re-synchronization process at both entities (BCMCS Controller, CS) are part of the local policy of BCMCS Controller and CS and not in the scope of the document.... Refresh Keys The RefreshKeyRequest message is sent by the CS to the BCMCS Controller to request the Broadcast Access Key(s) (BAK) for one or more provisioned BCMCS Flows before the expiration time of the BAK(s). The RefreshKeyResponse message is sent by the BCMCS Controller to the CS to provide the new BAK(s) for a provisioned BCMCS Flow(s). The BCMCS Controller sends the new BAK(s) to be used for any given flow. The BCMCS Controller can accept or deny the request through the RefreshKeyResponse message.... CS Functional Requirements If the CS requires the new BAK(s) for one or more provisioned BCMCS Flows before the expiry time of the BAK is met, the CS shall send a RefreshKeyRequest message to the BCMCS Controller.... BCMCS Controller Functional Requirements If the BCMCS Controller receives a RefreshKeyRequest message including an {Active, Idle} or {Active, Busy} BCMCS Flow Handle, the BCMCS Controller shall return the RefreshKeyResponse message to provide the associated BAKs for requested Flow Handles, if the request is successful. The BCMCS Controller shall set the ResultCode corresponding to that Flow Handle to SUCCESS. The BCMCS Controller may autonomously send a RefreshKeyResponse message to the CS before the BAK expiry time for a flow. The BCMCS Controller may send two BAKs current BAK to be used and a subsequent BAK to be used for any given flow. If the BAKParameter IE is included in the RefreshKeyResponse, the BCMCS Controller should use TLS-PSK [] as a secure channel between the BCMCS Controller and CS.... FlowInformation The FlowInformation message is sent from the CS to the BCMCS Controller to provide BCMCS flow information that is associated with the same program. The FlowInformationResponse message is sent from the BCMCS Controller to the CS to acknowledge the reception of FlowInformation message.

65 GPP X.S00-A v CS Functional Requirements The CS may send the FlowInformation to the BCMCS Controller to provide flow information corresponding to one or more BCMCS Flows associated with one program. The feasible QoSParameters values depend on the characteristics of the content and the available radio resource of RAN. The CS may send a requested QoS parameter to the BCMCS controller in a FlowInformation message.... BCMCS Controller Functional Requirements The BCMCS Controller shall send the FlowInformationResponse in response to the FlowInformation message sent from the CS. If the FlowInformation contains valid configuration information of the flow(s), the BCMCS Controller shall send the FlowInformaitonResponse with ReasonCode set to SUCCESS. If the FlowInformation contains invalid configuration information of the flow(s), the BCMCS Controller shall send the FlowInformaitonResponse with an appropriate ReasonCode set... Message Format A CS-BCMCS control message consists of two parts: a Header and a Body. The header has a fixed length and a common format across messages and the body has variable length as shown in Figure -. 0 Octet Protocol Version = 0H Message Type = < 0H 0CH > (MSB ) Message Length = < 0 FF FFH > (LSB) (MSB ) Transaction ID = < 0 FF FFH > (LSB) (MSB ) Timestamp (LSB) Body 0 Figure - Common Header Format and Body Format Protocol Version: This parameter indicates the version of the CS-BCMCS Control Protocol the sender is using and it shall be set to 0H.

66 GPP X.S00-A v.0 0 Message Type: The Message Type parameter identifies the type of message. The possible values for the Message Type parameter are listed in Table -. Values 0H, 0DH FFH are reserved. Table - Message Type Values Value Message Name 0H AddFlowRequest 0H AddFlowResponse 0H ModifyFlowRequest 0H ModifyFlowResponse 0H RemoveFlowRequest 0H RemoveFlowResponse 0H ResetRequest 0H ResetResponse 0H RefreshKeyRequest 0AH RefreshKeyResponse 0BH FlowInformation 0CH FlowInformationResponse Message Length: -bit unsigned integer value that indicates the length of the message including the header fields and the body. Transaction ID: -bit unsigned integer value that uniquely identifies a CS-BCMCS Controller protocol transaction. This parameter is used by the sender to match a request with the corresponding response from the receiver. The sender increments this parameter by for every new transaction with the receiver and the parameter wraps around at (FFFFH). The receiver shall copy the Transaction ID from the request into the response message. Timestamp: -bit unsigned integer value in NTP format (specified in [0]), indicating the time the message was created. The parameter is used to protect against replay attacks in conjunction with the mandatory presence of the AuthenticationExtension information element, which provides message authentication and integrity protection. The body is of variable length and has Information Element specific to each message type. The Information Elements are in TLV (Type, Length, and Value) format and can be Mandatory, Conditional, or Optional, as described in Table -. Table - Definition of Mandatory, Conditional, Optional 0 Information Element Mandatory (M) Conditional (C) Optional (O) Description The Information Element is required for the message. The Information Element is required in situations where a condition is met (the condition is given in the Description in the message definition). The Information Element is provided at the discretion of the implementation.... AddFlowRequest The message format of the AddFlowRequest is described in Table -.

67 GPP X.S00-A v.0 0 Table - AddFlowRequest Information Element Format M/C/O One occurrence of the following elements: StartTime... M EndTime... M SDPParameters... M ContentTunnelProtocolOption... M LTunnelDestinationAddress...0 C a N occurrence (N=number of flows being added) of the following elements: MulticastFlowAddress... M BCMCSFlowHandle QoSParameters... O BAKParameter... O One occurrence of the following element: AuthenticationExtension... M a Included only if ContentTunnelProtocolOption = 00H (L Tunnel). The feasible QoSParameters values depend on the characteristics of the content and the available radio resource of RAN. The BCMCS Controller requests an operating point for these parameters and the CS accepts the parameters if it is feasible.... AddFlowResponse The message format of the AddFlowResponse is described in Table -. Table - AddFlowResponse Information Element Format M/C/O One occurrence of the following element: ContentTunnelProtocolOption... M LTunnelSourceAddress... C a DelayOffset... O N occurrence (N=number of flows added) of the following elements: ResultCode... M FailedParameter... C b One occurrence of the following element: AuthenticationExtension... M a Included if ResultCode = SUCCESS (00H) and ContentTunnelProtocolOption = 00H (L Tunnel). b Included if ResultCode is set to one of the following values: UNSUPPORTED_PARAMETER, POORLY_FORMED_PARAMETER, INVALID_PARAMETER_VALUE and MISSING_PARAMETER... ModifyFlowRequest The message format of the ModifyFlowRequest is described in Table -.

68 GPP X.S00-A v.0 Table - ModifyFlowRequest Information Element Format M/C/O One occurrence of the following element: StartTime... O a EndTime... O a N occurrences (N=number of flows being modified) of the following elements: BCMCSFlowHandle... M One occurrence of the following element: AuthenticationExtension... M a At least one of the StartTime or EndTime shall be included.... ModifyFlowResponse The message format of the ModifyFlowResponse is described in Table -. Table - ModifyFlowResponse Information Element Format M/C/O N occurrences (N=number of flows modified) of the following elements: ResultCode... M FailedParameter... C a One occurrence of the following element: AuthenticationExtension... M a Included if ResultCode is set to one of the following values: UNSUPPORTED_PARAMETER, POORLY_FORMED_PARAMETER, INVALID_PARAMETER_VALUE and MISSING_PARAMETER... RemoveFlowRequest The message format of the RemoveFlowRequest is described in Table -. 0 Table - RemoveFlowRequest Information Element Format M/C/O N occurrences (N=number of flows being removed) of the following elements: BCMCSFlowHandle... M One occurrence of the following element: AuthenticationExtension... M The BCMCS controller chooses BCMCSFlowHandle(s) associated with one BCMCS program.

69 GPP X.S00-A v RemoveFlowResponse The message format of the RemoveFlowResponse is described in Table -. Table - RemoveFlowResponse Information Element Format M/C/O N occurrences (N=number of flows removed) of the following elements: ResultCode... M FailedParameter... C a One occurrence of the following element: AuthenticationExtension... M a Included if ResultCode is set to one of the following values: UNSUPPORTED_PARAMETER, POORLY_FORMED_PARAMETER, INVALID_PARAMETER_VALUE and MISSING_PARAMETER... RefreshKeyRequest The message format of the RefreshKeyRequest is described in Table -0. Table -0 RefreshKeyRequest Information Element Format M/C/O N occurrences (N=number of flows for which BAK is requested) of the following elements: BCMCSFlowHandle... M One occurrence of the following element: AuthenticationExtension... M... RefreshKeyResponse The message format of the RefreshKeyRequest is described in Table - Table - RefreshKeyResponse Information Element Format M/C/O N occurrences (N=number of flows for which BAK is delivered) of the following elements: ResultCode... M BAKParameter... C a FailedParameter... C b One occurrence of the following element: AuthenticationExtension... M a Included only if ResultCode = SUCCESS (0H). b Included if ResultCode is set to one of the following values: UNSUPPORTED_PARAMETER, POORLY_FORMED_PARAMETER, INVALID_PARAMETER_VALUE and MISSING_PARAMETER

70 GPP X.S00-A v.0... FlowInformation The message format of the FlowInformation is described in Table -. Table - FlowInformation Information Element Format M/C/O One occurrence of the following element: ContentProviderID... M StartTime... M EndTime... M SDPParameters... M ContentTunnelProtocolOption... M LTunnelSourceAddress... C a N occurrences (N=number of flows being added) of the following elements: QoSParameters... O One occurrence of the following element: AuthenticationExtension... M a Included only if ContentTunnelProtocolOption = 0H (L Tunnel)....0 FlowInformationResponse The message format of the ResetRequest is described in Table -. Table - FlowInformationResponse Information Element Format M/C/O N occurrences of the following elements: ReasonCode... M One occurrence of the following element: AuthenticationExtension... M 0... ResetRequest The message format of the ResetRequest is described in Table ResetResponse Table - RestRequest Information Element Format M/C/O N occurrences of the following elements: BCMCSFlowHandle... M One occurrence of the following element: AuthenticationExtension... M The message format of the ResetResponse is described in Table -.

71 GPP X.S00-A v.0 0 Table - RestResponse Information Element Format M/C/O N occurrences of the following elements: BCMCSFlowHandle... M One occurrence of the following element: AuthenticationExtension... M.. Information Elements This section contains the coding and definition of the Information Elements (IEs) used in the messages defined in section... The following table contains a list of all the information elements used on the CS-BCMCS control protocol. The table is sorted by the Information Element Identifier (IEI) coding which distinguishes one information element from another. The table also includes a reference to the section where the element coding can be found. Table - Information Element Identifiers Element Name Identifier (IEI) Section Reference ResultCode 0H... MulticastFlowAddress 0H... StartTime 0H... EndTime 0H... ContentProviderID 0H... ContentTunnelProtocolOption 0H... LTunnelSourceAddress 0H... BCMCSFlowHandle 0H... LTunnelDestinationAddress 0H...0 DelayOffset 0AH... FailedParameter 0BH... AuthenticationExtension 0CH... BAKParameters 0DH... SDPParameters 0EH... QoSParameters 0FH... All other values are reserved. The rest of this section presents the definition of the CS-BCMCS Control Protocol information elements.... AuthenticationExtension The Authentication Extension shall be included in all CS-BCMCS Control Protocol messages. This Authentication Extension information element marks the end of the authenticated data in the CS-BCMCS Control Protocol messages. The structure of the extension is as shown in Figure -.

72 GPP X.S00-A v Octet Information Element Identifier (Type) = 0CH Length (MSB ) SPI (MSB )... BAKParameter (LSB) Authenticator Figure - AuthenticationExtension IEI: Information Element Identifier. It shall be set to 0CH. (LSB) Varia ble Length: This field indicates the number of octets in this element including IEI and Length fields. This field is set to plus the number of bytes in the authenticator. SPI: This four octet field is set to the Security Parameter Index as specified in []. Authenticator: For message authentication, the Authenticator field is calculated over TCP payload data except for Authenticator field, as specified in section.. of []. The BCMCS Controller sends the BAK_ID, BAK, and BAK_Expire field to the CS (in the given order). The structure of the BAKparameter is as shown in Figure -. 0 Octet Information Element Identifier (Type) = 0DH Length (MSB ) Identifier Type (MSB ) Identifier Varia ble N Reserved BAK_ID N+ BAK BAK_Expire Figure - BAKParameter N+ N+ N+ N+ 0

73 GPP X.S00-A v.0 0 IEI: Information Element Identifier. It shall be set to 0DH. Length: This field indicates the number of octets in this element including IEI and Length fields. Identifier Type: This field shall be set to 00H if the Identifier field contains the BCMCSFlowHandler value. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. Other values are reserved. The sender shall set this field to 00H if the BCMCSFlowHandler is available. Identifier: This field shall be set to the BCMCSFlowHandler value ( octets) if the Identifier type field is set to 00H. This filed shall be set to IPv Multicast Address and Port number as defined in Figure - if the Identifier field is set to 0H. This filed shall be set to IPv Multicast Address and Port number as defined in figure - if the Identifier field is set to 0H. 0 0 Octet (MSB ) Port Number = < C0 00H - C0 0H> (MSB ) (LSB) IP Address (IPv or IPv) Figure - Field format for Port number and IP address Reserved: Reserved bits. This field shall be set to all 0s. (LSB) BAK_ID: BAK identifier. A sequence number that identifies which value of BAK is currently valid for a particular BCMCS Multicast IP Flow; that is, the BAK is identified by the combination of a BCMCS_FLOW_ID and BAK_ID. For a particular BAK, the corresponding value of BAK_ID is the same for all users. BAK: -bit Broadcast Access Key: Provides access to one or more multicast IP flows of a particular set of BCMCS programs for a certain amount of time (for example, one day, week or month). Each encrypted set of BCMCS programs has a different BAK value. BAK_Expire: Indicates when the BAK will expire. This field shall be encoded using an unsigned integer and contain the number of seconds since January, 0 00:00 UTC. or... BCMCSFlowHandle The BCMCS Flow Handle references a unique BCMCS Flow reservation. The structure of the BCMCSFlowHandle is as shown in Figure -.

74 GPP X.S00-A v.0 0 Octet Information Element Identifier (Type) = 0H Length = 0H (MSB ) Value = < 0 - FF FF FF FFH >... ContentProviderID Figure - BCMCSFlowHandle IEI: Information Element Identifier. It shall be set to 0H. (LSB) Length: This field indicates the number of octets in this element including IEI and Length fields. This field shall be set to 0H. Value: -bit unsigned integer value indicating the BCMCS Flow Handle. This information element specifies the identification (name) of the Content Provider that is the source of the content for the BCMCS Flow. The structure of the ContentProviderID is as shown in Figure Octet Information Element Identifier (Type) = 0H Length Character Set = <00H-0H> (MSB ) ContentProviderID Figure - ContentProviderAddress IEI: Information Element Identifier. It shall be set to 0H. (LSB) Length: This field indicates the number of octets in this element including IEI and Length fields. Character Set: This field indicates the character set encoding type used for the following Content Provider ID field. Value 00H 0H 0H Otheres Table - Character Set Values ASCII- UTF- Unicode Reserved Character Set N

75 GPP X.S00-A v.0 ContentProviderID: Contains the identification (name) of the Content Provider that is the source of the content.... ContentTunnelProtocolOption The ContentTunnelProtocolOption indicates what bearer protocol is used between CS and BSN to transport content for the BCMCS Flow being added. The structure of the ContentTunnelProtocolOption is as shown in Figure Octet Information Element Identifier (Type) = 0H Length = 0H Value = < 0 0H > Figure - ContentTunnelProtocolOption IEI: Information Element Identifier. It shall be set to 0H. Length: This field indicates the number of octets in this element including IEI and Length fields. This field shall be set to 0H. Value: This -bit enumerated value identifies the type of bearer transport protocol used between the CS and BSN. The supported ContentTunnelProtocolOption values are listed below: Table - ContentTunnelProtocolOption Values Value Content Transport Protocol 00H L Tunnel 0H IP Multicast Otheres Reserved... DelayOffset This information element indicates that the CS shall start transmission of content for the BCMCS Flow at (StartTime DelayOffset). This is to compensate for processing and transmission delays on the CS-BSN link. The structure of the DelayOffset is as shown in Figure Octet Information Element Identifier (Type) = 0AH Length = 0H (MSB ) Value = < 0 - FF FFH > Figure - DelayOffset IEI: Information Element Identifier. It shall be set to 0AH. (LSB) Length: This field indicates the number of octets in this element including IEI and Length fields. This field shall be set to 0H.

76 GPP X.S00-A v.0 Value: -bit unsigned integer value indicating time in milliseconds.... EndTime This information element indicates the end time of a BCMCS Flow. The structure of the EndTime is as shown in Figure Octet Information Element Identifier (Type) = 0H Length = 0AH (MSB ) Value = < 0 - FF FF FF FF FF FF FF FFH >... FailedParameter Figure -0 EndTime IEI: Information Element Identifier. It shall be set to 0H. (LSB) 0 Length: This field indicates the number of octets in this element including IEI and Length fields. This field shall be set to 0AH. Value: -bit unsigned integer value in NTP format, as specified in [0]. This information element is included in response messages that have the ResultCode set to one of the following values: UNSUPPORTED_PARAMETER, POORLY_FORMED_PARAMETER, INVALID_PARAMETER_VALUE, and MISSING_PARAMETER. The structure of the FailedParameter is as shown in Figure -. 0 Octet Information Element Identifier (Type) = 0EH Length = <variable> Number of Failed IEIs Number of Failed IEIs occurrences of the following field: Identifier Type Identifier Varia ble N Failed Information Element Identifier N+ Figure - FailedParameter IEI: Information Element Identifier. It shall be set to 0BH. Length: This field shall be set the number of Failed Information Element Identifiers in this element plus.

77 GPP X.S00-A v.0 0 Identifier Type: This field shall be set to 00H if the Identifier field contains the BCMCSFlowHandler value. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. The sender shall set this field to 00H if the BCMCSFlowHandler is available. Identifier: This field shall be set to the BCMCSFlowHandler value ( octets) associated with the FailedParameters if the Identifier Type field is set to 00H. This filed shall be set to IPv Multicast Address and Port number as defined in figure - if the Identifier field is set to 0H. This filed shall be set to IPv Multicast Address and Port number as defined in Figure - if the Identifier field is set to 0H. Failed Information Element Identifier: Identifier. This field contains a Failed Information Element... QoSParameters This information element indicates the QoS of a BCMCS Flow. The structure of the QoSParameters is as shown in Figure Octet Information Element Identifier (Type) = 0FH Length = <variable> Identifier Type Identifier Variabl e N Number of Flow Profile IDs N+ (MSB) Flow Profile ID N+ Flow Profile ID N+ Figure - QoSParameters IEI: Information Element Identifier. It shall be set to 0FH. Length: This field indicates the number of octets in this element including IEI and Length fields. Identifier Type: This field shall be set to 00H if the Identifier field contains the BCMCSFlowHandler value. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. The sender shall set this field to 00H if the BCMCSFlowHandler is available. Identifier: This field shall be set to the BCMCSFlowHandler value ( octets) associated with the Flow Profile ID if the Identifier type field is set to 00H. This filed shall be set to IPv Multicast Address and Port number as defined in figure - if the Identifier field is set to 0H. This filed shall be set to IPv Multicast Address and Port number as defined in Figure - if the Identifier field is set to 0H. Number of Flow Profile IDs: This field indicates the number of Flow Profile IDs contained in this IE. This field shall be set to for the CS-BCMCS Control Protocol revision.

78 GPP X.S00-A v.0 Flow Profile ID: One Flow Profile ID is bits length. This field shall be set according to the QoS requirements for a flow. Flow Profile ID is specified in []....0 LTunnelDestinationAddress This information element specifies the IP address of the BSN entity that is the destination endpoint of the L tunnel for a BCMCS Flow. The structure of the LTunnelDestinationAddress is as shown in Figure Octet Information Element Identifier (Type) = 0H Length = < 0H, H > IPVersion = < 0H, 0H > (MSB ) IPAddress Figure - LTunnelDestinationAddress IEI: Information Element Identifier. It shall be set to 0H. (LSB) Length: This field indicates the number of octets in this element including IEI and Length fields. It shall be set to 0H if the IP Version field is set to 0H, or H if the IP Version field is set to 0H. IP Version: This parameter indicates the version of the IP protocol used as a Delivery Protocol for L Tunneling. The supported IP Version values are listed below: Value 0H 0H Others Table - IP Version Values IP Version IPv IPv Reserved IP Address: -bit IPv, or -bit IPv address, depending on the value of the IP Version field.... LTunnelSourceAddress This information element specifies the IP address of the CS entity that is the source endpoint of the L tunnel for a BCMCS Flow. The structure of the LTunnelSourceAddress is as shown in Figure -. or

79 GPP X.S00-A v Octet Information Element Identifier (Type) = 0H Length = < 0H, H > IP Version = < 0H, 0H > (MSB ) IP Address Figure - LTunnelSourceAddress IEI: Information Element Identifier. It shall be set to 0H. (LSB) Length: This field indicates the number of octets in this element including IEI and Length fields. It shall be set to 0H if the IP Version field is set to 0H, or H if the IP Version field is set to 0H. IP Version: This parameter indicates the version of the IP protocol used as a Delivery Protocol for L Tunneling. The supported IP Version values are listed in Table -. IP Address: -bit IPv, or -bit IPv address, depending on the value of the IP Version field.... MulticastFlowAddress_BCMCSFlowHandle This information element specifies the IP multicast address, port and BCMCSFlowHandle on which the BCMCS Flow is sent. The structure of the MulticastFlowAddress_BCMCSFlowHandle is as shown in Figure -. or

80 GPP X.S00-A v Octet Information Element Identifier (Type) = 0H Length = < 0DH, H > (MSB ) Port Number = < C0 00H - C0 0H> (MSB ) (MSB )... ResultCode (LSB) IP Version = < 0H, 0H > BCMCSFlowHandle IP Address Figure - MulticastFlowAddress_BCMCSFlowHandle IEI: Information Element Identifier. It shall be set to 0H. (LSB) or or 0 or or or or Length: This field indicates the number of octets in this element including IEI and Length fields. It shall be set to 0DH if the IP Version field is set to 0H, or H if the IP Version field is set to 0H. Port Number: -bit port number. The range of permissible values is from (C000H) to (C00H). IP Version: This parameter indicates the version of the IP protocol used as a Delivery Protocol for L Tunneling. The supported IP Version values are listed in Table -. IP Address: -bit IPv, or -bit IPv address, depending on the value of the IP Version field. BCMCSFlowHandle: -bit unsigned integer value indicating the BCMCS Flow Handle. This information element is used to indicate the reason for occurrence of a particular event. The structure of the ResultCode is as shown in Figure -.

81 GPP X.S00-A v Octet Information Element Identifier (Type) = 0H Length Identifier Type Identifier Varia ble N Value = < 0 - FFH > N+ Figure - ResultCode IEI: Information Element Identifier. It shall be set to 0H. Length: This field indicates the number of octets in this element including IEI and Length fields. Identifier Type: This field shall be set to 00H if the Identifier field contains the BCMCSFlowHandler value. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. This filed shall be set to 0H if the Identifier field contains IPv Multicast Address and Port number. The sender shall set this field to 00H if the BCMCSFlowHandler is available. Identifier: This field shall be set to the BCMCSFlowHandler value ( octets) associated with the ReasonCode if the Identifier type field is set to 00H. This filed shall be set to IPv Multicast Address and Port number as defined in figure - if the Identifier field is set to 0H. This filed shall be set to IPv Multicast Address and Port number as defined in Figure - if the Identifier field is set to 0H. Value: -bit unsigned integer value indicating the processing result of a message request. Table -0 ResultCode Values Value Mnemonic Description

82 GPP X.S00-A v.0 00H SUCCESS The Request was successfully completed 0H RESOURCES_NOT_AVAILABLE Resources are not available at the time of the request. 0H 0H 0H 0H 0H 0H 0H 0H 0AH UNSUPPORTED_VERSION UNSUPPORTED_REQUEST POORLY_FORMED_REQUEST TIMESTAMP_MISMATCH AUTHENTICATION_FAILURE UNSUPPORTED_PARAMETER INVALID_PARAMETER_VALUE MISSING_PARAMETER UNABLE_TO_COMPLY This error is returned when a request was received, whose version number is unsupported. This error is returned when a request contained a Message Type that the receiver did not recognize or support. This error is returned when the received message is poorly formed. The message length is not valid. This error is sent when the received timestamp value is more than REPLAY_OFFSET seconds away from the receiver s local time. In this scenario, the receiver copies only the low-order bits of the timestamp into the response, and supplies the high-order bits from its own time of day. This error is sent when message authentication failed at the receiver. The peer received a message that contained a parameter that is not recognized or supported. A message with this error shall contain a FailedParameter element containing the IEI(s) of the one or more IEIs that caused the failure. The request contained an IE with an invalid value in its data portion. A message indicating this error shall include the offending IEs within a FailedParameter element. The request did not contain a parameter that is required by the message definition. A FailedParameter should be included in the response containing the missing IEIs. This error is returned when a request is rejected for unspecified reasons. 0BH INVALID_MULTICAST_ADDR_VALUE The AddFlowRequest message contained a value of the multicast IP address that is already assigned to another flow by the BCMCS Controller. 0CH INVALID_STATE The message is received in invalid state. All other values are reserved.... SDPParameters This information element indicates the SDP for one or more BCMCS Flows associated with one program. The structure of the SDPParameters is as shown in Figure -. 0

83 GPP X.S00-A v.0 0 Octet Information Element Identifier (Type) = 0EH Length (MSB ) SDP... StartTime Figure - SDPParameters IEI: Information Element Identifier. It shall be set to 0EH. (LSB) Varia ble Length: This field indicates the number of octets in this element including IEI and Length fields. SDP: This field shall contain the application information using the format specified in []. This information element indicates the start time of a BCMCS Flow. The structure of the StartTime is as shown in Figure Octet Information Element Identifier (Type) = 0H Length = 0AH (MSB ) Value = < 0 - FF FF FF FF FF FF FF FFH > Figure - StartTime IEI: Information Element Identifier. It shall be set to 0H. (LSB) 0 Length: This field indicates the number of octets in this element including IEI and Length fields. It shall be set to 0AH. Value: -bit unsigned integer value in NTP format, as specified in [0].

84 GPP X.S00-A v.0 0 BCMCS Bearer Path Setup For static broadcast services, the BCMCS bearer paths may be set up or released via static provisioning at any time. How to set up or release a bearer path in this case is beyond the scope of this document. For dynamic broadcast services, bearer path setup may be triggered based on the first MS's registration or when the RAN determines that the transmission of a BCMCS flow is required. The network may tear down the bearer path when a program associated with the bearer is ended or the RAN determines that there are no more MS s listening to the program. If the network decides to release the bearer path, it may perform the following based on local policy: Release the bearer paths over the air (radio channels) only, Release the bearer paths over the air (radio channels) and RAN bearer paths (A and A0 connections), Release the bearer paths over the air (radio channels), RAN bearer paths (A and A0 connections), and core network bearer paths (between BSNs and MRs or between the BSN and the BCMCS Contents Server). It is assumed that the bearer path(s) between the MR and the BCMCS Content Server is (are) always established. How to establish bearer paths between them is beyond the scope of this document. 0. Bearer Path Setup between MS and BSN Bearer Path(s) between MS and BSN are established and maintained as defined in [], [] and []. The bearer path establishment may involve authorization procedures, session discovery procedures, or both. 0. Join Multicast Group from BSN If the BSN supports the multicast routing, the BSN shall support IGMPv [] or IGMPv [0]. The BSN may support MLD [] or MLDv []. For Dynamic Broadcast, the reception of a RADIUS Access-Accept message as a result of the first MS's registration via RAN, with the BSN that is associated with Program ID [], may trigger the BSN to join the corresponding multicast group(s) via IGMP for IPv multicast flows or via MLD for IPv multicast flows. If the BSN is not IPv capable, it shall discard the BCMCS_FLOW_IDs that are associated with IPv multicast flows. In order to know whether requested multicast IP Flows are available or not, the BSN needs to know the BCMCS Session Information. Before performing the IGMP or MLD procedure, the BSN shall know the BCMCS Session Information. If it is unknown, the BSN shall wait for performing the procedures in this section until the BSN Session Discovery Procedure described in section 0 has completed.

85 GPP X.S00-A v IGMP Support If the BSN is configured to use IGMP and the IP Multicast flows requested are not available, the BSN shall perform the following: If registration authorization is not required, or if registration authorization is required and is successful (see section..) the BSN shall send the Version Membership Report message or Version Membership Report message to the MR when it receives the BC Registration Request from the RAN. If the BSN doesn t have the BCMCS session information, it shall fetch the information from the BCMCS Controller before sending the Version Membership Report message or Version Membership Report message. The BSN may send the Version Membership Report message or Version Membership Report message to the MR based on local policy at anytime after it acquires necessary BCMCS session information. If the BSN is configured to use IGMP, the BSN shall support either IGMPv or IGMPv. If the BSN sends the Version Membership Report message or Version Membership Report message to the MR, the BSN shall follow the guidelines in [] or [0] for other multicast management procedures. If the BSN supports IGMPv, it shall use the Version Membership Report message to join the multicast group. If the BSN supports IGMPv, and it receives the source IP addresses, i.e., content server IP address, in the BSN session information, it shall use the Version Membership Report message to join the multicast group with setting the received addresses as the source IP address of the Membership Report message and setting the Record Type to (MODE IS INCLUDE) in the Group Record. If BSN doesn t receive the IPv source IP address in the BSN session information, it may use either the Version or Version Membership Report message. When all of the A0 connections for a certain Multicast IP address are disconnected, the BSN shall send the Leave Group message to the MR. The MR shall send the Membership Query message to the BSN at an operator-configured interval and shall follow the guideline in [] or [0]... MLD Support If the BSN supports MLD and the IPv Multicast Flows requested are not available, the BSN shall perform the following: If registration authorization is not required, or if registration authorization is required and is successful, the BSN shall send the Version Multicast Listener Report message or Version Multicast Listener Report message to the MR when it receives the BC Registration Request from the RAN. If the BSN doesn t have the BCMCS session information, it shall fetch the information from the BCMCS Controller before sending the Version Multicast Listener Report message or Version Multicast Listener Report message. The BSN may send the Version Multicast Listener Report message or Version Multicast Listener Report message to the MR based on local policy at anytime after it acquires necessary BCMCS session information.

86 GPP X.S00-A v.0 0 If the BSN supports MLD, the BSN shall support either MLDv or MLDv. If the BSN sends the Version Multicast Listener Report message or Version Multicast Listener Report message to the MR, the BSN shall follow the guidelines in [] or [] for other multicast management procedures. If the BSN supports MLDv, it shall use the Multicast Listener Report message to join the multicast group. If the BSN supports MLDv, and it receives source IPv addresses, i.e., content server IPv address, in the BSN session information, it shall use the Version Multicast Listener Report message to join the multicast group with setting the received addresses as the source IPv address of the Multicast Listener Report message and setting the record type to (MODE IS INCLUDE) in Multicast Address Record. If BSN doesn t receive IPv source IP address in the BSN session information, it may use either Version or Version Multicast Listener Report message. When all of the A0 connections for a certain Multicast IPv address are disconnected, the BSN shall send the Multicast Listener Done message to the MR. The MR shall send the Multicast Listener Query message to the BSN at an operator-configured interval and shall follow the guideline in [] or [].. BSN-Content Server Unicast Tunnel Contents may be received by the BSN via a unicast tunnel from the content server. How to set up or release a unicast tunnel is beyond the scope of this document.

87 GPP X.S00-A v BSN Session Management To deliver the BCMCS flows to the MS via the RAN, both the RAN and the BSN require BCMCS session related information from the BCMCS Controller. The BCMCS session information includes the following: BCMCS_FLOW_ID or Program ID and (Multicast IP address, Destination Port number), Header Compression information: Algorithm (ROHC, or no header compression etc.) and configuration information, Encryption Mechanism (e.g., link layer encryption vs. higher layer encryption), BAK_ID, BAK, and BAK Expiry time (if link layer encryption is used and/or the BCMCS Controller allows the registration authorization performed in the RAN), Authorization Required Flag, Program Schedule (Start time, end time, allowed registration time), Bandwidth (data rate) of the BCMCS session, QoS Parameters. If BAK is passed to the BSN, the BAK should be delivered securely from the SAAA/BCMCS Controller to the BSN Session Discovery Triggered by the BSN Upon receiving an A-BC Service Request message from the RAN for the BCMCS IP Flow or Program ID, the BSN may request BCMCS session information from the SAAA/BCMCS Controller via the RADIUS protocol. The SAAA/BCMCS Controller responds with the BCMCS session information corresponding to the flow identified by the BCMCS_FLOW_ID or to the program identified by the Program ID. 0.. BSN Requirement The BSN shall act as a RADIUS client in accordance with []. The BSN shall send a RADIUS Access- Request message to the SAAA/BCMCS Controller in accordance with Table 0- when triggered to do so. There are two triggers: When an A BC Service Request message is received from the RAN containing either a BCMCS_FLOW_ID or a Program ID for which the BSN has no information. An A BC Service Request message is received containing authorization parameters (see section..). Table 0- Occurrence of RADIUS Attributes for Session Discovery Attribute Name Type Access-Request Access-Accept Interface(s) User-Name M Note M BSN <-> SAAA/Controller User-Password M Note BSN -> SAAA/Controller NAS-IP-Address O Note BSN -> SAAA/Controller NAS-IPv-Address O Note BSN -> SAAA/Controller Correlation ID / M O BSN <-> SAAA/Controller Authorization Parameters / O BSN -> SAAA/Controller BCMCS Capability /0 O O BSN <-> SAAA/Controller

88 GPP X.S00-A v Common Session Info /0 O SAAA/Controller->BSN BSN Session Info /0 O SAAA/Controller->BSN RAN Session Info /0 O SAAA/Controller->BSN Reason Code /0 M BSN -> SAAA/Controller BCMCS_FLOW_ID /00 O Note BSN -> SAAA/Controller Program ID / O Note BSN -> SAAA/Controller Content Provider ID / O SAAA/Controller->BSN (M) Indicates Mandatory Attribute (O) Indicates Optional Attribute Note : User name and User-Password are manually configured as static BCMCS group name and BCMCS group password, respectively. Note : At least one of NAS-IP-Address or NAS-IPv-Address shall be included. Note : Either BCMCS_FLOW_ID or Program ID shall be included. BCMCS_FLOW_ID shall be included if an A-BC Service Request message (see []) contains BCMCS_FLOW_ID. Program ID shall be included if an A-BC Service Request message contains Program ID. 0.. SAAA/BCMCS Controller Requirement The SAAA/BCMCS Controller shall support the attributes as specified in Table 0-. Upon receiving a RADIUS Access-Request message, the SAAA/BCMCS Controller performs the BCMCS registration authorization if necessary (see section..). If the Reason Code VSA is set to (Authorization and Session Discovery), the SAAA/BCMCS Controller shall include the BCMCS session information in a RADIUS Access-Accept message and send it to the BSN upon successful authorization. If the Reason Code is set to (Session Discover Only), the SAAA/BCMCS Controller shall send to the BSN a RADIUS Access-Accept message that includes the BCMCS session related information. If the BCMCS_FLOW_ID or Program ID is not available in the BCMCS Controller, it shall send a RADIUS Access-Reject message to the BSN. When the BCMCS Controller returns Common, BSN, and RAN session information, it shall include the session information for all flows of the programs in each of three types information Session Information Triggered by the BCMCS Controller For the BCMCS Controller initiated bearer path setup, the BCMCS Controller pushes the BCMCS session information to the SAAA/BSN via the RADIUS extension protocol. The SAAA/BSN responds with an acknowledgement on receipt of the BCMCS session information. 0.. SAAA/BCMCS Controller Requirement The BCMCS Controller shall support RADIUS protocol in accordance with [] and []. The BCMCS Controller shall send a RADIUS CoA- Request message to the BSN directly or through the SAAA in accordance with Table 0- when triggered to do so. The trigger may be a configurable period of time before the start time of pre-configured network initiated flow (with the receiving area for the flow). How a network initiated flow is provisioned at the BCMCS Controller is beyond the scope of this document. Table 0- Occurrence of RADIUS Attributes for Session Information Attribute Name Type CoA-Request CoA-ACK Interface(s) User-Name O Note SAAA/Controller -> BSN User-Password O Note SAAA/Controller -> BSN

89 GPP X.S00-A v NAS-IP-Address O Note SAAA/Controller -> BSN Message-Authenticator 0 O O SAAA/Controller <-> BSN NAS-IPv-Address O Note SAAA/Controller -> BSN BCMCS Capability /0 O SAAA/Controller -> BSN Common Session Info /0 M SAAA/Controller ->BSN BSN Session Info /0 M SAAA/Controller ->BSN RAN Session Info /0 M SAAA/Controller ->BSN BSID /0 O SAAA/Controller -> BSN Subnet /0 O SAAA/Controller -> BSN Content Provider ID / O SAAA/Controller->BSN (M) Indicates Mandatory Attribute (O) Indicates Optional Attribute Note : User name and User-Password are manually configured as static BCMCS group name and BCMCS group password, respectively. Note : At least one of NAS-IP-Address or NAS-IPv-Address shall be included. 0.. BSN Requirement The BSN shall support the attributes as specified in Table 0-. Upon successfully receiving a RADIUS CoA-Request message, the BSN shall respond with a RADIUS CoA-ACK message to the SAAA/BCMCS Controller. The BSN then sends an A-BC-Service Initiate Request message to the RAN[], in order to set up the network initiated bearer path. If any of the mandatory attributes listed in Table 0- are not available in the RADIUS CoA-Request message or the CoA-Request message does not contain valid configuration for BCMCS Session Information, the BSN shall reject the request and send a RADIUS CoA-NAK message to the SAAA/Controller. If any unsupported VSAs (that are not listed in Table 0-) are present in the RADIUS CoA-Request, the BSN shall ignore the unsupported VSAs and shall send RADIUS CoA-ACK message to the SAAA/Controller to acknowledge on the supported VSAs. If both BSID and Subnet attributes are not included in CoA-Request message, the BSN sends A-BC-Service Initiate Request message to the RANs based on local configuration Session Termination Triggered by the BCMCS Controller For the BCMCS Controller initiated session termination, the BCMCS Controller sends the BCMCS FLOW ID to the SAAA/BSN via the RADIUS extension protocol. The BSN responds with an acknowledgement on receipt of the BCMCS FLOW ID to be terminated. 0.. SAAA/BCMCS Controller Requirements The BCMCS Controller shall support RADIUS protocol in accordance with [] and []. The BCMCS Controller shall send a RADIUS Disconnect - Request message to the BSN directly or through the SAAA in accordance with Table 0- when it removes the flow(s) at the CS via CS-BCMCS Control Protocol (see section ). Table 0- Occurrence of RADIUS Attributes for Session Information

90 GPP X.S00-A v Attribute Name Type Disconnect-Req uest Disconnect-AC K Interface(s) User-Name O Note SAAA/Controller -> BSN User-Password O Note SAAA/Controller -> BSN NAS-IP-Address O Note SAAA/Controller -> BSN Message-Authenticator 0 O O SAAA/Controller <-> BSN NAS-IPv-Address O Note SAAA/Controller -> BSN BCMCS Capability /0 O SAAA/Controller -> BSN BCMCS_FLOW_ID /00 M SAAA/Controller ->BSN (M) Indicates Mandatory Attribute (O) Indicates Optional Attribute Note : User name and User-Password are manually configured as static BCMCS group name and BCMCS group password, respectively. Note : At least one of NAS-IP-Address or NAS-IPv-Address shall be included. 0.. BSN Requirements The BSN shall support the attributes as specified in Table 0-. Upon successfully receiving a RADIUS Disconnect-Request message, the BSN shall respond with a RADIUS Disconnect-ACK message to the SAAA/BCMCS Controller. If A0(s) for the corresponding BCMCS flow(s) has been established, the BSN then sends an A-BC-Registration Update message to the RAN [], in order to terminate the BCMCS flow(s). Upon receiving A-BC-Regsitration Request from the RAN, the BSN sends A-BC Registration Reply to the RAN[], the BSN shall then remove the BCMCS Session Information for the flow(s). If A0(s) for the corresponding BCMCS flow(s) has not been established, the BSN then sends an A-BC-Service Initiate Request message with Code set to 0H (Information unavailable) to the RAN [], in order to remove the BCMCS flow(s) session information. Upon receiving A-BC- Service Initiate Response message from the RAN, the BSN shall then remove the BCMCS Session Information for the flow(s). If any of the mandatory attributes listed in Table 0- are not available in the Disconnect-Request message, the BSN shall reject the request and send a RADIUS Disconnect-NAK message to the SAAA/Controller. If any unsupported VSAs (that are not listed in Table 0-) are present in the RADIUS Disconnect-Request, the BSN shall ignore the unsupported VSAs and shall send RADIUS Disconnect-ACK message to the SAAA/Controller to acknowledge on the supported VSAs.

91 GPP X.S00-A v.0 BCMCS Security 0 0. Authentication, Authorization and Integrity Check.. Information Acquisition The BCMCS Controller may perform authentication and integrity protection for BCMCS Information Acquisition (see section ). The main purpose of authentication for BCMCS Information Acquisition is to avoid sending the BCMCS session information to an invalid user, especially when the BAK with life time is used for charging the user. The main purpose of integrity protection for BCMCS Information Acquisition is to avoid man in the middle attacks from modifying the BCMCS session information. BCMCS Information Acquisition Request and Response messages should be integrity protected.... BCMCS Controller Requirement The BCMCS Controller shall perform authentication and integrity protection if the MS requests security information and the requested flow(s) are protected by BAK(s). The BCMCS Controller shall use HTTP digest and shall follow [] and [] for Information Acquisition authentication and integrity protection. Upon receiving the HTTP Post from the MS (see section ) without an authorization header, if the BCMCS Controller decides that authentication and integrity protection is required, and a valid nonce is not available in the BCMCS Controller, the BCMCS Controller shall send a RADIUS Access-Request message to the Home RADIUS Server according to [] with Digest-Qop set to auth-int to request a nonce. Upon receiving RADIUS Access Challeng containing Digest attributes, the BCMCS controller shall send HTTP 0 Unauthorized with a WWW-Authenticate Header to the MS including digest challenge. Upon receiving the HTTP Post from the MS with an authorization request header included, the BCMCS Controller shall send a RADIUS Access-Request message to the Home RADIUS Server in accordance with Table -. Table - Occurrence of RADIUS Attributes for Information Acquisition Attribute Name Type Access-Request Access-Accept Interface(s) User-Name M M Controller<-> HAAA NAS-IP-Address O Note Controller -> HAAA Class O HAAA -> Controller Message-Authenticat or 0 M M HAAA <-> Controller NAS-IPv-Address O Note Controller -> HAAA Digest-Response 0 M Controller -> HAAA Digest-Realm 0 M Controller -> HAAA Digest-Nonce 0 M Controller -> HAAA Digest-Nextnonce 0 O HAAA -> Controller

92 GPP X.S00-A v.0 Digest-Method 0 M Controller -> HAAA Digest-URI 0 M Controller -> HAAA Digest-QoP 0 M Controller -> HAAA Digest-Algorithm O Controller -> HAAA Digest-Entity-Body-H ash M Controller -> HAAA Digest-CNonce M Controller -> HAAA Digest-Nonce-Count M Controller -> HAAA Digest-Username M Controller -> HAAA Digest-Auth-Param O O Controller <-> HAAA Digest-HA M HAAA -> Controller Correlation ID / M Controller -> HAAA 0 0 TK Info / M HAAA -> Controller Acq Info TimeStamp / M Controller -> HAAA Program Name / O O HAAA <-> Controller (M) Indicates Mandatory Attribute (O) Indicates Optional Attribute Note : At least one of NAS-IP-Address or NAS-IPv-Address shall be included. Upon receiving a RADIUS Access-Accept message from the RADIUS Server including Digest-HA, and TK Info (TK and TK_RAND), the BCMCS Controller shall compute auth-info as specified in []. The BCMCS Controller shall send a 00 Ok with authentication-info header. The BCMCS Controller shall set message-qop to auth-int. The BCMCS Controller shall include a Message-Authenticator (0) attribute in the RADIUS Access-Request message. The RADIUS Access-Accept message, including the BCMCS attribute(s) without a Message-Authenticator (0) attribute shall be silently discarded by the BCMCS Controller. The BCMCS Controller supporting the BCMCS attributes shall calculate the correct value of a received Message-Authenticator (0) (as per []) and shall silently discard the packet if it does not match the value sent.... Home RADIUS Server Requirement Upon receiving a RADIUS Access Request message from the BCMCS Controller, the Home RADIUS Server shall follow [] and [] for authentication and may authorize the user by checking whether the user is subscribed to BCMCS. For authentication purpose, the RADIUS server shall compute Auth-Key as specified in [] and use it as passwd as specified in []. Upon successful authentication and authorization, the RADIUS Server shall compute TK as specified in [] and send TK and TK_RAND to the BCMCS Controller in accordance with Table -. The Home RADIUS Server may include Class attribute to the BCMCS Controller in the RADIUS Access-Accept message. The Home RADIUS server shall include a Message-Authenticator (0) attribute in the RADIUS Access-Accept message. The RADIUS Access-Request message including BCMCS attributes without a Message-Authenticator (0) attribute shall be silently discarded by the Home RADIUS server. A Home RADIUS server supporting the BCMCS attributes shall calculate the correct value of the Message-Authenticator (0) (as per []) and shall silently discard the packet if it does not match the value sent. 0

93 GPP X.S00-A v MS Requirement If the MS receives an HTTP 0 Unauthorized with a WWW-Authenticate Header from the BCMCS Controller in response to a BCMCS Information Acquisition Request message, the MS shall compute Auth-Key as specified in [] and perform HTTP digest procedures and resend HTTP Post with an authorization request header included, as specified in [] with passwd set to Auth-Key (see section... of []). Upon receiving 00 OK with authentication-info header from the BCMCS Controller, the MS shall check response digest (see []). Upon successful check, the MS shall process the HTTP body (see section ); otherwise, the MS shall ignore the message... Registration BSN Requirements Upon receiving the authorization parameters contained in an A-BC Service Request from the RAN for a BCMCS IP Flow or Program, the BSN shall include the Auth Signature, BAK_ID, and cdma system time in the Authorization Parameters VSA and send it to the SAAA/BCMCS Controller in a RADIUS Access-Request message with the BCMCS_FLOW_ID or Program ID VSA. The BSN may request BCMCS session information associated with the BCMCS_FLOW_ID or Program ID within the same RADIUS Access Request message (see section 0..) If the BSN receives a RADIUS Access-Accept message from the SAAA/BCMCS Controller, the BSN shall send an A-BC Service Response message to the RAN. If the BSN receives a RADIUS Access-Reject message from the SAAA/BCMCS Controller, the BSN shall indicate to the RAN that authorization for the user is unsuccessful or information is not available.... SAAA/BCMCS Controller Requirements Upon receiving the Authorization Parameters VSA in a RADIUS Access-Request message with Reason Code set to or, the SAAA/BCMCS Controller shall use the EHMAC-SHA procedure as specified in [], [] and [] to compute the Auth Signature. The SAAA/BCMCS Controller shall compare the computed Auth Signature with the Auth Signature received from the BSN for the corresponding BCMCS Flow or Program. If the result is matched, the SAAA/BCMCS Controller shall send a RADIUS Access-Accept message to the BSN to indicate the authorization for the corresponding flow or Program is successful. The SAAA/BCMCS Controller shall send BCMCS session related information within the same RADIUS Access-Accept message if Reason Code VSA is set to (see section 0..). If a mismatch is detected between the received Auth signature from the BSN and the computed version, the SAAA/BCMCS Controller shall send a RADIUS Access-Reject message to the BSN. If the SAAA/BCMCS Controller sends a RADIUS Access-Accept message to the BSN, the SAAA/BCMCS Controller may send the BAK_ID, the BAK expiry time, and the BAK to the RAN through the BSN for subsequent user authorization to be performed in the RAN (see []). If the SAAA/BCMCS controller receives the Auth Signature with the Program ID VSA, it assumes that the same BAK is applied to all flows associated with the Program ID.

94 GPP X.S00-A v.0 0. Key Management Registration Key (RK) is the basis of the key distribution and authentication for BCMCS. RK is specific to the user and provisioned in both UIM and the HAAA prior to the service. A Temporary encryption Key (TK) is derived from the RK and the TK_RAND by the HAAA, sent to the BCMCS Controller and subsequently used by the BCMCS Controller to encrypt the BAK when the BCMCS Controller distributes the BAK to the MS via BCMCS Information Acquisition. BAK provides access to one or more multicast IP flows of a particular set of BCMCS programs for a certain amount of time (for example, one day, week or month). Each encrypted set of BCMCS programs/flows or each BCMCS flow may have a different BAK value. The Short-term Key (SK) is used by the BCMCS Content Server (for higher layer encryption) or by the RAN (for link layer encryption) to encrypt the BCMCS flow and by the MS to decrypt the BCMCS flow. The SK is derived from SK_RAND and BAK. The details of the key management for RK, TK, BAK, and SK are specified in []. 0. Encryption The Content Encryption (CE) function as specified in [] encrypts BCMCS content. If link layer encryption is used, the CE function is located in the RAN. If higher-layer encryption is used, the CE function is located in the content server... Link Layer Encryption See []... Higher Layer Encryption If higher layer encryption is enabled, SRTP [] shall be applied and the Content Encryption (CE) function shall be in the content server. The SRTP Session Encryption Key shall be used as the SK to encrypt the BCMCS content. The SRTP Master Key, SRTP Master Salt, and Packet Index are used for deriving the SRTP Session Encryption Key and Session Authentication Key according to section of []. Figure - depicts the SRTP key derivation. The key derivation occurs in the UIM. The SRTP encryption transform shall be the AES in Counter Mode (see [], section..).

95 GPP X.S00-A v.0 Packet Index 0 SRTP Master Key SRTP Master Salt Key Derivation Function SRTP Session Encryption Key SRTP Session Authentication Key Figure - SRTP Key Derivation The BAK shall be used as the SRTP Master Key. The SK_RAND is bits [] and shall be extended to bits by left-padding with zeros to form the SRTP Master Salt. The Packet Index is determined according to ([], section..). The Key Derivation Rate shall be set to zero. The Key Derivation Function shall be the AES in Counter Mode as specified in ([], section..). The Master Key Identifier (MKI) shall be used for distributing the SK_RAND. The MKI shall be 0 bits and consist of -bit reserved field, -bit BAK_ID and -bit SK_RAND, as specified in Figure -. The reserved field is the most significant bits in the MKI and is set to The MS shall ignore the reserved field. The MKI is included in every encrypted RTP packet []. Reserved ( bits) BAK_ID ( bits) SK_RAND ( bits) 0 Figure - MKI Format An MKI, containing the same SK_RAND that was already in use, is transmitted in encrypted RTP packets within the same SK lifetime interval. On the receiving side, if the BAK_ID in the MKI is not the same as one of the BAK_IDs stored in the MS, the MS shall acquire a new BAK from the BCMCS Controller and derive a new SRTP Session Encryption Key to decrypt the BCMCS content. If SK_RAND in the MKI is not the same as the SK_RAND stored in the MS, the MS shall derive a new SRTP Session Encryption Key to decrypt the BCMCS content.... Authentication Tag If SRTP authentication is enabled, the CS shall use the new authentication tag field containing the ROC as defined in []. The CS shall compute the integrity checksum over the SRTP packet and the ROC as defined in [] and amended in [], i.e., the received ROC shall be used in the MAC computation. See Figure - for the format of the authentication tag.

96 GPP X.S00-A v.0 ROC ( bits) Auth_tag (0 bits, HMAC SHA-) 0 Figure - BCMCS SRTP Authentication Tag format The MS, upon reception of the SRTP packet, shall compute the authentication key and then the authentication tag over the SRTP packet and the ROC value, and compare the computed value to the received authentication tag. If the values are the same, the SRTP packet shall be decrypted and used, otherwise the packet shall be discarded. The received ROC value replaces the stored ROC value at the receiver. The CS shall support HMAC-SHA with an 0-bit output tag and a 0-bit key ([], section.) as the SRTP authentication algorithm. The CS may support SRTP weak authentication (-bits from the HMAC-SHA output) and NULL authentication. The MS shall support all three modes of SRTP authentication. The CS may include ROC in every Rth packet; the default value for R is (every packet).

97 GPP X.S00-A v Header Compression Both the BSN and the MS may support the ROHC U Mode header compression algorithm (see []). Instead of using IPCP or IPvCP[] to acquire the header compression configuration parameters, the BCMCS Information Acquisition procedures (see section ) between the BCMCS Controller and the MS are used to convey the header compression configuration parameters. After the MS discovers the BCMCS Controller address (see section ), the MS acquires the BCMCS session related information (see section ), including whether header compression is used and the header compression configuration parameters. The header compression configuration parameters are required by the specific header compression algorithm chosen. The header compression configuration parameters for ROHC U mode are listed as follows: LARGE_CIDS: Boolean, indicates whether large CID (0 ~ ) or small CIDs (0 ~ ) are used. MAX_CID: Nonnegative integer, indicates the maximum CID used, constrained by the choice of LARGE_CIDS. If it does not have the capability to handle the number of contexts indicated by MAX_CID, the MS may still accept the header compression configuration because it may only be interested in a subset of BCMCS streams and thus does not need to maintain all the contexts. Profile: Nonnegative integer, indicates the compression profile used. The profile ID for RTP profile is 0x000. MAX_HEADER: Nonnegative integer, indicates the maximum header size in octets that can be compressed. The suggested value is. MRRU: Nonnegative integer, indicates the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments. Value 0 means that no segment headers are allowed on the channel. When ROHC U mode is used, the BSN and MS follow []. The BSN sends IR packets at initialization and sends IR and IR-DYN at periodic refresh. 0. MS Requirements When the MS receives the BCMCS session related information from the BCMCS Controller, the MS checks whether the header compression algorithm is supported or not. If the header compression algorithm is supported, the MS shall store the header compression configuration parameters and shall follow ROHC U mode as specified in [].. BCMCS Controller Requirements During the BCMCS Information Acquisition (see section ), the BCMCS Controller shall indicate to the MS whether header compression is used or not. If ROHC U mode header compression is used, the BCMCS Controller shall also include the configuration parameters required for the ROHC U mode header compression.

98 GPP X.S00-A v.0 During the BSN session discovery (see section 0), the BCMCS Controller shall indicate to the BSN whether header compression is used or not. If ROHC U mode header compression is used, the BCMCS Controller shall also include the configuration parameters required for the ROHC U mode header compression. 0. BSN Requirements During BSN session discovery (see section 0), the BSN checks whether the header compression is required. If header compression is required and the BSN supports the header compression algorithm, the BSN shall configure the header compressor according to the configuration parameters received and perform header compression for the multicast IP flow when the multicast IP flow is received from the content server. If ROHC U mode is used, the BSN shall follow []. The BSN shall use PPP encapsulation to indicate the header compression protocol in use for the corresponding flow as specified in section of []. The BSN shall initialize the compressor by sending IR packets to the MS. In addition the BSN shall periodically send IR and IR-DYN packets to refresh the static and/or dynamic context as specified in []. The refresh periods are configurable by the operator. If the BSN does not support the header compression, it shall ignore the header compression configuration parameters and send IP packets without header compression.

99 GPP X.S00-A v.0 Accounting 0 0. General Accounting for BCMCS may be done using either per BAK based accounting and/or octet count based accounting. Per BAK based accounting is used for charging the BCMCS content receiver and octet count based accounting is used for charging the BCMCS content provider. BCMCS Accounting parameters are divided into airlink record collected by the RAN, and IP network specific parameters collected by the BSN or the BCMCS Controller. For octet count based accounting, the BSN shall merge airlink records with IP network specific records to form one or more Usage Data Records (UDR). For per BAK based accounting, the BCMCS Controller shall create a UDR once the BAK is distributed to the user. Both BSN and the BCMCS Controller shall use RADIUS accounting messages [] to send UDR information to the Home RADIUS Server via the serving RADIUS server. This is outlined as below in Figure - and Figure -, and further detailed in the subsequent sections. The BSN and the BCMCS Controller shall maintain UDR information until it receives positive acknowledgment from the RADIUS server that the RADIUS server has correctly received the RADIUS message. Likewise, the RADIUS server shall maintain the UDR until the record is delivered to a Home RADIUS server, or removed by the operator billing system. The method by which information is moved from a RADIUS server to a billing system is beyond the scope of this document as is the summary, reconciliation, and billing process used by the carriers. RAN BCMCS Airlink Records i.e., A0 Connection ID, PCF Address, BCMCS_FLOW_ID RADIUS Server BSN RADIUS Records BSN adds more info and sends RADIUS accounting info Figure - Octet Count Based Accounting Architecture

100 GPP X.S00-A v.0 MS BCMCS Information Acquisioon Response BCMCS Info rmation Acquisition Request RADIUS Server BCMCS Controller RADIUS Records The BCMCS Controller adds more info and sends RADIUS accounting info Figure - Per BAK based Accounting Architecture In this section, a lower case letter implies an accounting attribute in an airlink record whereas a capital letter implies an accounting attribute in a UDR... BAK Based Accounting Per BAK based accounting is based on BAK distribution.... BCMCS Controller Usage Data Record (UDR) Table - contains the complete BCMCS Controller UDR and the description of each field. Table - Complete BCMCS Controller UDR Item Parameter B. User Identifiers Description B Source IP Address IPv address of the MS. B Network Access Identifier (NAI) user@domain construct which identifies the user and home network of the MS. B Framed-IPv-Prefix MS IPv prefix. B IPv Interface ID MS IPv interface identifier. C. Session Identifiers C Account Session ID The Account Session ID is a unique accounting ID created by the BCMCS Controller. C Correlation ID The Correlation ID is a unique accounting ID created by the BCMCS Controller for each BAK distribution that allows accounting event to correlate with content information acqusition authentication and authorization. C BCMCS_FLOW_ID Identities of the BCMCS Flow for which this Usage Data Record is generated. C Multicast IP Address The Multicast IP address for a BCMCS flow. C Port The port number for a BCMCS flow. C Class This contains a string used by HAAA, see []. C0 Content Provider ID The Content Provider Identity to indentify the content provider that the BCMCS flow belongs to.

101 GPP X.S00-A v.0 D. Infrastructure Identifiers D D BCMCS Controller s IP Address BCMCS Controller s IPv Address G. Session Activity The IPv address of the RADIUS client in the BCMCS Controller The IPv address of the RADIUS client in the BCMCS Controller G Event Time This is an event timestamp which indicates the time that the BAK is sent to the MS. G BAK_ID BAK Identifier. An instance of G is used for each BAK.... Accounting Formats The BCMCS Controller and RADIUS server shall support RADIUS attribute formats as defined in [] and []. Table - lists each accounting parameter and its associated RADIUS attribute. Note: Attributes of type defined in [] and [] are vendor specific, and are used to transport GPP specific parameters. Attribute value types /0 to / within the GPP vendor specific space are reserved. The default Vendor ID value in Vendor Specific attributes shall be defined in IANA in order for cdma000 packet data service to support global roaming.

102 GPP X.S00-A v.0 Table - BCMCS Controller Accounting Parameter Attribute RADIUS Definitions RADIUS Attribute Definitions Item Parameter Type/ Vendor Type Maximum Payload Length (in octets) Format Field Special Values B. User Identifiers B Source IP Address ip-addr Framed-IP-Address This is the IP address of the MS used as a source IP address of the BCMCS Information Acquisition Request packet. B Network Access Identifier (NAI) string User-Name See []. B Source IPv Address / ipv-addr GPP_IPv-Address This is the IPv address of the MS used as a source IPv address of the BCMCS Information Acquisition Request packet. C. Session Identifiers C Account Session ID string Acct-Session-Id ASCII string of session ID C Correlation ID / string Correlation ID ASCII string of Correlation ID C BCMCS_FLOW_ID /00 variable string GPP_BCMCS_FLOW_ Identities of the BCMCS Flow for which this ID Usage Data Record is generated. C Multicast IP Address /0 (IPv) or Ip-addr GPP_Multicast_IP Identities of Multicast IP address for a (IPv) BCMCS flow C Port /0 Ip-port GPP_Port Identities the destination port number for a BCMCS flow C Class variable string Class See []. C0 Content Provider ID / variable string GPP_Content_Provide r_id Identity of the Content provider. D. Infrastructure Identifiers D BCMCS Controller IP Address ip-addr NAS-IP-Address IPv address of the RADIUS client in the BCMCS Controller D IPv BCMCS Controller Address Ipv-addr NAS-IPv-Address See []. G. Session Activity G Event Time time Event-Timestamp See []. G BAK_ID / string GPP_BAK_ID BAK Identifier and BAK Expire Time 0

103 GPP X.S00-A v BCMCS Controller Procedure The following event causes the BCMCS Controller to take accounting action: Successfully sending a current BAK, a subsequent BAK, or both to the MS. Upon successfully sending a BAK to the MS, the BCMCS Controller shall form a UDR for each flow if the per BAK based accounting is enabled in the system. The BCMCS Controller shall send a RADIUS Accounting Request message (Stop) to the home RADIUS server upon successful distribution of BAK(s) to the MS. If the BCMCS Controller receives the Class attribute in a RADIUS Access-Accept message (see section..), the BCMCS Controller shall include the Class attribute in the Accounting Request Message (stop). This is one time event accounting. If the BCMCS Controller sends both a current BAK and a subsequent BAK to the MS, it shall generate a second instance of G and shall include both instances of G in the RADIUS Accounting-Request message (stop). Further BAK renew for the same MS and same BCMCS_FLOW_ID is treated as a different accounting event.... RADIUS Server Procedure Upon receiving a RADIUS Accounting Request message (stop) from the BCMCS Controller, the RADIUS server shall respond with a RADIUS Accounting Response message... Octet Count Based Accounting BCMCS Airlink Records The RAN generates one of three types of airlink records over the A signaling: An A0 Connection Setup Airlink Record when the RAN establishes an A0 connection for the BCMCS flow identified by BCMCS_FLOW_ID. A BCMCS Active Start Airlink Record when the RAN starts transmitting the BCMCS flow identified by BCMCS_FLOW_ID over-the air service instance. A BCMCS Active Stop Airlink Record when the RAN stops transmitting the BCMCS flow identified by BCMCS_FLOW_ID over-the air service instance. The PCF uses the A0 Connection ID as the PCF Session Identifier Key in A0 setup messages. All the airlink records shall include a sequence number initialized to zero at A0 connection setup. The sequence number is unique for a single identification triplet (A0 Connection ID, PCF ID, and BCMCS_FLOW_ID). Upon receiving the A0 connection setup airlink record, the BSN updates the UDR with the airlink record information and stores the sequence number. The PCF increments the sequence number modulo in the subsequent airlink record transmitted over the corresponding A0 connection. The BSN shall compare the received sequence number with the previously stored sequence number (N). If the received sequence number is in the range from (N+) modulo to (N+) modulo, inclusive, the BSN shall act accordingly based on the information contained in the airlink record, and shall update its stored sequence number. If the received sequence number is in the range from (N-) modulo to N modulo, inclusive, The BCMCS Controller relies on the TCP acknowledgement mechanism to determine successful delivery of the BAK(s) to the MS.

104 GPP X.S00-A v.0 0 the BSN shall ignore the message. The same procedure continues for all the subsequent airlink records, until the closing of the A0 connection. In the event of retransmission, the PCF retransmits with the same sequence number, and the BSN shall not update the UDR if the same sequence number corresponding to a single identification triplet is received. There should be at most one outstanding unacknowledged airlink record at any given time. Detailed documents of airlink records are in [].... BCMCS A0 Connection Setup Airlink Record Table - contains fields present in the A0 Connection Setup Airlink Records. Table - A0 Connection Setup Airlink Fields Item Parameter Max Payload Length (octets) Format y Airlink Record Type = (BCMCS A0 Connection Setup) Integer y A0 Connection ID Integer y Airlink Sequence Number Integer c BCMCS_FLOW_ID Integer d Serving PCF ip-addr Each A0 connection and each airlink record is indexed via the A0 Connection ID.... BCMCS Active Start Airlink Record Table - contains fields present in BCMCS Active Start Airlink Records. Table - BCMCS Active Start Airlink Fields Item Parameter Max Payload Length (octets) Format y Airlink Record Type = (BCMCS Active Start) integer y A0 Connection ID integer y Airlink Sequence Number integer c BCMCS_FLOW_ID integer d Serving PCF ip-addr... BCMCS Active Stop Airlink Record Table - contains fields present in BCMCS Active Stop Airlink Records. Table - BCMCS Active Stop Airlink Fields Item Parameter Max Payload Format

105 GPP X.S00-A v.0 Length (octets) y Airlink Record Type = (BCMCS Active Stop) integer y A0 Connection ID integer y Airlink Sequence Number integer c BCMCS_FLOW_ID integer d BSID string d Subnet string g BCMCS Flow Transmision Time in Seconds integer Either d or d parameters are present in Table -. The RAN sends a list of pair of {d and g} (for x) or a list of pair of {d and g} (for HRPD) per flow identifying cell(s)/sector(s) under the PCF in the Active Stop Airlink Record when all cell(s)/sector(s) are deleted from transmitting the BCMCS flow over an already established A0 connection.... BSN Usage Data Record (UDR) Table - contains the complete BSN UDR and the description of each field. Either a pair of D and G or D and G can be occurred multiple times in an UDR. Table - Complete BSN UDR Item Parameter Description B. User Identifiers B Network Access Identifier (NAI) The group name (e.g., BCMCS@domain). C. Session Identifiers C Account Session ID The Account Session ID is a unique accounting ID created by the Serving BSN that allows start and stop RADIUS records from a single A0 connection to be matched. C Correlation ID The Correlation ID is a unique accounting ID created by the BSN for each BCMCS session that allows multiple accounting events for each associated A0 connection to be correlated. C Session Continue This attribute when set to true means it is not the end of a Session and an Accounting Stop is immediately followed by an Account Start Record. If the value is set to False or if the VSA is absent, it indicates the end of a session. C BCMCS_FLOW_ Identities of the BCMCS Flow for which this Usage Data Record is generated. ID C Multicast IP The Multicast IP address for a BCMCS flow. Address C Port The port number for a BCMCS flow. C0 Content Provider The Content Provider Identity to indentify the content provider that the BCMCS ID flow belongs to. D. Infrastructure Identifiers D BSN The IPv address of the RADIUS client in the BSN. Address D Serving PCF The IP address of the serving PCF, i.e., the PCF in the serving RAN. D BSID SID + NID + Cell Identifier type. D IPv BSN The IPv address of the BSN. Address D Subnet The subnet information for HRPD. G. Session Activity G Data Octet Count The total number of octets in IP packtes sent to the RAN, as received at the BSN from the MR or the BCMCS content server. G Event Time This is an event timestamp which indicates one of the following:

106 GPP X.S00-A v.0 0 G BCMCS Tranmission Time Z. Container The start of an accounting session if it is part of a RADIUS start message. The end of an accounting session if it is part of a RADIUS stop message. An Interim-Update accounting event if it is part of a RADIUS Interim-Update message. The total BCMCS flow transmission time in seconds. Z Container GPP Accounting Container attribute. This attribute is used to embed GPP AVPs. This attribute is further described in [].... Accounting Formats The BSN and the RADIUS server shall support RADIUS attribute formats as defined in [] and []. Table - lists each accounting parameter and its associated RADIUS attribute. Either a pair of D and G or D and G can occur multiple times in an UDR. Note: Attributes of type defined in [] and [] are vendor specific, and are used to transport GPP specific parameters. Attribute value types /0 to / within the GPP vendor specific space are reserved. The default Vendor ID value in Vendor Specific attributes shall be defined in IANA in order for cdma000 packet data service to support global roaming.

107 GPP X.S00-A v.0 Item Parameter Type/ Vendor Type Table - BCMCS Accounting Parameter Attribute RADIUS Definitions RADIUS Attribute Definitions Maximum Payload Length (in octets) Format Field Special Values B. User Identifiers B Network Access Identifier (NAI) string User-Name See []. C. Session Identifiers C Account Session ID string Acct-Session-Id ASCII string of session ID C Correlation ID / string Correlation ID ASCII string of Correlation ID C Session Continue / integer GPP_Session_cont 0=False, =True C BCMCS_FLOW_ID /00 variable string GPP_BCMCS_FLOW_ Identities of the BCMCS Flow for which this ID Usage Data Record is generated. C Multicast IP Address /0 (IPv) or Ip-addr GPP_Multicast_IP Identities of Multicast IP for a BCMCS flow (IPv) C Port /0 Ip-port GPP_Port Identities the destination port number for a BCMCS flow C0 Content Provider ID / variable string GPP_Content_Provide Identity of the Content provider. r_id D. Infrastructure Identifiers D BSN Address ip-addr NAS-IP-Address IPv address of the RADIUS client in the BSN D Serving PCF / ip-addr GPP_PCF IP_Addr The serving PCF is the PCF in the serving RAN. D BSID /0 string GPP_BSID A number formed from the concatenation of SID ( octets)+ NID ( octets)+ Cell Identifier (type ) ( octets). In the Cell Identifier the upper bits are the Cell Id and the lower bits are the Sector. Each item is encoded using hexadecimal uppercase ASCII characters. D IPv BSN Address ipv-addr NAS-IPv-Address See []. D Subnet /0 string GPP_Subnet The subnet for HRPD system. G. Session Activity G Data Octet Count (Terminating) integer Acct-Output-Octet See []. G Event Time time Event-Timestamp See []. G BCMCS Trasmission Time /0 integer GPP_BCMCS_TRA_TI The total BCMCS flow transmission time in ME seconds. Z. Container Z Container / Variable string GPP_Container See [].

108 GPP X.S00-A v BSN Procedures The following events cause the BSN to take accounting action: Reception of A0 Connection Setup Airlink Record over A0 interface, A0 connection termination at the BSN, Arrival of forward link direction BCMCS flow, Reception of Active Start Airlink Record, Reception of Active Stop Airlink Record, Interim-Update record trigger, Stop record trigger, Time of day timer expiry. Each BCMCS session is identified with a Correlation ID provided to the SAAA. All UDR information is stored and transmitted per tuple of {BCMCS_FLOW_ID, Multicast IP address/port, A0 connection ID}. UDRs are created, initialized, modified, maintained, copied, and released for each A0 connection. The BSN shall create one UDR per A0 connection ID. The BSN releases a UDR when any of the following events occur: An existing A0 connection is closed. The BSN determines the BCMCS session associated with the Correlation ID has ended. For example, the program has ended. At an initial A0 connection establishment, a UDR is created and initialized from relevant airlink records. When the A0 connection is disconnected, the BSN closes the UDR and sends accounting records to the RADIUS server. RADIUS accounting messages are generated from the information in the UDR. The Correlation ID is used to match different accounting records (Account Session IDs) across the A0 connection for a single BCMCS session in which over the air transmission may be on and off. One Correlation ID for all A0 connections is maintained for a BCMCS session for each BCMCS_FLOW_ID within the same BSN. The Account Session ID is used to match a single RADIUS Start and Stop pair. A different Account Session ID is used for each A0 connection. Airlink records are associated with an A0 connection ID and PCF address. The BSN matches the A0 Connection ID and PCF address in the airlink record to the A0 Connection ID and PCF address in the appropriate UDR. Some events cause certain UDR fields to change in the middle of a session. When this happens, one of two approaches shall be taken: () a container attribute as specified in [] is created and the changed fields are embedded in that container attribute. This allows the UDR to continue to accumulate accounting information after an event without transmitting a RADIUS message. Alternatively (), the BSN may send a RADIUS Stop record to capture accounting data before the event, followed by a RADIUS Start record with the new field values. The BSN may send a The use of the Account session ID as described in this section does not apply to the container accounting procedures.

109 GPP X.S00-A v RADIUS Stop and RADIUS Start anytime during a single session as long as no accounting data is lost. In these cases, the BSN shall send the same Correlation ID in both the RADIUS Start and RADIUS Stop records. The subsequent sections specify the actions to take for each event.... A0 Connection Setup Airlink Record Arrives If the BSN receives a BCMCS A0 Connection Setup Airlink Record with a new A0 connection ID, the BSN shall use the BCMCS A0 Connection Setup Airlink Record to generate a new UDR for the corresponding BCMCS_FLOW_ID and fill the following fields of the new UDR: D, and D (IPv) or D(IPv), Zero fields G and G.... Arrival of Forward Link Direction BCMCS Flow For any BCMCS flow processed by BSN in the forward direction, the BSN shall use the Multicast IP address and Port to find the associated UDR(s). The BSN shall: Increment G by the number of octets before compression in IP packets sent to the RAN for each UDR that matches the Multicast IP address and Port number.... Active Start Airlink Record Arrives When the BSN receives an Active Start Airlink record from the RAN, the BSN shall set UDR fields according to the Active Start airlink record. The PDSN shall then send RADIUS Accounting-Request (Start) message to the HAAA with a new Accounting Session ID.... Active Stop Airlink Record Arrives When the Serving BSN receives an Active Stop Airlink record from the RAN, the BSN shall: Increment G by the value of g for each BSID/subnet. Send RADIUS Accounting-Request (Stop) message to the HAAA with the same Accounting Session ID.... Interim-Update Record Trigger When the Interim-Update Record Trigger initiates, the BSN shall send a RADIUS Accounting-Request Interim-Update record based on the current UDR. The Interim-Update Record Trigger is an operator configurable time interval since the last RADIUS accounting record was sent for a UDR.... Stop Record Trigger Additional conditions may trigger a RADIUS Accounting-Request (Stop) record to be sent by the BSN such as: When the size of the RADIUS accounting record to be sent for the UDR exceeds an operator configurable threshold. Any time during a session as an implementation dictates.

110 GPP X.S00-A v.0 When the Stop Record Trigger initiates, the BSN shall add a Session Continue attribute in the UDR with the value set to (True). The BSN shall send a RADIUS Accounting-Request (Stop) record based on the current UDR then zero fields G and G. Immediately afterwards, the BSN shall send a RADIUS Accounting-Request (Start) record based on the current UDR containing a new Account Session ID and the same Correlation ID.... Time of Day Timer Expires The time of day timer(s) shall be a set of operator configurable parameters for certain time(s) of day. These timers may be used, for example, to delineate peak and off-peak billing hour boundaries. When an accounting time of day timer expires, the BSN shall either: 0 Or, Create a new Container attribute in the UDR with Container-Reason Tariff Boundary, Event-timestamp current time and attributes G and G are copied to the container. Zero fields G and G. Add a Session Continue attribute in the UDR with the value set to (True). Send a RADIUS Accounting-Request (Stop) record based on the current UDR. Zero fields G and G. Send a RADIUS Accounting-Request (Start) record based on current UDR containing a new Account Session ID and the same Correlation ID RADIUS Server Procedure Upon receiving an Accounting Request message from the BSN, the RADIUS server shall respond with an Accounting Response message.

111 GPP X.S00-A v BCMCS RADIUS Vendor Specific Attribute Figure - shows the general Vendor Specific Format for all GPP BCMCS RADIUS vendor specific attributes. The type and vendor ID are the same for every attribute. The vendor ID of is used to indicate GPP Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Vendor-value Figure - GPP BCMCS RADIUS Attribute Format Authorization Parameters: This attribute specifies the BCMCS bearer path establishment authorization parameters. It may be present in the RADIUS Access-Request message sent from the BSN to the SAAA/BCMCS Controller Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length Unused Value (BAK_I D) Sub-Type (=) Length Time stamp long length Value (Time stamp long) Value (Time stamp long) Value (Time stamp long) Value (Time stamp long) Value (Time stamp long) Value (Time stamp long) Value (Time stamp long) Value (Time stamp long) Value (Time stamp long) Sub-Type (=) Length Value (Auth Signature) Figure - Authorization Parameters VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: Vendor-Length: variable, >= Sub-Type (=): Sub-Type for BAK Identifier attribute Length: length of the BAK Identifier attribute (= octets) BAK_ID: BAK identity coded as an unsigned integer. Exactly one instance of Subtype () attribute shall be present. Sub-Type (=): Sub-Type for Time stamp long attribute Length: length of the Time stamp long attribute (= variable, greater than, less than or equal to octets). This length field denotes the length of Sub-Type ().

112 GPP X.S00-A v Time stamp long length: 0 in bits. This field denotes the length of system time long that is defined in the air interface [][]. Time stamp long: cdma system time used to compute authorization signature (see[][]). If the length of the Time stamp long field is less than the space allocated, the value of the Time stamp long field shall be aligned such that the LSB of the Time stamp long field is the LSB of the allocated space. The remaining Most Significant Bits (MSB) shall be set to 0. Exactly one instance of Subtype () shall be present. Sub-Type (=): Sub-Type for Authorization Signature attribute Length: length of the Authorization Signature attribute (= octets) Authorization Signature: Authorization Signature received from the MS. Exactly one instance of Subtype () shall be present. BCMCS_FLOW_ID: This attribute specifies the BCMCS_FLOW_ID. It may be present in the RADIUS Access-Request message and shall be present in the RADIUS Accounting-Request (Start, Stop and Interim) sent from the BSN to the SAAA/BCMCS Controller. Type: Length: variable, greater than Vendor-ID: Vendor-Type: 00 Vendor-Length:,, or octets Vendor-Value = BCMCS_FLOW_ID coded as a binary value BCMCS Capability: This attribute specifies the capability of the BSN or the BCMCS Controller. It may be present in the RADIUS Access-Request and the RADIUS Access-Accept messages sent between the BSN and the SAAA/BCMCS Controller. If this attribute is not present, it implies the revision protocol is Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length Protocol Revision Figure - BCMCS Capability VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: 0 Vendor-Length: >= Sub-Type (=): Sub-Type for Protocol Revision Length: length of the Protocol Revision attribute (= octets) Protocol Revision: The BSN and the SAAA/BCMCS Controller shall set this field to to indicate revision 0 of X.S00 or to indicate revision A of X.S00. Protocol revision shall be encoded as an unsigned integer. Exactly one instance of Sub-Type () shall be included. 00

113 GPP X.S00-A v Common Session Info: This attribute specifies the BSN session information that is needed by both BSN and RAN. One or more instance of this VSA may be included in the RADIUS Access-Accept message sent from the SAAA/BCMCS Controller to the BSN Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length Value (BCMCS_FLOW_ID) (, or bits) BCMCS_FLOW_ID ( or bits) BCMCS_FLOW_ID ( bits) Sub-Type (=) Length Value (Program Start Time) Sub-Type (=) Length Value (Program End Time) Value (Program End Time) Sub-Type (=) Length Value (Program Allowed Registration Time) Sub-Type (=) Length Value (Authorization Required Flag) Sub-Type (=) Length Flow Profile ID Sub-Type (=) Length BCMCS_Flow_Prior ity Figure - Common Session Info VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: 0 Vendor-Length: variable, >= Sub-Type (=): Sub-Type for BCMCS_FLOW_ID attribute Length: length of the BCMCS_FLOW_ID attribute (=,, or octets) BCMCS_FLOW_ID: BCMCS flow identity coded as a binary value. More than one instance of Sub-Type () may be included. At least one instance of Sub-Type () shall be included. Sub-Type (=): Sub-Type for Program Start Time attribute Length: length of the Program Start Time attribute (= octets) Program Start Time: Indicates the program start time. This value shall be encoded using an unsigned integer and shall contain the number of seconds since January, 0 00:00 UTC. This attribute is not included if this is on going program. Zero or one instance of Sub-Type () may be present. If Sub-type () is present, Sub-type () shall be present. Sub-Type (=): Sub-Type for Program End Time attribute Length: length of the Program End Time attribute (= octets) Program End Time: Indicates the program end time. This value shall be encoded using an unsigned integer and shall contain the number of seconds since January, 0 00:00 UTC. Zero or one instance of Sub-Type () may be present. Sub-Type (=): Sub-Type for Program Allowed Registration Time attribute Length: length of the Program Allowed Registration Time attribute (= octets) Program Allowed Registration Time: Indicates the program allowed registration time. This value shall be encoded using an unsigned integer and shall contain the number of seconds before the program start time. 0

114 GPP X.S00-A v Zero or one instance of Sub-Type () may be present. Sub-Type (=): Sub-Type for Authorization Required Flag attribute Length: length of the Authorization Required Flag attribute (= octets) Authorization Required Flag: Indicates whether the BCMCS registration authorization is required for the corresponding flow. 0. Authorization is not required for this flow. Authorization is required for this flow Exactly one instance of Sub-Type () shall be included. Sub-Type (=): Sub-Type for QoS Parameter attribute Length: length of the QoS Parameter attribute (= ) Flow Profile ID: One Flow Profile ID is bits length. This field shall be set according to the QoS requirements for a flow. Flow Profile ID can be found in []. One instance of Sub-Type () may be present. Sub-Type (=): Sub-Type for BCMCS_Flow_Priority Length: length of the BCMCS_Flow_Priority attribute (= ) BCMCS_Flow_Priority: This field indicates the priority of the BCMCS IP flow and shall be set to an unsigned integer. Priority is the highest and 0 is the lowest. Specifically: : Priority 0 to for regular BCMCS Flow 000-: Priority to for emergency BCMCS Flow All other values are reserved. Zero or one instance of Sub-Type () may be present. BSN Session Info: This attribute specifies the session information for one flow that is needed only by the BSN. One or more instance of this VSA may be included in the RADIUS Access-Accept message sent from the SAAA/BCMCS Controller to the BSN Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length Value (BCMCS_FLOW_ID) (,, or bits) BCMCS_FLOW_ID (, or bits) BCMCS_FLOW_ID ( bits) Sub-Type (=) Length Value (Multicast IP address) (IPv or IPv) Multicast IP address (IPv) Multicast IP address (IPv) Multicast IP address (IPv) Sub-Type (=) Length Value (Destination Port Number) Sub-Type (=) Length Header Compression Algorithm Sub-Type (=) Length Type for CID Sub-Type (=) Length Value (MAX CID) Sub-Type (=) Length Value (Compression profile) Sub-Type (=) Length Value (MAX Header Size) Sub-Type (=) Length MRRU Sub-Type (=0) Length Value (Content Server Source IP address) Value (Content Server Source IP address) Sub-Type (=) Length Value (Content Server Source IPv address) Value (Content Server Source IPv address) Value (Content Server Source IPv address) 0

115 GPP X.S00-A v Value (Content Server Source IPv address) Figure - BSN Session Info VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: 0 Vendor-Length: variable, >= Sub-Type (=): Sub-Type for BCMCS_FLOW_ID attribute Length: length of the BCMCS_FLOW_ID attribute (=,, or octets) BCMCS_FLOW_ID: BCMCS flow identity coded as a binary value. Exactly one instance of Subtype () shall be present. Sub-Type (=): Sub-Type for Multicast IP Address attribute Length: length of the Multicast IP Address attribute (= octets for IP v or octets for IPv) Multicast IP Address: Multicast IP Address Exactly one instance of Subtype () shall be present Sub-Type (=): Sub-Type for Destination Port Number attribute Length: length of the Destination Port Number attribute (= octets) Port Number : Destination Port Number. Exactly one instance of Sub-Type () shall be present. Sub-Type (=): Sub-Type for Header Compression Algorithm attribute Length: length of the Header Compression Algorithm attribute (= octets) Header Compression Algorithm: 0. No Header Compression. ROHC-U mode All other values are reserved. Zero or one instance of Sub-Type () may be present. Sub- Type (=): Sub- Type for CID attribute Length: length of the CID attribute (= octets) CID: this field shall indicate whether the small CID or large CID is used: 0. Small CID. Large CID Zero or one instance of Sub-Type () may be present. Sub- Type (=): Sub- Type for MAX CID attribute Length: Length of the MAX CID attribute (= octets) MAX_CID: this field shall contain the maximum CID used. Zero or one instance of Sub-Type () may be present. Sub- Type (=): Sub- Type for Compression Profile attribute Length: length of the Compression Profile attribute (= octets) Compression Profile: this field indicates the compression profile used. The profile ID shall be set to 0x000 for ROHC RTP profile. Zero or one instance of Sub-Type () may be present. Sub- Type (=): Sub- Type for MAX Header Size attribute Length: length of the MAX Header Size attribute (= octets) Max Header Size: This field shall contain the maximum header size in octets that can be compressed. If this Sub-Type is omitted, the value of shall be used. Zero or one instance of Sub-Type () may be present. 0

116 GPP X.S00-A v Sub Type (=): Sub Type for MRRU attribute Length: length of the MRRU attribute (= octets) Type for MRRU: This field shall contain the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments. If no segment headers are allowed on the channel, this field shall be set to 0. Zero or one instance of Sub-Type () may be present. Sub-Type (=0): Sub-Type for Content Server Source IP Address attribute Length: length of the Content Server Source IP Address attribute (= + x the number of addresses) Source IP Address: This field shall contain the Content Server Source IP Addresses to be used by the BSN for IGMPv. Zero or one instance of Sub-Type (0) may be present. Sub-type (=): Sub-Type for Content Server Source IPv Address attribute Length: length of the Content Server Source IPv Address attribute (= + x the number of addresses octets for IPv) Content Server Source IPv Address: This field shall contain the Content Server Source IPv Addresses to be used by MLDv source address filtering. Zero or one instance of Sub-Type () may be present. RAN Session Info: This attribute specifies the session information that needs to be known only by the RAN. One or more instance of this VSA may be included in the RADIUS Access-Accept message sent from the SAAA/BCMCS Controller to the BSN Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length Value (BCMCS_FLOW_ID) (, or bits) BCMCS_FLOW_ID ( or bits) BCMCS_FLOW_ID ( bits) Sub-Type (=) Length Value (Encryption mechanism) Sub-Type (=) Length Unused Value (BAK_I D) Sub-Type (=) Length Value (BAK) Value (BAK) Value (BAK) Value (BAK) Value (BAK) Sub-Type (=) Length Value (BAK Expire Time) BAK Expire Time Sub-Type (=) Length Value (Session Bandwidth) Session Bandwidth Figure - RAN Session Info VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: 0 Vendor-Length: variable, >= 0

117 GPP X.S00-A v Sub-Type (=): Sub-Type for BCMCS_FLOW_ID attribute Length: length of the BCMCS_FLOW_ID attribute (=,, or octets) BCMCS_FLOW_ID: BCMCS flow identity coded as a binary value. Exactly one instance of Subtype () shall be present. Sub-Type (=): Sub-Type for Encryption Mechanism attribute Length: length of the Encryption Mechanism attribute (= octets) Encryption Mechanism: Indicates Link Layer Encryption or High Layer Encryption. 0. High layer encryption in the Content Server. Link layer encryption in the RAN Zero or one instance of Sub-Type () may be present. Sub-Type (=): Sub-Type for BAK Identifier attribute Length: length of the BAK Identifier attribute (= octets, see []) BAK_ID: BAK identity coded as an unsigned integer. Zero or one instance of Sub-Type () may be present. Sub-Type (=): Sub-Type for BAK attribute Length: length of the BAK attribute (= octets, see []) BAK: Broadcast Access Key coded as a binary value. Zero or one instance of Sub-Type () may be present. Sub-Type (=): Sub-Type for BAK Expire Time attribute Length: length of the BAK Expire Time attribute (= octets) BAK Expire time: Broadcast Access Key Expire time. This value shall be encoded using an unsigned integer and contain the number of seconds since January, 0 00:00 UTC. Zero or one instance of Sub-Type () may be present. Sub-Type (=): Sub-Type for Session Bandwidth attribute Length: length of the Session Bandwidth attribute (= octets) Session Bandwidth attribute: Indicates the bandwidth (data rate) for the flow associated with BCMCS Flow ID expressed in kilobits per second. When sent from the Controller to the BSN, the bandwidth is that of the uncompressed flow at the IP layer. When sent from the BSN to the RAN on the A0 interface, the bandwidth is that of the IP flow after applying IP Header compression if any. Zero or one instance of Sub-Type () may be present. Reason Code: This attribute specifies the reason to send the RADIUS Access-Accept message. It shall be present in the RADIUS Access-Request message sent from the BSN to the SAAA/BCMCS Controller. Type: Length: variable, greater than Vendor-ID: Vendor-Type: 0 Vendor-Length: Vendor-Value = Reason Code. The BSN shall set this field to one of the following value: 0. Reserved. Authorization Only. Session Discovery Only. Authorization and Session Discovery 0

118 GPP X.S00-A v Subnet: This attribute specifies the Subnet and Sector ID information of the HRPD RAN. One or more attributes may be present in the RADIUS Accounting Messages (Stop) sent from the BSN to the SAAA/BCMCS Controller Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length Subnet length Subnet Subnet Subnet Subnet Subnet Sub-Type (=) Length Sector ID Sector ID Sector ID Sector ID Sector ID Figure - Subnet VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: 0 Vendor-Length: variable, >= Sub-Type (=): Sub-Type for Subnet attribute Length: length of the Subnet attribute (<= variable <= octets) Subnet Length: The element shall contain the number of bits in the subnet identifier. These bits shall form the most significant bits of any sector identifier within the subnet. This field shall be encoded as a positive integer from to. Subnet: The element shall contain a binary representation of the subnet value for the subnet where the BCMCS block is valid. This field is bits long. If the Subnet length (L) is less than bits, then the -L least significant bits shall be filled with all 0s. Sub-Type (=): Sub-Type for Sector ID attribute Length: length of the Sector ID attribute (= octets) Sector ID: The element shall contain a binary representation of the Sector ID value where the BCMCS block is valid. Either Sub-Type () or Sub-Type (), or both shall be present. TK Info: This attribute specifies the TK and TK_RAND. It shall be present in the RADIUS Access-Accept message sent from the Home RADIUS Sever to the BCMCS Controller Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length TK 0

119 GPP X.S00-A v.0 TK TK TK TK Sub-Type (=) Length TK_RAND TK_RAND Figure - TK Info VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: Vendor-Length: = Sub-Type (=): Sub-Type for TK attribute Length: length of the TK attribute (= octets, see []) TK: Temporary Key. Exactly one instance of Subtype () shall be present. Sub-Type (=): Sub-Type for TK_RAND attribute Length: length of the TK_RAND attribute (= 0 octets, see []) TK_RAND: A random number used for generating TK. Exactly one instance of Subtype () shall be present. BAK_ID: This attribute specifies the BAK_ID and BAK_Expire. It shall be present in the RADIUS Accounting-Request (Stop) message sent from the BCMCS Controller to the Home RADIUS server Type Length Vendor-ID Vendor-ID (cont) Vendor-Type Vendor-Length Sub-Type (=) Length Unused BAK_ID Sub-Type (=) Length Value (BAK Expire Time) Value (BAK Expire Time) Figure - BAK_ID VSA Format Type: Length: variable, greater than Vendor-ID: Vendor-Type: Vendor-Length: variable, >= Sub-Type (=): Sub-Type for BAK_ID Length: length of the BAK_ID attribute (= octet) BAK_ID: BAK Identifier. Exactly one instance of Subtype () attribute shall be present. Sub-Type (=): Sub-Type for BAK_Expire attribute Length: length of the BAK_Expire attribute (= octets) 0

120 GPP X.S00-A v BAK_Expire: Broadcast Access Key Expire time. This value shall be encoded using an unsigned integer and contain the number of seconds since January, 0 00:00 UTC. This sub-type may be present. Acq Info Time Stamp: This attribute specifies the time stamp that received from the MS in the BCMCS Information Acquisition Request message transported in the HTTP Post. It shall be present in the RADIUS Access-Request message sent from the BCMCS Controller to the Home RADIUS Sever. Type: Length: variable, greater than Vendor-ID: Vendor-Type: Vendor-Length: = Acq Info Time Stamp: Indicates the time stamp that received from in the BCMCS Information Acquisition Request message transported in HTTP Post. This value shall contain the number of seconds since January, 0 00:00 UTC. Program ID: This attribute specifies the Program ID. It may be present in the RADIUS Access-Request message sent from the BSN to the SAAA/BCMCS Controller. Type: Length: variable, greater than Vendor-ID: Vendor-Type: Vendor-Length:,, or octets Vendor-Value = Program ID coded as a binary value Program Name: This attribute specifies the Program Name. It may be included in the RADIUS Access-Request and RADIUS Access-Accept messages sent between the Home RADIUS Sever and the BCMCS Controller. Type: Length: variable, greater than Vendor ID: Vendor-Type: Vendor-Length = variable, >= Vendor-Value = UTF- String value containing the name of the BCMCS program. Content Provider ID: This attribute specifies the Content Provider ID. It may be present in the RADIUS Access-Request message from the BCMCS Controller to the BSN and in the RADIUS Accounting-Request (Start, Stop and Interim) sent from the BSN to the SAAA/BCMCS Controller and from the BCMCS Controller to the HAAA Type Length Vendor-ID 0

121 GPP X.S00-A v.0 0 Vendor-ID (cont) Vendor-Type Vendor-Length Character Set Content Provider ID Content Provider ID Figure -0 Content Provider ID format Type: Length: variable, greater than Vendor ID: Vendor-Type: Vendor-Length = variable, >= Character Set = UTF- String value containing the name of the BCMCS program. Character Set: This field indicates the character set encoding type used for the Content Provider ID field. This field shall be set to the follows: 00H: ASCII- 0H: UTF- 0H: Unicode Other: reserved ContentProviderID: Contains the identification (name) of the Content Provider that is the source of the content. 0

122 GPP X.S00-A v.0 A List of GPP VSAs between the BSN and SAAA/BCMCS Controller The following table provides a guide to the GPP vendor specific attributes that may be found in the RADIUS Access-Request, RADIUS Access-Accept messages and RADIUS Accounting-Request messages (following the RADIUS standard approach) between the BSN and SAAA/BCMCS Controller. The VSA types with vendor ID are reserved and shall only be allocated by published GPP documents. The entries in the table are defined as follows: 0 This attribute shall not be present. 0+ Zero or more instances of this attribute may be present. 0- Zero or one instance of this attribute may be present. Exactly one instance of this attribute shall be present. + One or more instances of this attribute may be present. Table - GPP VSA Table between BSN and SAAA/BCMCS Controller VSA Type Access- Request Access- Accept Accounting Start Accounting Stop Accounting Interim- Update CoA- Request Disconnect- Request Container / Serving PCF / BSID / Correlation ID / Session Continue / Authorization Parameters BCMCS_FLO W_ID BCMCS Capability Common Session Info BSN Session Info RAN Session Info / / / / / / Reason Code / BCMCS Flow Transmission Time / Subnet / Multicast IP Address / Port / Program ID /

123 GPP X.S00-A v.0 Content Provider ID /

124 GPP X.S00-A v.0 A List of GPP VSAs between the BCMCS Controller and HAAA The following table provides a guide to the GPP vendor specific attributes that may be found in the RADIUS Access-Request, RADIUS Access-Accept messages and RADIUS Accounting-Request messages (following the RADIUS standard approach) between the BCMCS Controller and HAAA. The VSA types with vendor ID are reserved and shall only be allocated by published GPP documents. The entries in the table are defined as follows: 0 This attribute shall not be present. 0+ Zero or more instances of this attribute may be present. 0- Zero or one instance of this attribute may be present. Exactly one instance of this attribute shall be present. + One or more instances of this attribute may be present. 0 Table - GPP VSA Table for BCMCS between the BCMCS Controller and HAAA VSA Type Access- Request Access- Accept Access-Chal lenge Accounting Stop Correlation ID / 0-0- Multicast IP Address / Port / TK Info / BAK_ID / Acq Info Time Stamp / Program Name / Content Provider ID / Note: Accounting Start and Accounting Interim-update shall not be sent by the BCMCS Controller to report per BAK based accounting.

125 GPP X.S00-A v.0 Annex A: Call Flows (Informative) Call flow for Registration Authorization, Bearer Path Setup, and BSN/RAN session discovery MS BSC/PCF BSN. Overhead messages SAAA/BCMCS Controller. BCMCS Registration (BCMCS_FLOW_ID, Auth Signature). Optionally perform BAK_HASH if BAK is available. BC Service Request (BCMCS_FLOW_ID, Auth Signature). Access Request (BCMCS_FLOW_ID, Authorization Parameters, Reason Code = ). BC Service Response (BAK_HASH Successful, Common Session info, RAN Session Info). Access Accept (Common Session info, BSN Session Info, RAN Session info). BC Registration Request 0. Registration Accept. BC Registration Reply 0 Figure A - Registration Authorization, Bearer. The MS receives content availability and radio parameter and information from the overhead messages.. The MS performs a BCMCS registration for BCMCS_FLOW_ID(s) with the authorization signature included.. If the BSC/PCF has BAK information, the RAN may check BAK_HASH.. The BSC/PCF sends the A BC Service Request to the BSN to request RAN session information and includes the BCMCS_FLOW_ID and the authorization signature.. The BSN sends the RADIUS Access-Request message to the SAAA/BCMCS Controller. The message includes the BCMCS_FLOW_ID, Authorization Parameters, and Reason Code. In Messages between MS and BSC/PCF in this figure are not exact names specified in the air interface documents. These messages denote generic behaviors for BCMCS Registration Authorization performed between MS and BSC/PCF.

126 GPP X.S00-A v.0 this example, the BSN sets Reason Code to to indicate both authorization and BSN session information are needed.. The BCMCS Controller performs the authorization. Then the BCMCS Controller sends the RADIUS Access-Accept message to the BSN including BCMCS session information.. The BSN sends BC Service Response to the BSC/PCF including BCMCS session information that RAN needs.. The RAN sends BC Registration Request to the BSN to set up a A0 connection.. The BSN responds with BC Registration Response. 0. The RAN sends Registration Accept to the MS.

127 GPP X.S00-A v.0 Call Flow for BCMCS Information Acquisition Authentication and Integrity Protection

128 GPP X.S00-A v.0 MS BSC/ PCF PDSN BCMCS Controller Home RADIUS Server. BCMCS HTTP Post ( XML body: NAI, Program Name/ Multicast IP address/port, Information Type Indicator). Access Request [Digest-URI, Digest- Method, other digest attributes). Calculate digestresponse using Auth-Key. BCMCS HTTP 0 Unauthorized with WWW- Authenticate Response Header (digest-challenge). BCMCS HTTP Post with Authorization Request Header (digest-response) (XML body: NAI, Program Name/Multicast IP address/port, Information Type Indicator ). Access Challenge (Digest- Nonce, other digest attributes). Access Request [Acq Info TimeStamp, Digest-Response, other digest attributes, Correlation ID). Derive Auth Key and perform Authentication and Service Authorization. Access Accept (H(A), TK, TK_RAND, Program name, Class) 0. Compute auth-info using H(A) and other Digest Attributes. BCMCS HTTP 00 OK with Authentication-Info header (auth-info) (XML body: Application Info, BCMCS Security Info, or/and BCMCS Session Related Info) Figure A - HTTP Authentication and Integrity Protection

129 GPP X.S00-A v The MS sends the BCMCS HTTP Information Request that includes NAI, the Program Name or Multicast IP address/port to the BCMCS Controller to request the BCMCS information. In the message, the MS also indicates what type of information is requested.. Upon receiving the HTTP Post from the MS without an authorization header, if the BCMCS Controller decides that authentication and integrity protection is required, and a valid nonce is not available in the BCMCS Controller, the BCMCS Controller sends a RADIUS Access-Request message to the Home RADIUS Server according to [] with Digest-Qop set to auth-int to request a nonce.. The home RADIUS server chooses a nonce and responds with an Access-Challenge contaninging Digest-Nonce and other digest attributes according to [].. The BCMCS Controller sends the 0 (Unauthorized) response message to the MS. This response includes a WWW-Authenticate header field containing the digest-challenge with qop set to auth-int per [].. Upon receiving the 0 Unauthorized response, the MS computes digest-response. The MS produces a WWW-Authentication header using the Auth-Key and the received challenge using Digest function according to [].. The MS re-sends the BCMCS HTTP Information Request with the WWW-Authentication header including digest-response.. The BCMCS Controller sends the RADIUS Access-Request to the Home RADIUS Server including Digest-Response attribute and other digest attributes, see RADIUS Extension for Digest Authentication []. The Digest-Response attribute includes the request-digest of digest-response taken from the Authorization Request Header. The other digest attributes include Realm, Nonce, QOP etc.. The Home RADIUS Server performs the authentication as specified in []. Then it performs the service authorization and derives Auth-key.. Upon successful authentication and authorization, the Home RADIUS Server responds with the RADIUS Access-Accept message to the BCMCS Controller including TK and TK_RAND. 0. The BCMCS Controller computes auth-info using Digest-HA, other digest attributes, and hash of the message body according to [].. Upon successful authentication, the BCMCS Controller sends the BCMCS HTTP 00 OK with Authentication-Info Header including auth-info. In the message body, the response includes information that the MS has requested, for example, application information, the security parameters (such as TK_RAND, BAK_ID, BAK Expiry time, and BAK encrypted with TK) and some other BCMCS Link Layer information (such as flow treatment (e.g., header compression), association between BCMCS_FLOW_ID and multicast IP address and port number etc).

130 GPP X.S00-A v.0 Call flow for Network Initiated Bearer Path Setup and BSN/RAN session information discovery MS BSC/PCF BSN SAAA/BCMCS Controller. Pre provisioned Flow + receiving area. CoA-Request (NAS IP Address, Common/ BSN/RAN session Info, BSID/ Subnet_ID etc.). CoA ACK. Send IGMP Join to MR. A- BC- Service Initiate Request. A- BC- BC- Service Initiate Response 0. Overhead messages. A- BC- Registration Request. A- BC- Registration Reply Figure A - Network Initiated Flow. The BCMCS Controller has a provisioned BCMCS flow and the receiving area for the flow.. The BCMCS Controller sends a CoA-Request message to the BSN directly or through the SAAA. The message includes the Common, BSN and RAN Session Info, Subnet/BSID etc.. The BSN processes the message and sends the RADIUS CoA-ACK message to the BCMCS Controller.. The BSN triggers the MR to join the multicast group for the network initiated flow.. The BSN sends an A-BC-Service Initiate Request to the BSC/PCF including common session information and RAN session information that RAN needs.. The RAN responds back with an A-BC-Service Initiate Response.. The RAN sends BC Registration Request to the BSN to set up an A0 connection. Please note the step and may occur later based on the MS s registration request or based on BCMCS program schedule.. The BSN responds with BC Registration Reply.. The MS receives flow/program related information from the overhead messages. 0

131 GPP X.S00-A v.0 Add New Flow(s) The AddFlowRequest message is sent by the BCMCS Controller to the CS to request resource reservations at the CS for BCMCS Flow(s). The content is sent to the BSN using CS-BCMCS Bearer Protocol. A successful AddFlowRequest scenario in which the BCMCS Controller provisions a flow at the CS is shown in figure below. BSN SAAA/BCMCS Controller Content Server time FlowInformation (IP Address, Port, QoS etc. ) () FlowInformationResponse () AddFlowRequest (FlowHandle, IP Address, Port, QoS etc. ) () Signaling AddFlowResponse (SUCCESS) () Content flow either via MR or unicast () 0 0 Figure A - Success Add Flow Scenario. The CS sends a FlowInformation message to the BCMCS Controller including the flow information regarding BCMCS Flow(s) such as schedule, QoS parameters, etc.. The BCMCS Controller responds with the FlowInformationResponse message as an acknowledgement.. The BCMCS Controller sends an AddFlowRequest message defining parameters of the BCMCS Flow(s), such as schedule, QoS parameters, etc. The BCMCS Controller includes the BCMCS Flow Handle(s) that the CS can use to reference this BCMCS Flow reservation.. The CS sends an AddFlowResponse message accepting the BCMCS Flow reservation. Upon receiving AddFlowResponse with SUCCESS indication, the SAAA/BCMCS Controller sends CoA-Request to the BSN as specified in Figure A -.. The CS starts sending the content for the BCMCS Flow(s) at the start time of the BCMCS Flow(s) to the MR (if the content tunnel protocol being used is IP multicast) or the BSN (if the content tunnel protocol being used is L tunnel).

132 GPP X.S00-A v.0 Modify Existing Flow(s) The ModifyFlowRequest message is sent by the BCMCS Controller to the CS to modify start and end times of BCMCS Flow(s) that was initially created through an AddFlowRequest message. The use of the ModifyFlowRequest message by the BCMCS Controller to successfully extend the end time of a BCMCS Flow in progress is illustrated in figure below. BSN SAAA/BCMCS Controller Content Server time Content flow for FlowHandle(s) () ModifyFlowRequest ( Flow Handle(s), extended end time ) () Signaling ModifyFlowResponse ( SUCCESS, FlowHandle(s) ) () 0 Figure A - Successful Modify Flow Scenario. There is an existing BCMCS Flow for which the CS is sending content IP datagrams to the BSN.. The BCMCS Controller sends a ModifyFlowRequest message to the CS with the new end time for the BCMCS Flow Identified by BCMCS Flow Handle.. The CS sends a ModifyFlowResponse message to indicate that the ModifyFlowRequest was successful. Upon receiving ModifyFlowResponse with SUCCESS indication, the SAAA/BCMCS Controller sends CoA-Request to the BSN as specified in Figure A -. The BCMCS Controller may change parameters such as start time and/or end time using the ModifyFlow message. However, certain changes in BCMCS Flow configuration can only be accomplished through removing a BCMCS Flow and adding a new BCMCS Flow with the new parameters. 0

133 GPP X.S00-A v.0 Remove Existing Flow(s) The RemoveFlowRequest message is sent by the BCMCS Controller to the CS to remove the reservation for an existing BCMCS Flow. The successful removal of a BCMCS Flow in progress is illustrated in the figure below. BSN SAAA/BCMCS Controller Content Server time Content flow for FlowHandle(s) () RemoveFlowRequest (Flow Handle(s)) () Signaling BSN stops processing content for BCMCS flow () RemoveFlowResponse (SUCCESS, FlowHandle(s)) () 0 Figure A - Successful Remove Flow Scenario. The CS is sending content to the BSN on an existing BCMCS Flow Identified by a BCMCS Flow Handle.. The BCMCS Controller sends a RemoveFlowRequest message that specifies the BCMCS Flow Handle to the CS.. The BCMCS Controller sends a RADIUS Disconnect message to the BSN. The BSN stops processing content for the BCMCS Flow identified in RemoveFlowRequest message.. The CS sends a RemoveFlowResponse message to the BCMCS Controller indicating successful removal of the BCMCS Flow.

134 GPP X.S00-A v Annex B: Sample XML Output (Informative) B. BCMCS Information Acquisition Request <?xml version=".0" encoding="utf-"?> <BCMCS Ver=".0" xmlns="xmlns:gpp=" xmlns:xsi=" <Request> <NAI>user@domain.com</NAI> <PgmInfo> <RequestType> <RequestTypeVal>All</RequestTypeVal> </RequestType> <BAKReq>CurrentBAK</BAKReq> <ReqInfo> <PgmName>GPP News Cast</PgmName> </ReqInfo> </PgmInfo> <TimeStamp></TimeStamp> <ReqSysInfo> <SystemInfo> <SID></SID> <NID></NID> <PZID></PZID> </SystemInfo> </ReqSysInfo> </Request> </BCMCS> B. BCMCS Information Acquisition Response <?xml version=".0" encoding="utf-"?> <BCMCS Ver=".0" xmlns:gpp=" xmlns:xsi=" <Response> <BCMCSInfo> <PgmInfo> <FlowIDInfo> <FlowID>00</FlowID> <IPPort> <IPAddress> <IPv>...</IPv> </IPAddress> <Port>0</Port> </IPPort> </FlowIDInfo> <FlowIDInfo> <FlowID>00</FlowID> <IPPort> <IPAddress> <IPv>...</IPv> </IPAddress> <Port></Port> </IPPort> </FlowIDInfo>

135 GPP X.S00-A v <AppInfo> <SDP> v=0 o=alice 0 0 IN IP host.atlanta.example.com s=gpp News Cast c=in IP... t= 0 m=audio 0 RTP/AVP a=rtpmap: PCMA/000 m=video RTP/AVP a=rtpmap: H/0000 </SDP> </AppInfo> <LinkInfo> <EncType>UpperLayer</EncType> </LinkInfo> <SecInfo> <TK_RAND>00</TK_RAND> <SecFlowInfo> <FlowID>00</FlowID> <BAK_ID></BAK_ID> <EncrBAK>0</EncrBAK> <BAKExpTime>00-0-T:0:00-0:00</BAKExpTime> <AuthReq>true</AuthReq> </SecFlowInfo> <SecFlowInfo> <FlowID>00</FlowID> <BAK_ID></BAK_ID> <EncrBAK>0</EncrBAK> <BAKExpTime>00-0-T:0:00-0:00</BAKExpTime> <AuthReq>true</AuthReq> </SecFlowInfo> </SecInfo> </PgmInfo> </BCMCSInfo> </Response> </BCMCS> B. BCMCS Information Acquisition Reject <?xml version=".0" encoding="utf-"?> <BCMCS Ver=".0" xmlns:gpp=" xmlns:xsi=" <Reject> <RejReason></RejReason> <ReasonString>Requested program is not available</reasonstring> </Reject> </BCMCS>

136 GPP X.S00-A v.0 Annex C: XML Data Structure (Normative) C. Overall Structure C. Request Figure C- XML Overall Structure 0 Figure C- XML Data Structure: Request

137 GPP X.S00-A v.0 Figure C- XML Data Structure: PgmInfo under Request 0 Figure C- XML Data Structure: ReqSysInfo under Request

138 GPP X.S00-A v.0 C. Response Figure C- XML Data Structure: Response Figure C- XML Data Structure: GenInfo under Response and BCMCSInfo