msf2011.007.01
MultiService Forum
Contribution Number: msf2011.007.01
Last Saved: 03/08/2016 2:03 AM
Title: Scenarios for ATIS IIF-MSF IPTV Interoperability Testing
Editor: Randy Sharpe
Alcatel-Lucent
randy.sharpe@alcatel-lucent.com
Abstract:
This document describes a set of physical scenarios to test the interoperability between key components
of the ATIS IIF IPTV architecture. The interfaces to be tested are specified (in terms of references to
the appropriate ATIS IIF specifications) within this document such that additional implementation
agreements for the individual interfaces may not need to be created. The tests cases are described at a
high level, more detailed test plans will be created from these.
By submitting this contribution, the representative(s) of the source company(ies) acknowledge reading
and agrees to the MSF IPR Policy Statement.
The MultiService Forum (MSF) is responsible for developing Implementation Agreements or
Architectural Frameworks which can be used by developers and network operators to ensure
interoperability between components from different vendors. MSF Implementation Agreements are
formally ratified via a Straw Ballot and then a Principal Member Ballot.
Draft MSF Implementation Agreements or Architectural Framework may be published before formal
ratification via Straw or Principal Member Ballot. In order for this to take place, the MSF Technical
Committee must formally agree that a draft Implementation Agreement or Architectural Framework
should be progressed through the balloting process. A Draft MSF Implementation Agreement or
Architectural Framework is given a document number in the same manner as an Implementation
Agreement.
Draft Implementation Agreements may be revised before or during the full balloting process. The
revised document is allocated a new major or minor number and is published. The original Draft
Implementation Agreement or Architectural Framework remains published until the Technical
Committee votes to withdraw it.
After being ratified by a Principal Member Ballot, the Draft Implementation Agreement or
Architectural Framework becomes final. Earlier Draft Implementation Agreements or Architectural
Frameworks remain published until the Technical Committee votes to withdraw them.
Page 1 of 35
msf2011.007.01
DISCLAIMER
The information in this publication is believed to be accurate as of its publication date. Such
information is subject to change without notice and the MultiService Forum is not responsible for any
errors or omissions. The MultiService Forum does not assume any responsibility to update or correct
any information in this publication. Notwithstanding anything to the contrary, neither the MultiService
Forum nor the publisher make any representation or warranty, expressed or implied, concerning the
completeness, accuracy, or applicability of any information contained in this publication. No liability of
any kind whether based on theories of tort, contract, strict liability or otherwise, shall be assumed or
incurred by the MultiService Forum, its member companies, or the publisher as a result of reliance or
use by any party upon any information contained in this publication. All liability for any implied or
express warranty of merchantability or fitness for a particular purpose is hereby disclaimed.
The receipt or any use of this document or its contents does not in any way create by implication or
otherwise:
Any express or implied license or right to or under any MultiService Forum member
company’s patent, copyright, trademark or trade secret rights which are or may be associated
with the ideas, techniques, concepts or expressions contained herein; nor
Any warranty or representation that any MultiService Forum member companies will
announce any product(s) and/or service(s) related thereto, or if such announcements are made,
that such announced product(s) and/or service(s) embody any or all of the ideas, technologies,
or concepts contained herein; nor
Any commitment by a MultiService Forum company to purchase or otherwise procure any
product(s) and/or service(s) that embody any or all of the ideas, technologies, or concepts
contained herein; nor
Any form of relationship between any MultiService Forum member companies and the
recipient or user of this document.
Implementation or use of specific MultiService Forum Implementation Agreements, Architectural
Frameworks or recommendations and MultiService Forum specifications will be voluntary, and no
company shall agree or be obliged to implement them by virtue of participation in the MultiService
Forum.
For addition information contact:
MultiService Forum
48377 Fremont Blvd., Suite 117, Fremont, CA 94538
(510) 492-4050
(510) 492-4001 (fax)
info@msforum.org
www.msforum.org
© MultiService Forum 2010 (or current year)
Page 2 of 35
msf2011.007.01
MULTISERVICE FORUM ................................................................................................................... 1
1
INTRODUCTION .......................................................................................................................... 5
1.1
TEST SCENARIOS ..................................................................................................................... 12
2
TESTING SCENARIO 1 – NETWORK ATTACHMENT, SERVICE PROVIDER
DISCOVERY AND SELECTION, SERVICES DISCOVERY ........................................................ 12
2.1
PHYSICAL SCENARIO ............................................................................................................... 13
2.2
NETWORK COMPONENTS ......................................................................................................... 14
2.2.1
Scenario 1a: DNG Network Attachment ......................................................................... 14
2.2.2
Scenario 1b: ITF Network Attachment ........................................................................... 14
2.2.3
Scenario 1c: Non-IMS Service Provider Discovery and Attachment ............................. 14
2.2.4
Scenario 1d IMS-based Service Provider Discovery and Attachment ............................ 15
2.2.5
Scenario 1e Services Discovery ...................................................................................... 15
2.3
PROTOCOLS AND REFERENCE POINTS...................................................................................... 15
2.4
TEST CASES ............................................................................................................................. 16
2.4.1
Scenario 1a: DNG Network Attachment ......................................................................... 16
2.4.2
Scenario 1b: ITF Network Attachment ........................................................................... 16
2.4.3
Scenario 1c: Non-IMS Service Provider Discovery and Attachment ............................. 17
2.4.4
Scenario 1d: IMS-based Service Provider Discovery and Attachment ........................... 18
2.4.5
Scenario 1e: Services Discovery and Selection .............................................................. 18
3
SCENARIO 2 – LINEAR TV SERVICE SELECTION, ATTACHMENT & SERVICE USE
18
3.1
PHYSICAL SCENARIO ............................................................................................................... 18
3.2
NETWORK COMPONENTS ......................................................................................................... 19
3.2.1
Scenario 2a – IMS-based Linear TV Service .................................................................. 19
3.2.2
Scenario 2b – Non-IMS-based Linear TV Service .......................................................... 19
3.3
PROTOCOLS AND REFERENCE POINTS...................................................................................... 20
3.4
TEST CASES ............................................................................................................................. 20
3.4.1 Scenario 2a: IMS-based Linear TV Service......................................................................... 21
3.4.2 Scenario 2b: Non-IMS-based Linear TV Service ................................................................. 21
4
SCENARIO 3 – CONTENT ON DEMAND SERVICE ATTACHMENT & SERVICE USE
21
4.1
PHYSICAL SCENARIO ............................................................................................................... 21
4.2
NETWORK COMPONENTS ......................................................................................................... 22
4.2.1
Scenario 3a: Content Acquisition, Preparation and Distribution .................................. 22
4.2.2
Scenario 3b: Content Discovery and Selection............................................................... 22
4.2.3
Scenario 3c: CoD Session Management ......................................................................... 22
4.2.4
Scenario 3d: Content Delivery and Control ......................Error! Bookmark not defined.
4.3
PROTOCOLS AND REFERENCE POINTS...................................................................................... 23
4.4
TEST CASES ............................................................................................................................. 23
4.4.1
Scenario 3a: Asset Acquisition, Preparation, and Distribution..................................... 24
4.4.2
Scenario 3b: ITF Authentication, Content Selection and Acquisition ............................ 24
4.4.3
Scenario 3c: Session Management ................................................................................ 24
4.4.4
Scenario 3d: Content Delivery and Control ......................Error! Bookmark not defined.
5
SCENARIO 4 – REMOTE MANAGEMENT OF CONSUMER DOMAIN DEVICES AND
QOS METRIC REPORTING ............................................................................................................. 24
5.1
PHYSICAL SCENARIO ............................................................................................................... 24
5.2
NETWORK COMPONENTS ......................................................................................................... 25
5.2.1
Scenario 4a – Software Download Management ............................................................ 25
5.2.2
Scenario 4b – Remote Device Management: Configuration and Provisioning .............. 26
5.2.3
Scenario 4c – Remote Device Monitoring ...................................................................... 26
5.2.4 Scenario 4d – IPTV Monitoring and Testing ........................................................................ 26
5.3
PROTOCOLS AND REFERENCE POINTS...................................................................................... 26
5.4
TEST CASES ............................................................................................................................. 26
5.4.1
Scenario 4a: Software Download Management ............................................................. 27
Page 3 of 35
msf2011.007.01
5.4.2
5.4.3
5.4.4
6
Scenario 4b: Remote Device Management ..................................................................... 28
Scenario 4c: Remote Device Monitoring ........................................................................ 28
Scenario 4d: IPTV Monitoring and Testing.................................................................... 28
INTERFACE SPECIFICATIONS .............................................................................................. 28
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
6.27
6.28
6.29
6.30
6.31
6.32
6.33
6.34
6.35
6.36
6.37
A0 (SP&SDF–CORE IMS) ...................................................................................................... 28
A3 (APF - COD AF) ................................................................................................................ 29
A4 (SP&SDF - AUP) .............................................................................................................. 29
A7 (CONTENT SOURCE - APF) ................................................................................................ 29
A8 (COD AF - IPTV CF) ......................................................................................................... 29
C1 (CONTENT ORIGIN FUNCTION - CD&LCF) ........................................................................ 29
C2 (CONTENT ORIGIN FUNCTION - CD&SF CONTENT RECEIVING FUNCTION) ....................... 29
C5 (ASSET PREPARATION FUNCTION – CONTENT ORIGIN FUNCTION)..................................... 29
C6 (ASSET PREPARATION FUNCTION – CONTENT ORIGIN FUNCTION)..................................... 30
D1 (CD&LCF - CD&SF) ........................................................................................................ 30
E0 (ITF AND SD&SDF) .......................................................................................................... 30
E1 (ITF– IPTV AF) ................................................................................................................. 30
E3I (ITF - CORE IMS) ............................................................................................................. 30
E3N (ITF - IPTV CF)............................................................................................................... 30
E5 ( ITF - DNG – TRANSPORT FUNCTIONS) ............................................................................ 30
E6 (ITF CONTENT DELIVERY CLIENT FUNCTION - CD&SF) ................................................... 31
H1 (DNG - ARF) .................................................................................................................... 31
H4 (DNG - RCMS) ................................................................................................................. 31
H5 (ITF - ARF) ....................................................................................................................... 31
H6 (ITF – RCMS) ................................................................................................................... 31
H7 (SDS-DNG)....................................................................................................................... 31
H8 (SDS-ITF) ......................................................................................................................... 32
H9 (SDS-ITF) ......................................................................................................................... 32
H10 (SDS-DNG)..................................................................................................................... 32
MD ( TRANSPORT FUNCTIONS – DNG - ITF) ........................................................................... 32
RU (NACF- RACF)................................................................................................................. 32
R* (RACF – TRANSPORT FUNCTIONS) .................................................................................... 32
S1 (IPTV CF - CD&LCF) ....................................................................................................... 32
S2 (CORE IMS – SUP)............................................................................................................. 32
S3 (CORE IMS/IPTV CF - RACF) ........................................................................................... 32
S4 (CORE IMS/IPTV CF – NACF) .......................................................................................... 33
S5 (IPTV CF - CD&SF) .......................................................................................................... 33
S6 (IPTV CF - SUP) ................................................................................................................ 33
S7 (CORE IMS - IPTV CF) ...................................................................................................... 33
T1 (NACF - ARF) ................................................................................................................... 33
T2 (RCMS-SDS)..................................................................................................................... 33
UD (CD&SF - UNICAST TRANSPORT FUNCTIONS) .................................................................. 33
Page 4 of 35
msf2011.007.01
1
Introduction
The ATIS IIF IPTV functional architecture is specified in ATIS-0800007, IPTV High Level
Architecture [2]. It is based on an NGN framework with a separation of services from transport. Two
approaches are specified; one using a specialized IPTV service control function and second approach
that adds core IMS to the service control. The IMS and non-IMS approaches use common functional
elements, interfaces, and metadata where possible. This facilitates the coexistence of non-IMS and
IMS-based IPTV service in the same network, and the migration from non-IMS to IMS-based IPTV
with minimal obsolescence. The ATIS IIF functional architecture is well aligned with the ITU-T IPTV
functional architecture as specified in Y.1910 [16].
The ATIS IIF IPTV High Level Architecture is shown in Figure 1. The functions and interconnections
in black are common to the IMS and non-IMS approaches. Functions and interconnections in green
apply only to non-IMS IPTV networks. Functions and interconnections in red apply only to IMS-based
IPTV networks.
It’s important to recognize that a network may offer non-IMS IPTV service but still use IMS for other
services such as voice services. A network may use non-IMS IPTV service for some customers such as
those that received IPTV service prior to core IMS being deployed, and use IMS-based IPTV service
for customers with an expanded service offering, located in a different serving area, or mobile service.
Coexistence of IMS and non-IMS IPTV service and architectural evolution are important
considerations in ATIS IIF.
Figure 1: ATIS IIF IPTV High Level Architecture
Notes:
1) Boxes with black outlines and black interconnections: common for non-IMS and IMS based IPTV
service.
2) Boxes with green outlines and green interconnections: only apply to non-IMS IPTV service.
3) Boxes with red outlines and red interconnections: only apply to IMS based IPTV service.
4) The blue line is the media path
Page 5 of 35
msf2011.007.01
Building on the IPTV High Level Architecture, the ATIS IIF has produced several documents focused
on particular aspects of the IPTV service such as network and service attachment and other documents
focused on particular services such as Linear TV and Content on Demand services.
Figure 2 shows the architecture that will be used for the ATIS IIF-MSF IOT based on the Linear TV
functional architecture in ATIS-0800018, IPTV Linear TV Service [10] and ATIS-0800042, IPTV
Content on Demand Service [15] The reference point designations used by the ATIS IIF align with
those used by the ITU-T in Y.1910.
Application Functions
E1 (XML)
A3
C5
A4
E0
A7
Asset Preparation
IPTV Application
AUP
SP&S Disc. Functions
C6
Content Origin
C1
A8
C2
A0
S2
ITF
P-CSC
CD&LC
S6
Core IMS
E3i
SUP
S1
S7
S-CSC
D1
IPTV CF
I-CSC
CD&SF
S5
E3n
S3
S4
E6
H4
H9, H10
H5
DNG
H6
CD&DF
S4
H7, H8
S3
NACF
RCMS
Ru
AAA
RACF
T2
SDS
T1
R*
Ud
H1
ARF
Transport Functions
Ud, Md, E5
Md
Transport & Access Networks
Key
Video
Headend
Not in scope at this time
In scope
Figure 2: ATIS IIF IPTV Functional Architecture
The main components of the architecture are described below.

