ATIS 0800053-2012 Test Cases for IMS-based Content on Demand Service Attachment and Service Use.pdf

1、 ATIS-0800053 TEST CASES FOR IMS-BASED CONTENT ON DEMAND SERVICE ATTACHMENT AND SERVICE USE ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications indust

2、ry. More than 200 companies actively formulate standards in ATIS Committees and Forums, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emergin

3、g Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Connected Vehicle, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the

4、 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Inst

5、itute (ANSI). For more information, please visit . Notice of Disclaimer therefore, a network configuration diagram is detailed at the beginning of each scenario under test. 4 Scenario 3: Content on Demand Service Attachment reg-name specified in section 3.2.2 of RFC 3986 5. Example C5 URIs: http:/ ;

6、for create, delete and get functions http:/ list function 3. C6 download request. Table 2: HTTP Method for C6 Function Name Method Request Message Information Status Code Response Message Information download GET URI: C6 Asset Preparation Functions URI provided in the C5 create request message body.

7、 200 OK 302 redirect 404 not found Link Header: Media Resource Metadata URI Body: requested content NOTE Status codes also include failure responses for convenience. 4. C1 create request. ATIS-0800053 7 Table 3: HTTP Methods for C1 Function Name Method Request Message Information Status Code Respons

8、e Message Information create PUT Path: ATIS-IIF-Assets/OriginContentId Body: Distribution Policy 201 created 202 accepted The C1 URI is specified as follows: C1URI = C1scheme “:/“ DCF-host “/“ “ATIS-IIF-Assets“ (“/“ OriginContentId / “?“ C1query ) C1scheme = “http“ / “https“ C1query = ”max=” 1* “ re

9、g-name specified in section 3.2.2 of RFC 3986 5. Example C1 URIs: http:/ ;for create, delete and get functions. http:/ list functionA3 list request. 5. A3 list response. 6. A3 get request. 7. A3 get response. The A3 URI is specified as follows: A3URI = A3scheme “:/“ APF-host “/“ “ATIS-IIF-Assets“ “/

10、“ CreatorAssetId “?“ A3query A3scheme = “http“ / “https“ A3query = query ; query specified in section 3.4 of RFC 3986 5. APF-host = reg-name ; reg-name specified in section 3.2.2 of RFC 3986 5. Example A3 URIs: http:/ ; for list function. http:/ ; for get function. Table 4: HTTP Request and Response

11、 Methods for A3 Function Name Method Request Message Information Status Code Response Message Information list GET Path: ATIS-IIF-Assets 200 OK Body: list of A3 URIs get GET Path: ATIS-IIF-Assets/CreatorAssetId (A3 URI) 200 OK 404 not found Body: metadata (including asset encryption elements) NOTE S