ITF (IPTV Terminal Function). The ITF is responsible for collecting control commands
from end-users and interacting with the application functions to obtain service information
(e.g., EPG), content licenses, and keys for decryption. The ITF interacts with the service
control and content delivery functions to receive the IPTV services and also provide the
capability for content reception, decryption, and decoding.

DNG (Delivery Network Gateway). The DNG provides connectivity between the external
network and the ITF. It acts as a DHCP client to the NACF and a DHCP server to ITFs.

Transport Functions. The transport functions provide IP layer connectivity between content
delivery functions and end user functions. This includes multicast replication and the
processing of requests for membership in multicast groups. The transport functions include
access, edge, and core transport functions as well as the Access Relay Function (ARF).

NACF (Network Attachment Control Functions). The Network Attachment Control
Function authenticates and assigns IP addresses to DNGs and ITFs. It also provides remote
management and configuration of these devices. The NACF includes a DHCP Server
providing AAA functionality and a Remote Configuration and Management Server (RCMS)
for remote management and configuration of CPE devices.
Page 6 of 35
msf2011.007.01

Software Download Server (SDS). The Software Download Server is a logical entity
containing all the components required for a software download service. It is possible for all
the components in the server to be physically co-located. It is used for new software and
updates to previously-installed software in a DNG or ITF.

RACF (Resource & Admission Control Functions). The Resource and Admission Control
Functions (RACF) provides control of the resources which have been allocated for the
delivery of IPTV services through the access, and edge transport networks.

Core IMS. Core IMS provides SIP session control and SIP message forwarding for
interactions between ITFs and IPTV applications functions and content delivery functions.
The Core IMS supports service discovery as well as the authentication and authorization of
ITFs based on the service user profile.

Service User Profile (SUP). Each Service User Profile may contain:
 user service subscription data (i.e., IPTV services subscribed to)
 subscriber related data (e.g., who pays the incurred charges)
 user location data
 user presence status (e.g., online/offline)
 user profiles for:
o authentication;
o authorization;
o subscriber mobility;
o location;
o presence.

IPTV CF (IPTV Control Function). The IPTV Control Functions are the set of functions to
request and release the network and system resources needed to support the required
application functionality. The IPTV CF may validate the requests against the service user
profile. The IPTV CF provides signal interworking such that the control interface to the
content delivery system is the same for IMS-based and non-IMS IPTV networks.

CD&DF (Content Distribution and Delivery Function). The Content Distribution and
Delivery Functions include the Content Distribution and Location Control Functions
(CD&LCF) along with the Content Delivery and Storage Functions (CD&SF). New content
available for distribution is communicated to the CD&LCF by the content origin function.
Included in this communication is information required to derive the Origin URI for a content
asset from the subscriber URI. The CD&LCF controls the distribution of available content by
either providing explicit instructions to the CD&SF to initiate transfer of the available content
(push model) or providing content origin location information when requested by the CD&SF
(pull model).

Service Provider and Services Discovery Functions. The Service Provider and Services
Discovery functions support several methods to discover service providers, attach to service
provider servers, and discover IPTV services. The SP&S Discovery function provides ITFs
with IPTV services information including EPG.

Application User Profile. The IPTV Application User Profile may include:
 End-user settings including information related to the capabilities of the end-user.
o Subscription terms and conditions
o Parental control level
o Bandwidth limit
 Global settings
o Language preference
 User preferences based on CoD metadata (favorites):
Page 7 of 35
msf2011.007.01



o Genre
o Artist
o Format (B/W, HD, SD, etc.)
o Rating
Information related to the actions the user may have taken while accessing services, e.g.,:
o Bookmarks of paused CoD;
o CoD orders and associated status;
o CoD assets that the user has asked to be recorded.
Preference for other services:
o Linear TV settings;
o Linear TV service packages subscribed to;
o PVR (personal video recorder) settings (PVR preferences network/local, PVR user
restrictions, PVR storage limit).
Subscriber’s ITF device capabilities

IPTV Applications. The IPTV application performs application authorization and execution
of IPTV service logic based on the Application User Profile. Linear TV and Content on
Demand are IPTV applications. The Linear TV application provides an Electronic Program
Guide (EPG) to ITFs for the browsing and selection of Linear TV content. The Content on
Demand application allows the ITF to select and purchase content.

Asset Preparation Function. CoD content is delivered (over A7) in the form of a package
which contains content files and metadata describing each content file included in the
package. The Asset Preparation Function prepares the content and generates the content
metadata.

1.
The Asset Preparation Function announces the availability of the content and its
associated content origin URI to the Content Origin Function (C5).
2.
The Asset Preparation Function publishes the asset metadata to the CoD Application
Function (A3).
3.
CoD metadata is generated and kept updated by the CoD Application function.
Content Origin Function. The Content Origin Function stores content that was created by
the Asset Preparation Function and makes it available to CD&SFs. Two types of Content
Origin Functions have been defined. A Base Content Origin Function is an Origin Server as
specified in IETF RFC 2616 [23] and is appropriate for non-real time prepositioning and best
effort real-time delivery of content to CD&SFs. An Extended Content Origin Function
augments the Base Content Origin Function with two HTTP extensions. The first extends the
HTTP range request to include time ranges based on the W3C Media Fragments URI
specification. The second extension provides a scheduled transmission service where the
delivery of content is paced according to request parameters.
The main interfaces of the architecture are described below.

A0. The A0 reference point between the SP&S Discovery function and Core IMS is used for
service discovery on IMS-based IPTV networks. This reference point is used to provide
authorized ITFs service data URIs to obtain IPTV service information such as the EPG.

A3. The A3 reference point is between the Asset Preparation Functions and the CoD
Application Function. This reference point is used to forward content related metadata created
and stored in the Asset Preparation Functions to the CoD Application Function. The following
functions are provided:
o create a new asset entry
o get the metadata associated with an existing asset entry
Page 8 of 35
msf2011.007.01
o
o
o
get a list of asset entries
update the metadata associated with an existing asset entry
delete an asset entry

A4. The A4 reference point is between the SP&S Discovery function and the IPTV
application’s AUP to provide IPTV application related user profile information to the SP&SD.

A7. The A7 reference point is between the Content Source and the Asset Preparation
Function. This reference point is used to ingest content and related metadata into the service
provider’s system. The following functions are provided:
o create a new asset entry
o get the metadata associated with an existing asset entry
o get a list of asset entries
o replace the metadata for an asset entry
o replace or add content to an asset entry
o delete an asset entry

A8. The A8 reference point is between the CoD Application Functions and the IPTV Control
Functions. This reference point is used for forwarding service signaling information (e.g.,
authorization information) between the IPTV CoD Application Function and the IPTV
Control Functions.

C1. The C1 reference point is between the Content Origin Function and the CD&LCF. This
reference point is used by the Content Origin Function to notify the CD&LCF of relevant
information associated with one or more content assets. This data includes information
required to derive the Origin URI for a content asset from the Subscriber URI and may also
include a distribution policy (e.g., whether a content asset needs to be prepositioned).

C2. The C2 reference point is between the Content Origin Function and the Content
Receiving Function within the CD&SF. This reference point is used by the Content Receiving
Function to retrieve content from the Content Origin Function.

C5. The C5 reference point is between the Asset Preparation Functions and the Content
Origin Function. The reference point is used by the Asset Preparation Functions to notify the
Content Origin Function of the availability of content asset and its associated content origin
URI.

C6. The C6 reference point is between the CD&LCF and the CD&SF. This reference point is
used by the Content Origin Function to retrieve content from the Asset Preparation Functions.

D1. The D1 reference point is between the CD&LCF and the CD&SF. This reference point is
used to convey content origin information from the CD&LCF to the CD&SF, as well as for
the CD&SF to report status information (e.g., load status, list of stored content identifiers) to
the CD&LCF.

E0. The E0 reference point is between the ITF and SD&S Discovery Function. This
reference point is used to discover and select IPTV services and applications.

E1. The E1 reference point is between the ITF CoD Application Client Function and the CoD
Application Function. This reference point is used by the ITF to browse, search, select and,
where applicable, purchase content using the services of the CoD Application Function. The
EPG including the CoD catalogue elements is specified in ATIS-0800020, IPTV EPG
Metadata Specification [12].

E3i. For IMS-based IPTV networks the E3i reference point between the ITF and Core IMS is
used to initiate a Linear TV SIP session upon attachment to the Linear TV service, change
network resources used by the Linear TV SIP session, and to tear down the Linear TV SIP
session when terminating the service. This reference point is also used to establish, modify
and terminate SIP sessions for CoD service including the content identifier of the requested
Page 9 of 35
msf2011.007.01
content and can optionally be used for exchanging service and application discovery
information. This reference point corresponds to the IMS-based IPTV E3 interface in ITU-T
Y.1910 [16] which corresponds to the Gm reference point defined in ITU-T Y.2021 [18],
clause 11.4.3.

E3n. For non-IMS IPTV networks, the E3n reference point between the ITF and IPTV
Control Function is used to exchange session signalling information, which includes the
content identifier of the requested content. E3n is not required for basic Linear TV service. E3
may be used for non-IMS based Linear TV with trick play modes and for network resource
allocation decoupled from the application layer. This reference point corresponds to the nonIMS based IPTV E3 reference point in ITU-T Y.1910 [16], clause 11.3.2.

E5. The E5 reference point is used to change from one Virtual Channel Service Stream (also
known as a Linear TV channel) to another. ITFs send messages to multicast tree nodes, such
as the DNG and access network equipment, to leave and join channels. This reference point
corresponds to the E5 reference point in ITU-T Y.1910 [16].

E6 . The E6 reference point is between the ITF Content Delivery Client Function and the
CD&SF. This reference point is used to exchange content control signalling information (e.g.,
play, pause, fast forward, rewind, download) between the ITF and the CD&SF. This reference
point corresponds to the E6 reference point in ITU-T Y.1910 [16].

H1. The H1 reference point between the DNG and the Access Node’s Access Relay Function
is used to perform authentication and is used by the DNG to obtain necessary information (e.g.
IP address, etc.) from the NACF when the DNG attaches to the network.

H4. The H4 reference point between the DNG and the Remote Configuration and
Management Server is used to download DNG software, manage the DNG, and monitor
network performance.

H5. The H5 reference point between the ITF and the Access Node’s Access Relay Function is
used to perform authentication and is used by the ITF to obtain necessary information (e.g. IP
address, etc.) from the NACF when the ITF attaches to the network.

H6. The H6 reference point between the ITF and the Remote Configuration and Management
Server is used to download ITF software, manage the ITF, and monitor network performance.

H7. The H7 reference point between the SDS and the DNG is used for multicast delivery of
software to the DNG. This reference point corresponds to the e1 interface described in ATIS0800009, Remote Management of Devices in the Consumer Domain [4], that is based on ETSI
TS 102 824 [29] reference point 5.

H8. The H8 reference point between the SDS and the DNG is used for unicast delivery of
Software to the DNG. This reference point corresponds to the f1 interface described in ATIS0800009 [4] that is based on ETSI TS 102 824 [29] reference point 6.

H9. The H9 reference point between the SDS and the ITF is used for multicast delivery of
Software to the ITF. This reference point corresponds to the e1 interface described in ATIS0800009 [4] that is based on ETSI TS 102 824 [29] reference point 5.

H10. The H10 reference point between the SDS and the ITF is used for unicast delivery of
software to the ITF. This reference point corresponds to the f2 interface described in ATIS0800009 [4] that is based on ETSI TS 102 824 [29] reference point 6.

Md. The Md reference point is used to deliver multicast media streams to ITFs. Md may
optionally support packet loss recovery. Two alternatives may be used; one based on an
application layer FEC and the other on RTP retransmission.
Page 10 of 35
msf2011.007.01