12、tatus codes include failure responses for convenience. 8. A6 get request. ATIS-0800053 8 4.1.1.9 Known Issues None. 4.1.2 Test Case 3a1.2: Content Distribution and Storage after a Cache Miss The next applicable option (option C, Real Time Unicast Retrieval after Cache Miss, as described in ATIS-0800

13、042 14) represents a real-time delivery of content from the Content Origin Function to the Content Delivery and Storage Functions (CD reg-name specified in section 3.2.2 of RFC 3986 5. path-absolute is specified in section 3.3 of RFC 3986 5. Example Origin URIs: http:/ http:/ The OriginContentId, us

14、ed to refer to an asset can be translated into an Origin URI by prepending the http scheme to the OriginContentId. The CD query specified in section 3.4 of RFC 3986 5. IPTV-SCF-host = reg-name ; reg-name specified in section 3.2.2 of RFC 3986 5. The path component of an E1 URI is a specific instance

15、 of a path as defined in section 3.3 of RFC 3986 5 and is composed of the OriginContentId. Example E1 URI: http:/iptv- 4.2.1.8 Known Issues Authentication details have not been specified by the ATIS IIF and therefore will not be included in the CoD Test Cases. ATIS-0800053 16 4.3 Scenario 3c: CoD Se

16、ssion Management 4.3.1 Test Case 3c1 IMS COD Session Establishment In this case, an IMS session setup request (SIP message over the E3 interface) is sent by the ITF to establish a session between the Session Client function and the Core IMS. The media is delivered over RTP (via the Ud interface) and

17、 the control is achieved via RTSP. 4.3.1.1 Test Setup See Figure 1 for an overview of the CoD sequence and Figure 8 for an overview of the CoD functional architecture. Note that IMS-based session management as shown in phase 4 of Figure 1 is used for the CoD session establishment/maintenance sequenc

18、e. The steps include a CoD SIP session, RTSP control session, and CoD media session. The Core IMS elements (Figure 8) of the Service Control Functions are utilized by the Session Client Function of the ITF for CoD SIP session establishment. NGN Service Stratum FunctionsService Control FunctionsConte

19、nt Distribution & Delivery FunctionsEnd- User FunctionsIPTV Terminal FunctionsNGN Transport Stratum FunctionsTransportFunctionsContent Delivery & Storage FunctionsApplication FunctionsHome Network FunctionsAccess NetworkFunctionsEdge FunctionsE7Content Distribution & Location Control FunctionsDistri

20、bution Control FunctionLocation Control FunctionD1R*Core TransportFunctionsContent Receiving FunctionContent Delivery Control FunctionUdContent DeliveryFunctionSCPA Client FunctionsControl FunctionsH3CoD ApplicationFunctionE1Unicast Transport FunctionsResource & Admission Control Functions (RACF)Con

21、tent Delivery Client FunctionCoD Application Client FunctionDelivery NetworkGateway FunctionCore IMSService User Profile F unctionE3iS6IPTV Control FunctionsSession ClientFunctionI- CSCFS- CSCF P- CSCFS2S3S1S5E6IPTV ServiceControl FunctionCo D ServiceControl FunctionS7C4A8Application User Profile Fu

22、nctionFigure 8: ATIS IIF IPTV CoD Architecture 4.3.1.2 Resource Required The following components are required for this scenario: ATIS-0800053 17 ITF Clients. DNG. Transport Functions. Core IMS IPTV Control Function. CD&DF (CD&LCF + CD&SF). CoD IPTV Application Function. The following components are

23、 optional for this scenario: Resource and Admission Control Function (RACF) (optional). S-User Profile (optional). 4.3.1.3 Test Pre-conditions Network attachment per ATIS-0800017 10. Remote configuration per ATIS-0800009 7. SP discovery per ATIS-0800017 10. SP attachment per ATIS-0800017 10. Service

24、s discovery per ATIS-0800017 10. Asset preparation per ATIS-0800042 14. EPG metadata distributed to the Application Function per ATIS-0800020 11 and ATIS-0800017 10. Content Selection and authorization per ATIS-0800042 14. Content distribution per ATIS-0800042 14. 4.3.1.4 Procedure See Figure 1 for

25、an overview of the CoD sequence and Figure 9 for the message exchange sequence. 4.3.1.5 Observable Results It shall be observed that IMS CoD session establishment-related messages can be exchanged (between the ITF and IMS core) seamlessly. 4.3.1.6 Pass/Fail criteria 1. Verify the SIP INVITE request/

26、response between the ITF and the IMS Core Network (P-CSCF) via E3. 2. Verify the SIP INVITE request/response between the IMS Core Network (S-CSCF) and the IPTV CF via S7. 3. Verify that the RTSP Setup request/response between IPTV CF and CD&SF via S5 are as listed in section 4.3.2.7. 4. Verify that

27、all message flows in section 4.3.2.7 follow required syntax as listed in section 4.3.2.7 (per ATIS-0800042 14). 5. Verify that the message flow completion in the E6 Play request results in media flow via the Ud reference point. ATIS-0800053 18 4.3.1.7 Message Flow Figure 9: IMS CoD Session Establish

28、ment and Management 1. The CoD Service is triggered through user interaction, preset recording instructions, or other means. 2. The ITF initiates a SIP session by sending a SIP INVITE to the Proxy-Call Session Control Function (P-CSCF) (E3). The INVITE includes the OriginContentId provided by the Co

29、D Application Function when the content was selected. 3. The P-CSCF initiates a resource reservation request (reservation phase) to the RACF based on the bandwidth requested in the incoming INVITE. The RACF allocates the default initial bandwidth (S3). 4. The RACF signals that the bandwidth allocati

30、on is complete to the P-CSCF (S3). 5. The P-CSCF forwards the INVITE to the S-CSCF. 6. The S-CSCF verifies the users entitlement from the S-User Profile (S2) (optional). 7. The S-User Profile provides subscription information and determines the IPTV Control Functions to which the user has subscribed

31、. If the subscriber is not entitled to IPTV services, the S-CSCF rejects the SIP session request (optional). 8. The S-CSCF forwards the INVITE to the IPTV Control Functions (S7). 9. The IPTV Control Functions request the users S-User Profile if not available (S6) (optional). 10. The S-User Profile r

32、eturns the profile data which the IPTV Control Functions use to validate the service connection (S6) (optional). 11. The IPTV Control Functions request the subscribers authorization for delivery of the asset (A8 authorization request). 12. If the subscriber is authorized, the Application Function re

33、turns the allocated session bandwidth and, optionally, content protection information (e.g., ECM) and NPT value (A8 authorization response). 13. The IPTV Control Functions request the location of a server within the CD&SF for content delivery from the CD&LCF (S1 locate request). 14. The CD&LCF retur

34、n the location of the chosen server (CD&SF host) within the CD&SF to the IPTV Control Functions (S1 locate response). 15. The IPTV Control Functions send an RTSP SETUP to the specified server location in the CD&SF (S5 setup request). IMS Core NetworkP-CSCFS-CSCF ITF ClientsCoD ApplicationRACFIPTVCon

35、trolCD&SFS-User ProfileTransportFunctionDNGCD&LCF21 SIP 200 OK1 ServiceTrigger2 SIP INVITE17 SIP 200 OK3 ResourceControl Req.4 Response5 SIP INVITE8 SIP INVITE18 SIP 200 OK22 ACK24 ACK19 ResourceControl Request20 Response25 Dialog EstablishedInitial Unicast Admission Control28 Media flow9 CheckProfi

36、le10 ReturnResult26 RTSP PLAYContent Selection and Acquisition, see section 6.213 LocateServer14 ReturnLocation23 ACK15 RTSP SETUP16 RTSP 200 OK27 RTSP 200 OKFinal Unicast Admission Control11 Check Application User Profile12 Return ResultInitiate Content Retrieval on Cache Miss per Figure 7 Scenario

37、 c7 ReturnResult6 Verify EntitlementATIS-0800053 19 16. The CD&SF establishes the RTSP session and returns an RTSP 200 OK to the IPTV Control Functions, including the RTSP MediaSessionId (S5 setup response). 17. The IPTV Control Functions return SIP 200 OK to the S-CSCF to acknowledge the INVITE, in

38、cluding the RTSP MediaSessionId and the location of the server within the CD&SF (S7). 18. The S-CSCF returns SIP 200 OK to the P-CSCF, including the RTSP MediaSessionId and the location of the server within the CD&SF. 19. The P-CSCF initiates a resource reservation request (commitment phase) to the

39、RACF based on the bandwidth for the requested CoD Service stream (S3). The RACF allocates the required bandwidth for the service. 20. The RACF signals that the bandwidth allocation is complete to the P-CSCF (S3). 21. The P-CSCF returns SIP 200 OK to the ITF, including the RTSP MediaSessionId and the

40、 location of the server within the CD&SF (E3). 22. The ITF sends an ACK to the P-CSCF (E3). 23. The P-CSCF sends an ACK to the S-CSCF. 24. The S-CSCF sends an ACK to the IPTV Control Functions. 25. The SIP dialog is now established between the ITF and the IPTV Control Functions. 26. The ITF sends an

41、 RTSP PLAY for the signaled RTSP MediaSessionId to the location of the server within the CD&SF (E6 play request). 27. The CD&SF starts media playback within the RTSP session and returns RTSP 200 OK to the ITF (E6 play response). 28. The media is now flowing to the ITF (Ud). 4.3.1.8 Trace Capture The

42、 main focus of this test case is the interaction between the ITF Clients and the Core IMS (P-CSCF). The traces of the messages exchanged on the E3 interfaces should be captured during the testing and validated against the test case descriptions. 1. SIP INVITE request. 2. Session Description Protocol

43、 (SDP) offered in INVITE request. ATIS-0800053 20 Table 7: IMS SDP Normative Fields and Values for E3 SDP Description Explanation v= protocol version 0 As specified in ATIS-0800013 8, section 16. s= session name “ATIS IIF CoD Service” Identifies the session as being compliant to the ATIS IIF specifi

44、cations for CoD Service. i= session description Populated with the well-known PSI for CoD Service, including the OriginContentId. The Public Service Identifier (PSI) identifies that the session is a CoD service. t= time the session is active Typically set to “0 0”. The t= type is usually defined as

45、unbounded (“0 0”). m= media descriptions This field is mandatory and defines the media information for the RTSP control channel which uses TCP or TCP/TLS as per RFC 4145 15. The field is set to application. The value is set to the value 9, which is a discard port since the actual port that can recei

46、ve the RTSP command is set dynamically and will be the one to be used by the peer. The field is set to TCP or TCP/TLS. The parameter is set to IIF-iptv-rtsp. a= attributes setup:active As per RFC 4145 15. a = attributes Connection: new As per RFC 4145 15. c= connection data IN (IP4 orIP6 set appropr

47、iately) IN is defined by IANA as Internet. IP4 or IP6 refers to whether IP protocol version 4 or 6 is being used for the supplied connection address and is set accordingly. The connection address is the IP address of the RTSP content control stream. a= attributes fmtp There may be one or more of the

48、 lines that represent RTSP-specific attributes (e.g., RTSP version). a=fmtp:iptv_rtsp version ATIS-0800053 21 SDP Description Explanation m= Additional media description entries Mandatory m= line that defines the video media. This line is constructed from the metadata associated with selected content by the user. The field is set to video. The value is set to the IP po