Ru. The Ru reference point between the NACF and RACF allows the RACF to interact with
the NACF for checking on CPE transport subscription profile information and the binding
information of the logical/physical port address to an assigned IP address.

R*. R* represents all reference points between RACF and transport functions. This includes
the ITU-T reference points Rc, Rn, Rp, and Rw, depending on the resource management
implementation.

S1. The S1 reference point is between the IPTV Control Function and the Location Control
Function within the CD&LCF. This reference point is used by the IPTV Control Function to
locate one or more instances of the CD&SF capable of delivering the requested content to the
ITF. The S1 reference point corresponds to the non-IMS S1 reference point in ITU-T Y.1910
[16]. S1 uses HTTP as specified in ATIS-0800013 [5], Media Formants and Protocols
Specification, with S1 specific usage specified in ATIS-0800042, IPTV Content on Demand
Service [15].

S2. The S2 reference point between Core IMS and SUP is used to store and retrieve service
user profile information.

S3. The S3 reference point is between the service control functions and RACF. In IMS-based
networks S3 terminates on Core IMS, and in non-IMS IPTV networks S3 terminates on the
IPTV Control Function. The service control functions use S3 to request RACF to control
transport resources. This corresponds to the Rs reference point in ITU-T Y.2111 [19].

S4. The S4 reference point is between the service control functions and NACF. In IMS-based
networks S4 terminates on Core IMS and in non-IMS IPTV networks S4 terminates on the
IPTV Control Function. The service control functions use S4 to retrieve information related
to the IP connectivity (e.g. physical location of the ITF). This corresponds to the S-TC1
reference point in ITU-T Y.2014 [17].

S5 The S5 reference point is between the IPTV Control Function and the CD&SF. This
reference point is used to exchange session management information between the IPTV
Control Function and the CD&SF. The S5 reference point corresponds to the non-IMS S5
reference point in ITU-T Y.1910 [16]. S5 uses RTSP as specified in ATIS-0800013, Media
Formats and Protocols Specification [5], with S5 specific usage specified in ATIS-0800042,
IPTV Contend on Demand Service [15].

S6. The S6 reference point between the IPTV Control Function and SUP is used to store and
retrieve service user profile information.

S7 The S7 reference point between Core IMS and the IPTV Control Function is used to
forward CoD session description information to the IPTV CF.

T1. The T1 reference point between the NACF and the Access Node’s Access Relay Function
is used to perform authentication and for the DNG and ITF to obtain necessary information
(e.g. IP address, etc.) from the NACF when they attach to the network.

T2. The T2 reference point between the SDS and the RCMS is used for signaling and
metadata between RCMS and the software download manager to notify the RCMS of software
availability for the ITF and DNG. This reference point corresponds to the d interface described
in ATIS-0800009, Remote Management of Devices in the Consumer Domain [4], that is based
on ETSI TS 102 824 [29] reference point 4.

Ud. The Ud reference point is between the CD&SF and the Unicast Transport Functions.
This reference point is used by the CD&SF to deliver content streams in unicast mode.
Page 11 of 35
msf2011.007.01
1.1 Test Scenarios
This document describes four test scenarios that will be used to exercise interoperability of the key
interfaces of the ATIS IIF IPTV architecture, these being:
Scenario 1: Network Attachment, Service Provider Discovery and Attachment, Services
Discovery.
Scenario 1a: DNG Attachment
Scenario 1b: ITF Attachment
Scenario 1c: Non-IMS Service Provider Discovery and Attachment
Scenario 1d: IMS-based Service Provider Discovery and Attachment
Scenario 1e: Services Discovery
Scenario 2: Linear TV Service Attachment and Service Use.
Scenario 2a: IMS-based Linear TV Service
Scenario 2b: Non-IMS Linear TV Service
Scenario 3: Content on Demand Service Attachment and Service Use.
Scenario 3a: Content Acquisition, Preparation and Distribution
Scenario 3b: Content Discovery and Selection
Scenario 3c: Session Management
Scenario 4: Remote Management of Consumer Domain Devices and QoS Metric Reporting.
Scenario 4a: Software Download Management
Scenario 4b: Remote Device Management
Scenario 4c: Remote Device Monitoring
Scenario 4d: IPTV Monitoring and Testing
2 Testing Scenario 1 – Network Attachment, Service
Provider Discovery and Selection, Services
Discovery
These scenarios detail the initial set of activities that prepare devices in the consumer domain to receive
and consume IPTV services. This section addresses the initialization and attachment phases for the
Delivery Network Gateway (DNG) and the IPTV Terminal Function (ITF), covering network
attachment, service provider discovery, service provider attachment, and services discovery procedures.
DNG network attachment refers to the activities associated with the DNG establishing Layer 3
connectivity to an IP network. Once the network attachment activities have been completed, the DNG
will be capable of transmitting and receiving IP packets and establishing a management session with an
RCMS. Subsequently, the RCMS is used to provision the DNG with access-network specific
parameters. ATIS IIF uses DHCP as a mechanism for network attachment. Using this protocol, the
DNG acquires its WAN IP address and can also learn the address of the RCMS.
After the DNG attaches to the network the ITF follows at path from top to bottom through the
following figure to attach to the network, discover service providers, attach to service providers and
query specific servers, and discover services. For each phase in the process there are several alternative
methods. The outcome of each method is the same.
Page 12 of 35
msf2011.007.01
Phase/Outcome
Method / Procedure
1-Network Attachment
Network Attachment via DHCP Procedure
The ITF gets its IP address
and the IP address of the
RCMS, performs remote
configuration procedure,
and attaches to the network
2-Service Provider Discovery
The ITF learns the means
for attaching to a Service
Provider
Per ATIS-0800009
Remote Management of Devices in the
Consumer Domain for IPTV Services
Remote Configuration Procedure
For Non-IMS Services
Using preconfigured
information
3-Attach to SP and Query
Specific Servers
The ITF attaches to a
Service Provider and
queries specific servers
Via DHCP
Container
Option
Via
TFTP
Via BBF
TR-069
Via known
multicast
stream
IMS registration
and authentication
No action required when
SP equals NP
Optional discovery of “Service
Discovery Application Server”
Authentication and Authorization
Provided through
authentication
response
For IMS Services based
on DHCP Option 120
Web Services
based
transactions
Attachment via SIP
Notification Package(s)
4-Services Discovery and
Selection
The ITF gets services data
such as EPG and SI
Multicast Push
WS Pull
SIP Notification
Package(s)
5-Service Attachment and
Operation
Service Specific Method
Not in scope of this
specification document
Figure 3: Phases of ITF Device Attachment & Initialization Sequence
2.1 Physical Scenario
The architecture for the network attachment service provider discovery and attachment and services
discovery and selection test cases is shown in the figure below.
Page 13 of 35
msf2011.007.01
Application Functions
E1 (XML)
IPTV Application
A4
E0
AUP
SP&S Disc. Functions
A0
S2
SUP
Core IMS
E3i
S-CSC
ITF
P-CSC
I-CSC
S4
H4
H6
RCMS
DNG
NACF
H5
AAA
T1
H1
ARF
Md, E5
Transport Functions
Md
Transport & Access Networks
Key
Video
Headend
Not in scope at this time
In scope
Figure 4: Scenario 1 Physical Architecture
2.2 Network Components
2.2.1 Scenario 1a: DNG Network Attachment
The following components are required for this scenario.




One Transport Network Elements (Access Node, Edge Router)
One AAA (DHCP) server
One DNS server
One DNG
2.2.2 Scenario 1b: ITF Network Attachment
The following components are required for this scenario.





One Transport Network Elements (Access Node, Edge Router)
One AAA (DHCP) server
One DNS server
One DNG
One ITF
2.2.3 Scenario 1c: Non-IMS Service Provider Discovery and Attachment
The following components are required for this scenario.

One Transport Network Elements (Access Node, Edge Router)
Page 14 of 35
msf2011.007.01








One AAA (DHCP) server
One DNS server
One DNG
One ITF
One RCMS
One source of multicast atis-iif-service-locator.xml file
One IPTV Application Server include authentication server function
One Client Authentication Server
2.2.4 Scenario 1d IMS-based Service Provider Discovery and
Attachment
The following components are required for this scenario.










One Transport Network Elements (Access Node, Edge Router)
One AAA (DHCP) server
One DNS server
One DNG
One ITF
One Core IMS
One Service Discovery Application Server
One IPTV Application Server (EPG, SI)
One GBA Server
One Authentication Proxy
2.2.5 Scenario 1e Services Discovery
The following components are required for this scenario.






One Transport Network Elements (Access Node, Edge Router)
One AAA (DHCP) Server
One DNS Server
One DNG
One ITF
One IPTV Application Server (EPG, SI)
2.3 Protocols and Reference Points
The following reference points will be included in this scenario.
Interface
H1
T1
H5
H6
Md
E5
E0
E3i
S4
A0
E1
Protocol
DHCP
DHCP
DHCP
CWMP (TR-069), DVB TS 102 034
RTP, MPEG2 TS
IGMPv3
HTTP 1.1
SIP (Gm)
DIAMETER
ISC
HTTP 1.1
Page 15 of 35
Sub Scenario
1a
1a, 1b
1b
1c
1c
1c, 1e
1c, 1d
1d
1d
1d
1e
msf2011.007.01
2.4 Test Cases
2.4.1 Scenario 1a: DNG Network Attachment
DNG network attachment refers to the activities associated with the DNG establishing Layer 3
connectivity to an IP network. Once the network attachment activities have been completed, the DNG
will be capable of transmitting and receiving IP packets and establishing a management session with an
RCMS. Subsequently, the RCMS is used to provision the DNG with access-network specific
parameters.
The test cases in this section are to verify the protocol usage, processes, and message content for DNG
network attachment. DNG network attachment may be considered as 4 steps:




Establish layer 1 and layer connectivity (out of scope)
Issue a DHCP DISCOVER message.
Receive a DHCP OFFER providing
o DNG IP address and network mask
o DNS and default gateway IP addresses
o Information from which the IP address of the RCMS is determined
DHCP protocol sequence is completed.
Test cases:
1.
DNG attaches to the network and establishes connectivity with the RCMS after being offered
the IP address of RCMS.
2.
DNG attaches to the network and establishes connectivity with the RCMS after being offered
the RCMS FQDN.
3.
DNG attaches to the network and establishes connectivity with the RCMS after being offered
neither RCMS IP address nor FQDN.
2.4.2 Scenario 1b: ITF Network Attachment
ITF device network attachment refers to activities associated with the ITF device establishing Layer 3
connectivity to an IP network and obtaining network configuration information data. Once the network
attachment activities have been completed, the ITF will be capable of transmitting and receiving IP
packets and establishing a management session with an RCMS.
The test cases in this scenario verify the protocol usage, processes, and message content for ITF
network attachment. ITF network attachment may be considered as a 4 step sequence:
1.
2.
3.
4.
Establish layer 1 and layer connectivity with the DNG (out of scope)
Issue a DHCP DISCOVER message.
Receive a DHCP OFFER providing
a. ITF IP address and network mask
b. DNS, default gateway, and RCMS IP addresses
DHCP protocol sequence is completed
Test cases:
1.
The ITF attaches to the DNG and establishes connectivity with the RCMS.
Page 16 of 35
msf2011.007.01
2.4.3 Scenario 1c: Non-IMS Service Provider Discovery and Attachment
Service Provider Discovery is the process by which an ITF becomes aware of the available IPTV
Service Provider(s), and learns the means of attaching to a Service Provider.
The list of one or more Service Provider(s) available to the subscriber is offered by the Network
Provider (NP). The information will be represented in the manner appropriate for each service
discovery method.
Six Service Provider Discovery methods are defined in ATIS-0800017 [9]– five for non-IMS IPTV
networks and one for IMS-based IPTV networks. The discovery methods differ in the number of steps
to be performed by an ITF to obtain the Service Provider’s information. A method can obtain the
Service Provider discovery information directly in a single step or indirectly by first obtaining a pointer
to the information and then obtaining the information.
Each method concludes with the ITF obtaining the following information for each service provider :






Name (optional) – may be multi-lingual.
Unique ID (optional).
Description (optional) – may be multi-lingual.
Logo (optional).
Authentication service location (optional).
Attachment service location (required) – in at least one of the following forms:
o HTTP or HTTPS URI
o





SIP URI (for IMS-based attachment).
Thin client portal URL (optional).
STUN server (optional).
Remote Configuration and Management Server (optional) .
Software download location (optional).
Version number of SP information (optional).
Test cases:
1.
2.
3.
4.
Service Provider discovery using preconfigured or manual methods
Service Provider discovery using the download method from the Network Provider Domain
Service Provider discovery using TR-069 [28] CWMP-based method
Service Provider discovery using streaming of the Service Provider’s information to a
multicast address method
Once the ITF device has discovered the available Service Providers and selected a Service Provider, the
next activity is Service Provider (SP) authentication and attachment. The end result of SP
authentication and attachment is that the ITF device has obtained two types of information:
A. Credentials allowing access to SP information and services.
B. Provisioning information:









Location of the Master SI Table (required).
Set of all services available to the ITF device, independent of entitlement (optional).
Set of all services to which ITF device is subscribed/entitled (required).
Location of Emergency Alert System (EAS) stream (optional).
Location(s) of EPG data (optional).
Thin client portal URL (optional).
STUN information (optional).
Location of the RCMS (optional).
Location(s) where software downloads are available (optional).
Page 17 of 35
msf2011.007.01


Authentication service location, if not provided in Service Provider Info Table
(optional).
ITF device location code (optional).The information retrieved at this stage is
typically not secured.
Test cases, continued:
5.
ITF attachment to a Service Provider through authentication.
6.
ITF attachment to a Service Provider using a pull mechanism.
2.4.4 Scenario 1d: IMS-based Service Provider Discovery and
Attachment
IMS-based networks advertise the use of SIP by using DHCP Option 120 during the network
attachment phase. Option 120 provides the ITF with the identity of the P-CSCF through which it
connects to the IMS registrar and allows the ITF to utilize IMS registration and attachment to discover
an IPTV Service Provider. It is assumed that the IPTV Service Provider is also the IMS Service
Provider so IPTV Service Provider discovery is not needed. The ITF locates a Service Discovery
Application Server and attaches to the server using the SIP Notification Framework.
At the end of IMS-based Service Provider discovery and attachment the ITF will have obtained the
same information listed in scenario 1c.
Test cases:
1.
ITF registers with IMS.
2.
ITF is authenticated using the generic bootstrap procedure.
3.
ITF locates Service Discovery Application Server (contained within the SP&S Discovery
Function):
4.
a.
Preconfigured in ITF.
b.
Using DNS SRV lookup.
ITF attaches to a Service Provider using SIP Notification Framework.
2.4.5 Scenario 1e: Services Discovery and Selection
Services Discovery is the process by which an ITF receives the necessary data elements which enable
the ITF to access the available IPTV services. The main data elements are EPG and Services
Information.
Test cases:
1.
Services discovery and selection using a multicast-based push mechanism.
2.
Services discovery and selection using a unicast-based pull mechanism.
3.
Service discovery and selection using the SIP Notification Framework.
3 Scenario 2 – Linear TV Service Selection,
Attachment & Service Use
3.1
Physical Scenario
Page 18 of 35
msf2011.007.01
This section includes two test scenarios of the Linear TV functionality as specified in ATIS-0800018
IPTV Linear TV Service [10].
 Scenario 2a: IMS-based Linear TV
 Scenario 2b: Non-IMS-based Linear TV
The content of this section is based on ATIS-0800018, IPTV Linear TV Service [10]. It is assumed that
the functions described and verified in Scenario 1 are executed prior to attempting any Scenario 2 test
cases.
The architecture for this scenario is shown in the figure below.
Application Functions
E1 (XML)
IPTV Application
AUP
A8
S2
S6
Core IMS
E3i
ITF
P-CSC
SUP
S7
S-CSC
IPTV CF
I-CSC
S3
S4
S4
RCMS
NACF
S3
Ru
RACF
DNG
AAA
R*
ARF
Md, E5
Transport Functions
Md
Transport & Access Networks
Key
Not in scope at this time
In scope
Figure 5: Architecture for Scenario 2
3.2 Network Components
3.2.1 Scenario 2a – IMS-based Linear TV Service





One Transport Network Elements (Access Node, Edge Router)
One Core IMS (P- and S-CSCFs at a minimum)
One DNG (optional)
One ITF
One Video Headend (or suitable multicasting server)
3.2.2 Scenario 2b – Non-IMS-based Linear TV Service



One Transport Network Elements (Access Node, Edge Router)
One IPTV Control entity
One DNG (optional)
Page 19 of 35
Video
Headend
msf2011.007.01


One ITF
One Video Headend (or suitable multicasting server)
3.3 Protocols and Reference Points
The following reference points will be included in this scenario.
Interface
A8
E1
E3i
E3n
E5
Md
S3
Protocol
Unspecified (Y.1910 A1)
HTTP 1.1
SIP
Unspecified (Y.1910, 11.3.2 E3)
IGMPv2, IGMPv3
MPEG2TS, RTP
Unspecified (Y.2111 Rs)
Sub Scenarios
2a, 2b?
2a
2a
2b
2a, 2b
2a, 2b
2a, 2b
3.4 Test Cases
The following figure from ATIS-0800018 [10] shows the phases of a Linear TV service. A Linear TV
service is executed following a path from the top to the bottom of the figure. The outcome of each
phase is described in the left column.
As preconditions for a Linear TV service the ITF and DNG have attached to the network, been
authenticated and configured, Service Providers have been discovered and attached to, and a Linear TV
service has been discovered.
For more information, refer to the sections of ATIS-0800018 [10] identified in the figure.
Phase/Outcome
Method / Procedure
0- Pre-conditions
•
•
These steps occur prior to the start of the
LTV service, and leave the ITF with specific
operational state, as described in section 6 of
this document.
Per ATIS0800009
Remote Configuration
Per ATIS0800017
SP Discovery
SP Attachment
These steps are covered in other ATIS
documents.
1- LTV Service Selection/Attachment, Session
Setup, and Initial Resource Acquisition
•
•
Network Attachment
Services Discovery
Static
Non-IMS
Dynamic
Coupled
I MS
Decoupled
Selection of the LTV service
Linear TV session established and, in IMS,
of LTV SIP session
Static
(Section 7.1)
• Resources allocated
2a •- M
IniotdiailficchaatinonneltoacLqTuV
ireSdession Resources
Mod.
Modification of LTV Application session and,
in IMS, of LTV SIP session resources prior to
channel change
2b - Channel Change
Channel changes handled by the transport layer
Coupled
(Section 7.2)
No Mod.
Coupled
(Section 9.1)
Static
Resources
(Section 8.1)
Decoupled
(Section A.2)
IMS
(Section 7.3)
Mod.
Mod.
No Mod.
Decoupled
(Section A.3)
IMS
(Section 9.2)
Channel Change common to IMS and non-IMS
1.
Static Resources (Section 8.1)
2.
Adjustable Resources (Section 8.2)
3.
Fully Shared Resources (Section 8.3)
3- LTV Service Termination
Coupled
(Section 10.1)
Release Network Resources
Page 20 of 35
Decoupled
(Section A.4)
IMS
(Section 10.2)
msf2011.007.01
Figure 6: Software Download Sequence
3.4.1 Scenario 2a: IMS-based Linear TV Service
IMS-based Linear TV Service is intended to provide a similar experience to existing broadcast, satellite
or cable TV services, utilizing an IMS core routing structure as the main path for control messaging
while leveraging multicast to make the content streams available to multiple users simultaneously.
Test cases:
1.
Service Attachment and Initial Channel Acquisition
2.
Channel Change without Resource Modification
3.
Channel Change with Resource Modification
4.
Service Termination
3.4.2 Scenario 2b: Non-IMS-based Linear TV Service
Non-IMS-based Linear TV Service is intended to provide a similar experience to existing broadcast,
satellite or cable TV services, utilizing a standard IPv4-based network as the main path for control
messaging while leveraging multicast to make the content streams available to multiple users
simultaneously.
Test cases:
1.
Service Attachment and Initial Channel Acquisition
2.
Channel Change without Resource Modification
3.
Channel Change requiring Resource Modification
4.
Service Termination
4 Scenario 3 – Content on Demand Service
Attachment & Service Use
4.1 Physical Scenario
This section includes four test scenarios of the Content on Demand Service functionality as specified in
ATIS-0800042 IPTV Content on Demand Service [15].
 Scenario 3a: Content Acquisition, Preparation and Distribution
 Scenario 3b: Content Discovery and Selection
 Scenario 3c: CoD Session Management
It is assumed that the functions described and verified in Scenario 1 are executed prior to attempting
any Scenario 3 test cases. The architecture for this scenario is shown in the figure below.
Page 21 of 35
msf2011.007.01
Application Functions
E1 (XML)
A3
A7
Asset Preparation
IPTV Application
C5
AUP
C1
A8
SUP
S2
E3i
ITF
P-CSC
S1
S7
S-CSC
D1
IPTV CF
I-CSC
S5
E3n
C2
CD&LC
S6
Core IMS
C6
Content Origin
S3
CD&SF
CD&DF
S3
E6
DNG
RACF
R*
Transport Functions
Ud
Transport & Access Networks
Key
Not in scope at this time
In scope
Figure 7: Overview of CoD Architecture
4.2 Network Components
4.2.1 Scenario 3a: Content Acquisition, Preparation and Distribution
The following components are required for this scenario:





Asset Preparation Function
Content Origin Function
Application Function
SCPA
CD&LCF
4.2.2 Scenario 3b: Content Discovery and Selection
The following components are required for this scenario:



ITF
CoD Client Application Function
CoD Application Function
4.2.3 Scenario 3c: CoD Session Management
The following components are required for this scenario:






ITF Clients
DNG
Transport Functions
RACF
Core IMS
S-User Profile
Page 22 of 35
msf2011.007.01




IPTV Control Function
CD&LCF
CD&SF
CoD IPTV Application Function
4.3 Protocols and Reference Points
The following reference points will be included in this scenario.
Interface
Protocols and References
A8
C1
C2
E1
E3i
E3n
E6
S1
S5
S6
S7
Ud
HTTP 1.1/HTTPS
HTTP 1.1 / HTTPS
HTTP 1.1 / HTTPS MPEG 2 TS, NPT, SCTE35, SNPT
HTTP 1.1 / HTTPS
HTTP 1.1, RTSP, SDP, SIP
HTTP 1.1, RTSP
RTSP, HTTP 1.1/HTTPS
HTTP 1.1/HTTPS
RTSP, NPT, HTTP
DIAMETER
SIP
RTP, HTTP, MPEG 2 TS
Test Case,
Subcase
3c
3a
3a, 3d
3b
3c
3c
3c
3c
3c
3c
3c
3c
4.4 Test Cases
The following figure provides an overview of the phases of CoD service. Asset preparation is an
ongoing process that occurs autonomously from the consumption of CoD service. As preconditions to
CoD service the following steps have taken place:




Network Attachment per ATIS-0800017 [9]
Remote Configuration per ATIS-0800009 [4]
SP Discovery per ATIS-0800017 [9]
SP Attachment per ATIS-0800017 [9]
After the preconditions are satisfied, the CoD service phases are executed. CoD service execution can
be described as following a path from content discovery and selection, through one of several
alternatives for CoD session management and one of several alternatives of content delivery and
control.
Page 23 of 35
msf2011.007.01
Phase
Method / Procedure
Outcome
• MPEG2 TS Continuous
Media
• Media Resource Metadata
• MPEG2 TS Index Data
Asset
Assetacquisition,
acquisition,preparation,
preparation,and
anddistribution
distribution
1- Asset Preparation
Network
NetworkAttachment
Attachment
Remote
RemoteConfiguration
Configuration
2- Pre-conditions
Per
ATIS-0800017
SP
SPDiscovery
Discovery
Per
• Device IP addr
ATIS-0800009 • RCMS IP addr
• SP list
• Services list
SP
SPAttachment
Attachment
Services
ServicesDiscovery
Discovery
3- Content Discovery
and Selection
• E1 URI
Content
Contentdiscovery,
discovery,content
contentselection,
selection,and
andauthorization
authorization
IMS Session (Dynamic)
Non-IMS
4- Session Management
• Session Signaling
• User Authorization
• CD&SF Location
• Server Resource Allocation
• Network Resource Allocation
• Set-up and tear-down
Static
Via
ViaHTTP
HTTP
Via
ViaRTSP
RTSP
Dynamic
RTSP Redirect
• SessionId
• CD&SF URI
Via
ViaHTTP
HTTP
Via
ViaRTSP
RTSP
Via
ViaSIP
SIP
Resource Management
5- Content Delivery and
Control
RTSP Proxy
• ControlSessionId
• MediaSessionId
• CD&SF URI
Delivery
Deliveryand
andcontrol
controlvia
viaHTTP
HTTP
Delivery
Deliveryvia
viaRTP
RTPand
andcontrol
controlvia
viaRTSP
RTSP
Real-time
Real-time(no
(nopersistence)
persistence)
Pull
PullDownload
Download
Progressive
ProgressiveView
View
HTTP
• SessionId
IMS
• CoD SIP Session
• RTSP Control Session
• CoD Media Session
Delayed
DelayedView
View
Figure 8: Overview of CoD Sequence
4.4.1 Scenario 3a: Asset Acquisition, Preparation, and Distribution
1.
2.
Asset Preparation and Distribution
Content Distribution and Storage after a Cache Miss
4.4.2 Scenario 3b: ITF Authentication, Content Selection and
Acquisition
1.
2.
Content Selection and Acquisition
Authorization Aspects of Content Selection
4.4.3 Scenario 3c: Session Management
1.
2.
3.
4.
5.
Non-IMS Proxy CoD Session Establishment – RTSP
Non-IMS Proxy CoD Session Termination – RTSP
Non-IMS Proxy CD&SF Initiated Session Termination – RTSP
Non-IMS Proxy CoD Service Control Initiated Session Termination – RTSP
Non-IMS Redirect CoD Session Establishment – RTSP
5 Scenario 4 – Remote Management of Consumer
Domain Devices and QoS Metric Reporting
5.1
Physical Scenario
This scenario tests four aspects of the remote management and QoS metric reporting functionalities as
specified in ATIS-0800009,Remote Management of Devices in the Consumer Domain [4]; ATIS-
Page 24 of 35
msf2011.007.01
0800008 QoS Metrics for Linear Broadcast IPTV [3]; ATIS-0800004, A Framework for QoS Metrics
and Measurements supporting IPTV Services [1]; and ATIS-0800041, Implementer’s Guide to QoS
Metrics[14].




Scenario 4a
Scenario 4b:
Scenario 4c:
Scenario 4d:
Software Download Management
Remote Device Management
Remote Device Monitoring
IPTV Monitoring and Testing
The architecture for this scenario is shown in the figure below.
Figure 9: Architecture for Scenario 4
Note: Whether the SDS and the RCMS will reside within the same equipment will depend on the
equipment available in the IOT.
5.2 Network Components
5.2.1 Scenario 4a – Software Download Management





One RCMS (Remote Configuration and Management Server)
One SDS (Software Download Server)
One DNG
One ITF
One mobile device
Page 25 of 35
msf2011.007.01
5.2.2 Scenario 4b – Remote Device Management: Configuration and
Provisioning




One RCMS (Remote Configuration and Management Server)
One DNG
One ITF
One mobile device
5.2.3 Scenario 4c – Remote Device Monitoring



One RCMS (Remote Configuration and Management Server)
One DNG
One ITF
5.2.4 Scenario 4d – IPTV Monitoring and Testing






One test device
One data collection device that can record metrics reported by the test device
One DNG
One ITF and remote control
One IPTV Application Server
One video server
5.3 Protocols and Reference Points
Interface
H7 (e1)
H9 (e2)
H8 (f1)
H10 (f2)
H8 (f1)
H10 (f2)
H4 (i1)
H6 (i2)
T2
Protocol
IGMPv3, FLUTE (per DVB)
IGMPv2/v3, FLUTE (per DVB)
HTTP(S) (required), (S)FTP (optional), TFTP (optional)
HTTP(S) (required), (S)FTP (optional), TFTP (optional)
OMA-DM FUMO
OMA-DM FUMO
CWMP (TR-069)
CWMP (TR-069)
Not specified
5.4 Test Cases
Assumptions

ITF and DNG are initialized, authenticated, and operating in the network.
Page 26 of 35
Sub Scenarios
4a
4a
4a
4a
4a
4a
4b, 4c
4b, 4c
4a
msf2011.007.01
Figure 10: Software Download Sequence
5.4.1 Scenario 4a: Software Download Management
Test cases for software download management verify the protocol usage, processes, and content for
software download to the device. The software download sequence is shown in Fig. 2. Software to be
downloaded includes the following (according to ATIS-0800009 [4]):
 An executable (image) running on the device.
 Updates to certain modules of the executable.
 Applications/modules running on top of the basic executable image.
 Profile files for the customization of certain features and services on the managed device.
ATIS IIF requires that software is protected at time of download and future executions based on a code
signing mechanism defined in ATIS-0800014 [6] using keys corresponding to the Code Verification
Certificate (CVC) [7][8]]. For this physical scenario, it is assumed that the CVC be made available for
DNG or ITF to download. The ITF is able verify the signature and the corresponding CVC upon the
download and prior to installation.
If a signing mechanism is not available, the integrity of the software may be protected through a serverside authenticated TLS connection into the download server.
For this physical scenario, it is assumed that the SDS and ITF follow the encryption mechanisms
provided in ATIS-0800014 [6]
Test cases:
1.
Software download for mobile devices
2.
Software download for TR-069 devices – unicast download
3.
Software download for TR-069 devices – multicast download with unicast control
4.
Software download for TR-069 devices – multicast download with multicast control
Page 27 of 35
msf2011.007.01
5.4.2 Scenario 4b: Remote Device Management
These remote device management test cases verify that the device is initialized. While live video is
present on its display, the RCMS queries and receives confirmation of the device’s configuration
parameters.
Test cases:
1.
Configuration and Provisioning for OMA-Compliant Mobile Device
2.
Configuration and Provisioning for TR-069 Compliant DNG
3.
Configuration and Provisioning for TR-069 Compliant ITF
5.4.3 Scenario 4c: Remote Device Monitoring
Remote device monitoring for DNG and ITF allows service providers to assess the user’s quality of
experience, manage and diagnose network performance, determine device capabilities, and configure
devices. These test cases verify a subset of the information specified in ATIS-0800009. While live
video is present on its display, the RCMS queries and receives confirmation of the device’s
configuration parameters.
Test cases:
1. Fault Detection – Faulty AV or Audio Stream
2.
Fault Detection – Modify ITF Parameters
3.
Fault Correction – ITF Reboot
4.
Fault Correction – Factory Reset
5.
Audience Measurements
6.
IPTV Transmission, Media Stream, Content, and Transaction Metrics at the ITF
5.4.4 Scenario 4d: IPTV Monitoring and Testing
Remote device monitoring and testing allows service providers to assess the user’s quality of
experience, manage and diagnose network performance, and perform troubleshooting in response to
faults or customer complaints.
This test relies on receiving data from a “test device” which could be a network probe, test-head,
portable test-set, DNG, mobile device, router, ITF, etc. The parameters described in Table 2 of ATIS0800008 QoS Metrics for Linear IPTV [3], are considered in this test case. Not all devices can report all
of these metrics, so participants are encouraged to report as many of these metrics as they can.
Test case:
1.
IPTV Transmission, Media Stream, Content, and Transaction Metrics at Test or Monitoring
Device
6 Interface Specifications
The following is a set of references for the interfaces tested in these scenarios.
6.1 A0 (SP&SDF–Core IMS)
ATIS-0800017 [9], section 9.4 and Appendix G
ATIS-0800022 [13], section 9.2.3 and Annex A
Page 28 of 35
msf2011.007.01
IETF RFC 3261, SIP: Session Initiation Protocol [24]
IETF RFC 3265, Session Initiation Protocol (SIP) – Specific Event Notification [25]
6.2 A3 (APF - CoD AF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.2
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
6.3 A4 (SP&SDF - AUP)
Not specified.
6.4 A7 (Content Source - APF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.3
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
6.5 A8 (CoD AF - IPTV CF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.4
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
6.6 C1 (Content Origin Function - CD&LCF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.5
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
6.7 C2 (Content Origin Function - CD&SF Content Receiving
Function)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.6
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
6.8 C5 (Asset Preparation Function – Content Origin
Function)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.7
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
Page 29 of 35
msf2011.007.01
6.9 C6 (Asset Preparation Function – Content Origin
Function)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.8
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
6.10 D1 (CD&LCF - CD&SF)
Not specified.
6.11 E0 (ITF and SD&SDF)
ATIS-0800017 Network Attachment and Initialization of Devices and Client Discovery of IPTV
Services [9]
ATIS-0800022 IPTV Consumer Device Configuration Metadata [13]
6.12 E1 (ITF– IPTV AF)
ATIS-0800018 IPTV Linear TV Service [10]
ATIS-0800020 IPTV EPG Metadata Specification [12]
ATIS-0800022 IPTV Consumer Domain Device Configuration Metadata [13]
ATIS-0800042 IPTV Content on Demand Service [15]
6.13 E3i (ITF - Core IMS)
ATIS-0800018 IPTV Linear TV Service [10]
ATIS-0800042 IPTV Content on Demand Service [15], section 10.9
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
ITU-T Y.2021 IMS for Next Generation Networks [18] Section 8.2
ETSI TS 123 002 UMTS Network Architecture [30]
ETSI TS 123 228 UMTS IP Multimedia Subsystem (IMS) [31]
6.14 E3n (ITF - IPTV CF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.9
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2326 Real Time Streaming Protocol (RTSP) [22]
6.15 E5 ( ITF - DNG – Transport Functions)
ATIS-0800018 IPTV Linear TV Service [10]
ATIS-0800019 Multicast Network service Specification [11]
Page 30 of 35
msf2011.007.01
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2236 Internet Group Management Protocol Version 2 (IGMPv2) [21]
IETF RFC 3376 Internet Group Management Protocol Version 3 (IGMPv3) [26]
6.16 E6 (ITF Content Delivery Client Function - CD&SF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.10
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2326 Real Time Streaming Protocol (RTSP) [22]
6.17 H1 (DNG - ARF)
ATIS-0800017 Network Attachment and Initialization of Devices and Client Discovery of IPTV
Services [9]
IETF RFC 2131 Dynamic Host Configuration Protocol [20]
ITU-T Y.2014 Network Attachment Control Function [17] (TC-T1)
6.18 H4 (DNG - RCMS)
ATIS-0800017 Network Attachment and Initialization of Devices and Client Discovery of IPTV
Services [9]
ATIS-0800009 Remote Management of Devices in the Consumer Domain for IPTV Services [4]
BBF TR-069 CPE WAN Management Protocol [28]
6.19 H5 (ITF - ARF)
ATIS-0800017, Network Attachment and Initialization of Devices and Client Discovery of IPTV
Services
IETF RFC 2131 Dynamic Host Configuration Protocol [20]
ITU-T Y.2014 Network Attachment Control Function [17] (TC-T1)
6.20 H6 (ITF – RCMS)
ATIS-0800017 Network Attachment and Initialization of Devices and Client Discovery of IPTV
Services [9]
ATIS-0800009 Remote Management of Devices in the Consumer Domain for IPTV Services [4]
BBF TR-069 CPE WAN Management Protocol [28]
6.21 H7 (SDS-DNG)
ATIS-0800009.v002 Remote Management of Devices in the Consumer Domain for IPTV Services [4]
IETF RFC 3926 FLUTE – File Delivery over Unidirectional Transport [27]
ETSI TS 102 824 Remote Management and Firmware Update System for DVB IP Services
[29]
Page 31 of 35
msf2011.007.01
6.22 H8 (SDS-ITF)
ATIS-0800009.v002 Remote Management of Devices in the Consumer Domain for IPTV Services [4]
ETSI TS 102 824, Remote Management and Firmware Update System for DVB IP Services
6.23 H9 (SDS-ITF)
ATIS-0800009.v002 Remote Management of Devices in the Consumer Domain for IPTV Services [4]
IETF RFC 3926 FLUTE – File Delivery over Unidirectional Transport [27]
ETSI TS 102 824 Remote Management and Firmware Update System for DVB IP Services
[29]
6.24 H10 (SDS-DNG)
ATIS-0800009.v002 Remote Management of Devices in the Consumer Domain for IPTV Services [4]
ETSI TS 102 824 Remote Management and Firmware Update System for DVB IP Services [29]
6.25 Md ( Transport Functions – DNG - ITF)
ATIS-0800018 IPTV Linear TV Service [10]
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
6.26 Ru (NACF- RACF)
ITU-T Y.2014 Network Attachment Control Function [17]
ITU-T Y.2111 Resource and Admission Control Function [19] (Ru)
6.27 R* (RACF – Transport Functions)
ITU-T Y.2111 Resource and Admission Control Function [19] (Rc, Rn, Rp, Rw)
6.28 S1 (IPTV CF - CD&LCF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.11
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2616 Hypertext Transfer Protocol – HTTP [23]
6.29 S2 (Core IMS – SUP)
ITU-T Y.1910 IPTV Functional Architecture [16] (S2)
ITU-T Y.2021 IMS for Next Generation Networks [18] (Cx)
3GPP TS 23.228 (2008) IP Multimedia Subsystem (IMS) [32] clause 5.1.2.1
3GPP TS 29.228 IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and
message contents [34]
3GPP TS 29.229 Cx and Dx Interfaces based on the Diameter protocol, Protocol details [35]
6.30 S3 (Core IMS/IPTV CF - RACF)
ITU-T Y.1910 IPTV Functional Architecture [16] (S3)
ITU-T 2111 Resource and Admission Control Function [19] (Rs)
Page 32 of 35
msf2011.007.01
6.31 S4 (Core IMS/IPTV CF – NACF)
ITU-T Y.1910 IPTV Functional Architecture [16] (S4)
ITU-T Y.2014 Network Attachment Control Function [17] (S-TC1)
6.32 S5 (IPTV CF - CD&SF)
ATIS-0800042 IPTV Content on Demand Service [15], section 10.12
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
IETF RFC 2326 Real Time Streaming Protocol (RTSP) [22]
6.33 S6 (IPTV CF - SUP)
3GPP TS 23.228, IP Multimedia Subsystem (IMS) Release 8 [32] clause 4.2.4a
3GPP TS 29.328 IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message
contents [36]
3GPP TS 29.329 Sh interface based on the Diameter protocol; Protocol details [37]
6.34 S7 (Core IMS - IPTV CF)
3GPP TS 23.228 (2008) IP Multimedia Subsystem (IMS) [32] clause 4.2.4
3GPP TS 24.229 IP Multimedia Call Control Protocol Based on SIP and SDP [33]
6.35 T1 (NACF - ARF)
ITU-T Y.1910 IPTV Functional Architecture [16] (T1)
ITU-T 2014 Network Attachment Control Function [17] (T-U1)
6.36 T2 (RCMS-SDS)
ATIS-0800009.v002 Remote Management of Devices in the Consumer Domain for IPTV Services [4]
ETSI TS 102 824 Remote Management and Firmware Update System for DVB IP Services
[29]
6.37 Ud (CD&SF - Unicast Transport Functions)
ATIS-0800042 IPTV Content on Demand Service [15], section 9
ATIS-0800013 Media Formats and Protocols for IPTV Services [5]
Page 33 of 35
msf2011.007.01
References
[1]
ATIS-0800004, A Framework for QoS Metrics and Measurements supporting
IPTV Services, December 2006
[2]
ATIS-0800007, IPTV High Level Architecture, April 2007
[3]
ATIS-0800008, QoS Metrics for Linear Broadcast IPTV, August 2007
[4]
ATIS-0800009.v002, Remote Management of Devices in the Consumer
Domain for IPTV Services, September 2009
[5]
ATIS-0800013, Media Formants and Protocols Specification, January 2009
[6]
ATIS-0800014.v002, Secure Download and Messaging Interoperability
Specification, September 2009
[7]
ATIS-0800015, Certificate Trust Hierarchy Interoperability Specification,
August 2008
[8]
ATIS-0800016, Standard PKI Certificate Format Interoperability Specification,
August 2008
[9]
ATIS-0800017.v002, Attachment and Initialization Specification for IPTV
Services in the Consumer Domain, April 2009
[10]
ATIS-0800018, IPTV Linear TV Service, January 2009
[11]
ATIS-0800019, Multicast Network Service Specification, October 2009
[12]
ATIS-0800020, IPTV EPG Metadata Specification, June 2008
[13]
ATIS-0800022, IPTV Consumer Device Configuration Metadata, March 2009
[14]
ATIS-0800041, Implementer’s guide to QoS Metrics, August 2010
[15]
ATIS-0800042, IPTV Content on Demand Service
[16]
ITU-T Y.1910, IPTV Functional Architecture, September 2008
[17]
ITU-T Y.2014, Network Attachment Control Functions in next Generation
Networks, March 2010
[18]
ITU-T Y.2021, IMS for Next Generation Networks, September 2006
[19]
ITU-T Y.2111, Resource and Admission Control Functions in Next Generation
Networks, November S2008
[20]
IETF RFC 2131 Dynamic Host Configuration Protocol, March 1997
[21]
IETF RFC 2236 Internet Group Management Protocol, Version 2, November
1997
[22]
IETF RFC 2326 Real Time Streaming Protocol (RTSP), April 1998
[23]
IETF RFC 2616 Hypertext Transfer Protocol - HTTP 1.1, June 1999
[24]
IETF RFC 3261 SIP: Session Initiation Protocol, June 2002
[25]
IETF RFC 3265 Session Initiation Protocol (SIP) – Specific Event Notification,
June 2002
[26]
IETF RFC 3376 Internet Group Management Protocol, Version 3, October
2002
[27]
IETF RFC 3926, FLUTE – File Delivery over Unidirectional Transport,
October 2004
[28]
Broadband Forum TR-069, CPE WAN Management Protocol, May 2004, and
Page 34 of 35
msf2011.007.01
Amendment 1, November 2006
[29]
ETSI TS 102 824, Remote Management and Firmware Update System for
DVB IP Services, February 2006
[30]
ETSI TS 123 002, Digital Cellular Telecommunications System (Phase 2+);
Universal Mobile Telecommunications System (UMTS); Network Architecture
3GPP TS 23.002), V9.3.0, June 2010
[31]
ETSI TS 123 228, Cellular Telecommunications System (Phase 2+);
Universal Mobile Telecommunications System (UMTS); IP Multimedia
Subsystem (IMS) Stage 2 V9.3.0, March 2010
[32]
3GPP TS 23.228, IP Multimedia Subsystem (IMS) V8.12.0, March 2010
[33]
3GPP TS 24.229, IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3,
V9.4.0 June 2010
[34]
3GPP TS 29.228, IP Multimedia (IMS) Subsystem Cx and Dx Interfaces;
Signalling flows and message contents V8.10.0, September 2010
[35]
3GPP TS 29.229, Cx and Dx Interfaces based on the Diameter protocol,
Protocol details V8.11.0, September 2010
[36]
3GPP TS 29.328, IP Multimedia Subsystem (IMS) Sh interface; Signalling
flows and message contents V8.10.0, September 2010
[37]
3GPP TS 29.329, Sh interface based on Diameter protocol; Protocol details
V8.7.0, September 2010
Page 35 of 35