CAUTION: This DRAFT document is provided for information and is for future development work within the ETSI Technical Committee TISPAN only. ETSI and its Members accept no liability for any further use/implementation of this Specification. Approved and published Specifications and reports for implementation of the TISPAN NGN system shall be obtained exclusively via the ETSI Documentation Service at http://pda.etsi.org/pda/queryform.asp ETSI TS 185 003 V3.1.1 (2010-06) Technical Specification Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Customer Network Gateway (CNG) Architecture and Reference Points
Transcript
CAUTION: This DRAFT document is provided for information and is for future development work within the ETSI
Technical Committee TISPAN only. ETSI and its Members accept no liability for any further use/implementation
of this Specification.
Approved and published Specifications and reports for implementation of the TISPAN NGN system shall be
obtained exclusively via the ETSI Documentation Service at http://pda.etsi.org/pda/queryform.asp
ETSI TS 185 003 V3.1.1 (2010-06)
Technical Specification
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);
Customer Network Gateway (CNG)Architecture and Reference Points
650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from: http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners. GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
Intellectual Property Rights ................................................................................................................................ 5
4 The CNG Architecture ............................................................................................................................. 9 4.1 Introduction ........................................................................................................................................................ 9 4.2 CPN and NGN side requirements ..................................................................................................................... 10 4.2.1 Analogue phone connected to the NGN through a CNG ............................................................................ 10 4.2.2 IMS Customer Network Device connected to the NGN through a CNG.................................................... 11 4.2.3 SIP-non IMS Customer Network Device connected to the NGN through a CNG ..................................... 12 4.3 CNG functions .................................................................................................................................................. 13 4.3.1 The transfer level functions ........................................................................................................................ 13 4.3.1.1 CNG-NFF: CNG-NAPT and Firewall Function ................................................................................... 13 4.3.2 The transport level functions ...................................................................................................................... 13 4.3.2.1 CNG-CSMF: CNG-Communication Services Media Function ............................................................ 13 4.3.2.2 CNG-IPTVF: CNG-IPTV Function ...................................................................................................... 13 4.3.3 The CNG Network Attachment Subsystem entities (CNG-NASS) ............................................................ 13 4.3.3.1 CNG-CMF: CNG-Configuration and Management Function ............................................................... 13 4.3.3.2 CNG-AtF: CNG-Attachment Function ................................................................................................. 14 4.3.3.3 CNG-PCF: CNG-Policy Control Function ............................................................................................ 14 4.3.3.4 CNG-AuF: CNG-Authentification Function ......................................................................................... 14 4.3.3.5 CNG-LF: CNG-Location Function ....................................................................................................... 14 4.3.4 The CNG-Resource and Admission Control Functional entities (C-RACF) ............................................. 14 4.3.4.1 CNG-ACF: CNG-Admission Control Function .................................................................................... 14 4.3.5 The CNG-Service-related Functional entities (CNG-SF) ........................................................................... 15 4.3.5.1 VGCF: Voice Gateway Control Function ............................................................................................. 15 4.3.5.2 CNG-SIP Proxy B2BUA Function ....................................................................................................... 15 4.3.5.3 CNG-PPF: CNG-Plug and Play Function ............................................................................................. 15 4.3.5.4 CNG-UIF: CNG-User Interface Function ............................................................................................. 16 4.3.5.5 ISIM module ......................................................................................................................................... 16
' reference point ................................................................................................................................. 17
5.1.1.2 e3' reference point ................................................................................................................................. 17
5.1.1.3 au reference point .................................................................................................................................. 18 5.1.2 Transport level reference points.................................................................................................................. 18 5.1.2.1 Dj reference point .................................................................................................................................. 18 5.1.2.2 Dj' reference point ................................................................................................................................. 18 5.1.3 Service-related reference points .................................................................................................................. 18 5.1.3.1 Gm
' reference point ............................................................................................................................... 18 5.1.3.2 u reference point .................................................................................................................................... 18 5.1.3.3 C reference point ................................................................................................................................... 19 5.2 NGN side Reference points .............................................................................................................................. 19 5.2.1 Network attachment reference points ......................................................................................................... 19
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)4
5.2.1.1 e1 reference point .................................................................................................................................. 19 5.2.1.2 e3 reference point .................................................................................................................................. 19 5.2.2 Service-related reference points .................................................................................................................. 19 5.2.2.1 Gm reference point ................................................................................................................................ 19 5.2.2.2 Ut reference point .................................................................................................................................. 20
6 The CNG Data Model ............................................................................................................................ 20
7 Information flows ................................................................................................................................... 20 7.1 Attachment flows ............................................................................................................................................. 21 7.2 Configuration and management flows .............................................................................................................. 21 7.3 Signalling flows ................................................................................................................................................ 22 7.3.1 CND attachment and local/IMS registration ............................................................................................... 22 7.3.2 Outgoing call .............................................................................................................................................. 24 7.3.2.1 SIP non-IMS CND ................................................................................................................................ 24 7.3.2.2 IMS CND .............................................................................................................................................. 25 7.3.3 Internal call ................................................................................................................................................. 25 7.3.4 Admission Control ...................................................................................................................................... 26 7.4 Remote Access flows ....................................................................................................................................... 27 7.4.1 Remote access basic architecture ............................................................................................................................. 27 7.4.1.1 Remote Access Connection Set-up ............................................................................................................. 28 7.4.1A Remote Access Connection Set-up using secure tunnel connection ........................................................... 29 7.4.1B Media delivery using multiple tunnel connection ....................................................................................... 30 7.4.1.2 Download of content using HTTP .............................................................................................................. 31 7.4.1.3 Upload of content using HTTP ................................................................................................................... 32 7.4.2 Remote Access using UPnP functionalities .............................................................................................................. 33 7.4.2.1 Remote Access AS database configuration with access rights .............................................................................. 35 7.4.2.2 Remote Access set-up ........................................................................................................................................... 36 7.4.2.3 Remote Browsing .................................................................................................................................................. 36 7.4.2.4 Media Delivery ...................................................................................................................................................... 37
Annex A (informative): Bibliography ........................................................................................................... 38
Annex B (informative): Change History....................................................................................................... 39
History .............................................................................................................................................................. 40
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)5
Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN).
Introduction The present document defines Release 2 of an anticipated series of releases of TISPAN NGN. Release 2 extends the capabilities of Release 1, enhances some Release 1 capabilities and provides some new services. The TISPAN NGN is described in terms of the content capabilities and this release (Release 2) is defined by the documentation set and the features that these support.
The general objective of Release 2 is to extend Release 1 through enhancements and new services. The present document focuses on additional capabilities and services and continues to enable an NGN to be a flexible platform allowing future enhancements and releases. The TISPAN NGN is specified using a release mechanism. The present document provides an overview of the capabilities in the second release. No assumptions should be made about future releases.
Throughout the present document, references to NGN are assumed to be references to TISPAN NGN unless otherwise indicated.
1 Scope The present document provides an overview of Customer Network Gateway (CNG) functional architecture and reference points and the way it interacts with an NGN, as described in ETSI TISPAN Release 1 and Release 2 standards (see ES 282 001 [1]).
The present document describes architectural building blocks to be included in the CNG to support the interworking with an NGN, both at the transfer, transport and service layers. It also defines the reference points between the CNG internal architectural blocks involved and a CND.
The WG5 does not address the layer 1 issues, as such studies refer to the AT&TM Group.
2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity.
2.1 Normative references The following referenced documents are indispensable for the application of the present document. For dated references, only the edition cited applies. For non-specific references, the latest edition of the referenced document (including any amendments) applies.
[1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture".
[2] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS): Functional Architecture".
[3] ETSI ES 282 004: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-System (NASS)".
[4] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture".
[5] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 [Release 7], modified]".
[6] ETSI TS 182 012: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based PSTN/ISDN Emulation Sub-system (PES); Functional architecture".
[7] ETSI TS 183 019: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Network Attachment; User-Network Interface Protocol Definitions".
[9] ETSI TS 131 103: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Characteristics of the IP Multimedia Services Identity Module (ISIM) application (3GPP TS 31.103)".
[11] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229 version 8.2.0 Release 8)".
[12] ETSI TS 185 006: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Customer Devices architecture and Reference Points".
[13] ETSI TS 185 009: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Architecture and reference points of a customer network device for IMS based IPTV services".
[15] Broadband Forum TR-069: "CPE WAN Management Protocol". Accessible through http://www.broadband-forum.org/technical/trlist.php
[16] Broadband Forum TR-098: "Data Model for TR6069". Accessible through http://www.broadband-forum.org/technical/trlist.php
[17] Broadband Forum TR-104: "Provisioning Parameters for VoIP CPE". Accessible through http://www.broadband-forum.org/technical/trlist.php
2.2 Informative references The following referenced documents are not essential to the use of the present document but they assist the user with regard to a particular subject area. For non-specific references, the latest version of the referenced document (including any amendments) applies.
[i.1] ETSI TR 185 007: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Analysis of protocols for customer networks connected to TISPAN NGN".
[i.2] ETSI TR 185 004: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); High level customer network architectures".
[i.3] ETSI TS 185 005: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Services requirements and capabilities for customer networks connected to TISPAN NGN".
[i.4] ETSI TR 180 001: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Release 1; Release definition".
[i.5] HGI-RD001-R2.01: "HGI Forum Home Gateway Technical Requirements: Residential Profile V1.01" http://www.homegatewayinitiative.org/publis/index.html
[i.6] HGI-GD002-R2.01: "HGI Forum Remote Access Guidelines" http://www.homegatewayinitiative.org/publis/index.html
3.1 Definitions For the purposes of the present document, the following terms and definitions apply:
CPN Device: device that is physically installed in the CPN allowing user access to network services; this can be a Customer Network Gateway with gateway functionalities towards the NGN, or a Customer Network Device being the end user terminal
Customer Network Device (CND): CPN device enabling the final user to have direct access to services through a specific user interface
NOTE: CNDs can be dedicated to the internet, conversational and audio-video services. But they could be also Consumer Electronics equipment and other devices which may have nothing to do with these premium services (e.g. services performing a content sharing within a CPN, typically between a PC and a music system).
Customer Network Gateway (CNG): CPN device acting as a gateway between the CPN and the NGN
NOTE: CNG is able to perform networking functions from physical connection to bridging and routing capabilities (L1 to L3), but also possibly implementing functions related to the service support (up to L7).
Customer Premises Network (CPN): in-house network composed by customer network gateway, customer network devices, network segments, network adapters and nodes
NOTE: Network segments are physical wired or wireless connections between customer premises network elements); network adapters are elements performing a L1/L2 conversion between different network segments; nodes are network adapters with L3 routing capabilities.
IMS CND: CND whose external behaviour complies with the IMS specifications
NOTE: See [1], [2], [3], [4] and [5].
"Multiple" Play Services (can be: double, triple, quadruple etc.): delivery by a single service provider of different types of concurrent services to one or multiple users within the same CPN
NOTE: Services can be categorized in the following way: data (e.g. Web browsing, best effort traffic etc.), person(s) to person(s) communication, entertainment.
Non-IMS SIP IETF CND: SIP-based CND whose external behaviour conforms to RFC 3261 [8] but do not fully conform to the IMS specifications
Many scenarios are expected to provide one service from a service provider to a customer device (case of multiple service providers, one or several CNG, etc.). They are presented within the TR 185 004 [i.2] and TS 185 005 [i.3].
3.2 Abbreviations For the purposes of the present document, the following abbreviations apply:
ACS Auto-Configuration Server AKA Authentication and Key Agreement ALG Application Layer Gateway A-MGF Access-Media Gateway Function ARF Access Relay Function B2BUA Back-to-Back User Agent BC Broadcast Content CLF Connectivity session Location and repository Function
CND Customer Network Device CNG Customer Network Gateway CNG-ACF CNG-Admission Control Function CNG-AtF CNG-Attachment Function CNG-AuF CNG-Authentication Function CNGCF CNG Configuration Function CNG-CMF CNG-Configuration and Maintenance Function CNG-CSMF CNG- Communication Services Media Function CNG-LF CNG-Location Function CNG-NFF CNG-NAPT and Firewall Function CNG-PCF CNG-Policy Control Function CNG-PPF CNG-Plug and Play Function CNG-UIF CNG-User Reference point Function CoD Content on Demand CPN Customer Premises Network DHCP Dynamic Host Configuration Protocol
DLNA Digital Living Network Alliance EF Elementary Files ETH ETHernet IGMP Internet Group Multicast Protocol IMPU IMS PUblic identity IMS IP Multimedia Subsystem IP Internet Protocol IPTV IP TeleVision ISIM IMS Subscriber Identity Module MGC Media Gateway Controller NACF Network Access Configuration Function NAPT Network Address and Port Translation
NASS Network Attachment Subsystem NAT Network Address Translation NDN Next Generation Network P-CSCF Proxy Call Session Control Function PLT Power-Line Telecommunication RADA Remote Access Discovery Agent RATA Remote Access Transport Agent RTSP Real Time Streaming Protocol SDP Session Data Protocol SIP Session Initiation Protocol SSID Service Set IDentifier UE User Equipment UICC Universal Integrated Circuit Card VGCF Voice Gateway Control Function VoIP Voice over IP
4 The CNG Architecture
4.1 Introduction The following clauses present the functional entities for the CNG. Examples of Customer Network Devices may be connected to the CNG:
a) Analogue phones connected through the CNG to the NGN network.
b) IMS Customer Network Devices connected through a CNG to the NGN network [5].
d) ISDN Customer Network Devices through the CNG to the NGN network.
Different types of Customer Network Devices may be involved in Intra CPN communication through a CNG.
The list of Customer Network Devices which are likely to be connected to the CNG is provided by the TS 185 006 [12].
The general overview of the CPN Architecture is provided by the TR 185 004 [i.2]. The CNG functional entities are described in the following parts of the document, as well as the reference points between each function.
4.2 CPN and NGN side requirements The list of the CNG requirements is provided by the TS 185 005 [i.3]. specification for Service requirements and capabilities for customer networks connected to TISPAN NGN.
4.2.1 Analogue phone connected to the NGN through a CNG
In this case, the CNG includes all the CPN functionalities necessary to fulfill a service between the analogue phone and the NGN, as shown in figure 1.
CNG
Access node
P-CCSF
CNGCF
ARF
Voice Gateway Control Functions (VGCF)
Gm
e3
e1
Z
Customer Network Gateway
AnalogCND
Dj
ASUt
CNG-Attachment Function (CNG-AtF)
The CPN Environment the NGN and IMS entities
ISIMUICC
CNG-IPTV Functions (CNG-IPTVF)
CNG-Communication Services Media Function (CNG-CSMF)
CNG-Configuration & Management Function (CNG-CMF)
CNG-Policy Control Function (CNG-PCF)
CNG-Location Function (CNG-LF)
Z
CNG
Access node
P-CCSF
CNGCF
ARF
Voice Gateway Control Functions (VGCF)
Gm
e3
e1
Z
Customer Network Gateway
AnalogCND
Dj
ASUt
CNG-Attachment Function (CNG-AtF)
The CPN Environment the NGN and IMS entities
ISIMUICC
CNG-IPTV Functions (CNG-IPTVF)
CNG-Communication Services Media Function (CNG-CSMF)
CNG-Configuration & Management Function (CNG-CMF)
CNG-Policy Control Function (CNG-PCF)
CNG-Location Function (CNG-LF)
Z
Exchanges inside the CNG
Network attachment functions
Transport plane functions
Service plane and applicative functions
Figure 1: Analogue phone connected to the NGN-IMS network through a CNG
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)11
4.2.2 IMS Customer Network Device connected to the NGN through a CNG
In this case, the Customer Network Device includes all the CPN functionalities necessary to fulfilll a service between itself and the NGN-IMS network, as shown in figure 2:
LAN WAN
CNG
LAN side :
the User Equipment
WAN side :
the NGN and IMS entities
P-CSCF
CNGCF
ARF
Gm
e3
e1
Customer Network Gateway
CNG-User Interface Function (CNG-UIF)
e3'
e1'
Access nodeDj
CND-SIP UA
CND-NAPT Traversal Function (CND-NTF)
CND-Communication Services Media Function (CND-CSMF)
u
CNG-Location Function (CNG-LF)
AS
Ut
Ut
au
CNG-Attachment Function (CNG-AtF)
CND
CNG-Plug and Play Function (CNG-PPF)
CND-Plug and Play Function (CND-PPF)
C
CND-Local Authentication Function (CND-LAF)
CND-Configuration & Management Function (CND-CMF)
CND-Attachment Function (CND-AtF)
CND-Self Provisioning (CND-SP)
Customer ApplicationCustomer
ApplicationCustomer Application
Gm'
CNG-Authentication Function (CNG-AuF)
CNG-Policy Control Function (CNG-PCF)
CNG-Configuration & Management Function (CNG-CMF)
CNG-AdmissionControlFunction (CNG-ACF)
Gm
CNG-NAPT and Firewall Function (CNG-NFF)
e3
B2BUA
CNG- SIP proxy B2BUA
SIP Proxy
Registrar
Customer Network Device
e1
ISIMUICC
UICC
ISIM
CNG-IPTV Functions (CNG-IPTVF)
Gm
LAN WAN
CNG
LAN side :
the User Equipment
WAN side :
the NGN and IMS entities
P-CSCF
CNGCF
ARF
Gm
e3
e1
Customer Network Gateway
CNG-User Interface Function (CNG-UIF)
e3'
e1'
Access nodeDj
CND-SIP UA
CND-NAPT Traversal Function (CND-NTF)
CND-Communication Services Media Function (CND-CSMF)
u
CNG-Location Function (CNG-LF)
AS
Ut
Ut
au
CNG-Attachment Function (CNG-AtF)
CND
CNG-Plug and Play Function (CNG-PPF)
CND-Plug and Play Function (CND-PPF)
C
CND-Local Authentication Function (CND-LAF)
CND-Configuration & Management Function (CND-CMF)
CND-Attachment Function (CND-AtF)
CND-Self Provisioning (CND-SP)
Customer ApplicationCustomer
ApplicationCustomer Application
Gm'
CNG-Authentication Function (CNG-AuF)
CNG-Policy Control Function (CNG-PCF)
CNG-Configuration & Management Function (CNG-CMF)
CNG-AdmissionControlFunction (CNG-ACF)
Gm
CNG-NAPT and Firewall Function (CNG-NFF)
e3
B2BUA
CNG- SIP proxy B2BUA
SIP Proxy
Registrar
Customer Network Device
e1
ISIMUICC
UICC
ISIM
CNG-IPTV Functions (CNG-IPTVF)
Gm
Exchanges inside the CNG
Network attachment functions
Transport plane functions
Service plane and applicative functions
NOTE: The IMS CND functions are described within TS 185 006 [12] dedicated to Customer Network Devices.
Figure 2: IMS Customer Network Device connected to the NGN-IMS network through a CNG
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)12
4.2.3 SIP-non IMS Customer Network Device connected to the NGN through a CNG
In this case, the Customer Network Gateway includes all the CPN functionalities necessary to fulfilll a service between itself and the NGN-IMS network, as shown in figure 3.
CNG
LAN side : the User Equipment
WAN side :
the NGN and IMS entities
P -CCSF
CNGCF
ARF
G m
e3
e1
Customer Network Gateway
CNG -User Interface Function (CNG - UIF)
e3'
e 1 '
Access node Dj
CND - SIP UA
CND -NAPT Traversal Function (CND -NTF)
CND -Communication Services Media Function (CND -CSMF)
u
CNG -Location Function (CNG -LF)
AS U t
U t
a u
CNG -Attachment Function (CNG - AtF)
CND CNG -Plug and Play Function (CNG -PPF)
CND -Plug and Play Function (CND -PPF) C
CND - Local Authentication Function (CND -LAF)
CND -Configuration & Management Function (CND -CMF)
CND - Attachment Function (CND - AtF)
CND -Self Provisioning (CND - SP)
Customer ApplicationCustomer
Application Customer Application
G m '
CNG -Authentication Function (CNG -AuF )
CNG - Policy Control Function (CNG -PCF)
CNG - Configuration & Management Function (CNG -CMF)
CNG -AdmissionControlFunction (CNG -ACF)
G m
CNG -NAPT and Firewall Function (CNG -NFF)
e3
B2BUA
CNG - SIP proxy B2BUA
SIP Proxy Registrar
Customer Network Device
e 1
ISIMUICC
UICC ISIM
CNG -IPTV Functions (CNG -IPTVF)
G m
Dj'
CNG
LAN side : the User Equipment
WAN side :
the NGN and IMS entities
P -CCSF
CNGCF
ARF
G m
e3
e1
Customer Network Gateway
CNG -User Interface Function (CNG - UIF)
e3'
e 1 '
Access node Dj
CND - SIP UA
CND -NAPT Traversal Function (CND -NTF)
CND -Communication Services Media Function (CND -CSMF)
u
CNG -Location Function (CNG -LF)
AS U t
U t
a u
CNG -Attachment Function (CNG - AtF)
CND CNG -Plug and Play Function (CNG -PPF)
CND -Plug and Play Function (CND -PPF) C
CND - Local Authentication Function (CND -LAF)
CND -Configuration & Management Function (CND -CMF)
CND - Attachment Function (CND - AtF)
CND -Self Provisioning (CND - SP)
Customer ApplicationCustomer
Application Customer Application
G m '
CNG -Authentication Function (CNG -AuF )
CNG - Policy Control Function (CNG -PCF)
CNG - Configuration & Management Function (CNG -CMF)
CNG -AdmissionControlFunction (CNG -ACF)
G m
CNG -NAPT and Firewall Function (CNG -NFF)
e3
B2BUA
CNG - SIP proxy B2BUA
SIP Proxy Registrar
Customer Network Device
e 1
ISIMUICC
UICC ISIM
CNG -IPTV Functions (CNG -IPTVF)
G m
Dj'
Exchanges inside the CNG
Network attachment functions
Transport plane functions
Service plane and applicative functions
Figure 3: Non IMS SIP Customer Network Device connected to the NGN-IMS network through a CNG
In this case Gm' is used, the SIP proxy B2BUA shall perform an adaptation of the non-IMS SIP profile from a CND
which requests for an IMS session.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)13
4.3 CNG functions
4.3.1 The transfer level functions
4.3.1.1 CNG-NFF: CNG-NAPT and Firewall Function
The CNG-NFF entity shall provide gate control functionality i.e. dynamic NAPT and firewall functions at the boundary between the CPN and the NGN.
4.3.2 The transport level functions
4.3.2.1 CNG-CSMF: CNG-Communication Services Media Function
The CNG-CSMF is the termination point for the access node, it shall perform an adaptation so as to deliver media flows from the NGN network to an analogue or IP Customer Network Device.
The CNG-CSMF is used for analogue (or digital in the case of ISDN CNDs) to IP media conversion - in which case it corresponds to the R-MGF identified in ES 282 001 [1] or it is used for IP-IP media traffic.
In case the CPN is provided with analogue or ISDN CNDs and the media gateway function is not implemented in the NGN (as an A-MGF, c.f. ES 282 001 [1]), the CNG-CSMF shall be used.
As a result, this functionality is recommended.
4.3.2.2 CNG-IPTVF: CNG-IPTV Function
When supporting IPTV services, the CNG shall be able to forward inbound multicast packets only to the physical interfaces connected to devices that have joined the specific multicast group. This mechanism should be implemented acting on layer 2 and layer 3 multicast signalling flows (e.g. IGMP based).
The CNG shall be able to perform a link layer multicast to unicast translation, if the CPN segment, which the IPTV CND is connected to, is not able to support multicast; specifically, when sending an IP multicast packet to a host received on an NGN reference point, the CNG can send the packet to the unicast MAC address of the host (contained in the multicast signalling message without any change in the IP destination address). This mechanism is also of interest for example when the IPTV CND is connected to the CNG through Powerlines technology (directly or using ETH-to-PLT bridges).
4.3.3 The CNG Network Attachment Subsystem entities (CNG-NASS)
4.3.3.1 CNG-CMF: CNG-Configuration and Management Function
The CNG-CMF shall manage a mutual authentication between the CNGCF and the CNG.
The CNG-CMF shall enable the CNG configuration and firmware upgrade.
The CNG-CMF entity should enable transmission of configuration information to CNDs, obtained from the CNGCF. As a result the CNG-CMF should be able particularly to store configuration information dedicated to several CND, after sending only one request to the CNGCF. As soon as a CND is connected, the CNG-CMF should be able to deliver configuration parameters to it.
Furthermore, the CNG-CMF should allow maintenance of any CPN device (CNG/CND) from the NGN network, through the CND-CMF, that is to say the opportunity to do diagnostic and performance tests too. Functionalities should be added to the CNGCF, whether this latter entity could perform the CPN maintenance.
For instance, the CNG-CMF could provide the functionality and reference points of a Broadband Forum Auto Configuration Client (see TR-069 [15]).
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)14
Moreover, the CNG-CMF may be able to perform management activities related to remote access. The remote access allows the user to access a CND from another device via the Internet through the Gm reference point, and work on it
remotely.
Some authentication parameters may be stored in a UICC (containing the ISIM).
4.3.3.2 CNG-AtF: CNG-Attachment Function
The CNG-AtF entity shall be responsible for allocation of IP addresses to user premises equipment (CND), and to the CNG from the NACF via the ARF.
4.3.3.3 CNG-PCF: CNG-Policy Control Function
The CNG-PCF may integrate a database containing the access profile.
This includes bandwidth and QoS parameters for the CNG Customer Network Device side applications and terminals, which could be configured by a user. For instance, congestion issues within the CPN may be solved defining resources for several SSID.
4.3.3.4 CNG-AuF: CNG-Authentification Function
The CNG-AuF shall manage the authentication of CNDs to be connected to the CPN. A CND requesting for a CPN Wireless attachment should be authorized by the access point embedded in the CNG.
The CNG-AuF may thus be configured by the user for such a case, using the CNG-User Interface Function (CNG-UIF).
4.3.3.5 CNG-LF: CNG-Location Function
The CNG-LF functional entity may allow an internal application providing location information, to perform for instance emergency calls or deliver some local video content.
This information may be configured by the owner of the CNG, received from the CLF or obtained from the network, via the CNG-AtF (typically through DHCP option 82).
The information should also come from the CLF. In this case the CNG-LF may not be used.
4.3.4 The CNG-Resource and Admission Control Functional entities (C-RACF)
4.3.4.1 CNG-ACF: CNG-Admission Control Function
The CNG-ACF should receive and send QoS messages from/to the CNG-SIP proxy B2BUA Function. In particular it should:
a) check resources availability on each link/device involved in the communication requesting a QoS reservation/allocation, through an internal database;
b) perform the appropriate resources reservation, through the CNG-PCF.
Thus, the CNG-ACF should manage session limitations for instance or the priority of media streams. This applies to upstream flows but there may also be an opportunity to do so for downstream flows.
The CNG-ACF is only able to take into account sessions that pass through the SIP B2BUA. Sessions using encrypted signalling or different signalling protocols will not be included. In the latter case the CNG-ACF might allow more sessions through the access line that it should have. As RACS has a full view on all sessions over the access line, it will deny the session setup thus preventing an overload situation [i.7].
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)15
4.3.5 The CNG-Service-related Functional entities (CNG-SF)
Depending on the services supported, a CNG may include one or more Service-related Functions. The present version of the present document identifies four types of SCFs intended to support SIP-based applications. It should be noted that not all applications require a Service-related Function to be involved (e.g. P2P applications usually do not require such functions).
4.3.5.1 VGCF: Voice Gateway Control Function
The VGCF within the CNG is the equivalent of an MGC embedding a SIP User Agent. A CNG should include several UAs in case of multi analogue and/or ISDN Customer Network Device within the CPN. The VGCF should control the CNG-CSMF (i.e. the R-MGF as defined in ES 282 001 [1]).
The VGCF should perform the service authentication and manage signalling flows securely.
NOTE: The VGCF together with the CNG-CSMF provides the function of a R-VGW as defined in TS 182 012 [6].
In case of AKA authentication, the VGCF shall have access to the authentication parameters through an ISIM/UICC functionality. To be noticed that HTTP Digest is for an early deployment whereas IMS AKA is the target solution.
4.3.5.2 CNG-SIP Proxy B2BUA Function
The CNG-SIP Proxy B2BUA should implement:
a) a Local SIP Registrar without any authentication needed;
b) an outbound SIP Proxy, a SIP access point for the P-CSCF, forwarding the register messages to the P-CSCF if necessary.
Moreover, it may be:
c) a protocol adaptation module performing an adaptation of non-IMS compliant IETF SIP protocols towards one IMS compliant SIP protocol. This functionality could also be performed by the NGN.
NOTE: Some adaptation may be performed by the CNG so as to support non-IETF SIP CNDs in the CPN (proprietary SIP) but this case is out of the scope of the present document.
d) a protocol adaptation module performing remote access communication establishment. This functionality is called Remote Access Transport Agent (RATA).
The CNG-SIP Proxy B2BUA Function should be aware of each SIP CND (could be an IMS CND) capability within the CPN environment.
The CNG-SIP Proxy B2BUA Function shall at last be able to manage two SIP dialogues and the associated identities (possibly through an ISIM module), from both the NGN and the CND sides. This gives the opportunity to transfer an IMS session from a device to another or to forward an incoming call to the appropriate CNDs (forking).
The responsibility of the RATA is to provide a communication channel enabling interaction between remote and in the home network located UPnP capable CND’s.
In case of AKA authentication, the SIP Proxy B2BUA shall have access to the authentication parameters through an ISIM/UICC functionality. To be noticed that HTTP Digest is for an early deployment whereas IMS AKA is the target solution.
4.3.5.3 CNG-PPF: CNG-Plug and Play Function
The CNG-PPF may obtain some CND information (service discovery, description) and allow their control.
Also, the CNG-PPF should allow a communication between many types of Customer Network Device within the CPN, not only conversational (based on UPnP for instance).
The CNG-PPF may also support this kind of communication through the CNG between NGN devices and CND devices.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)16
While facilitating such communication, ALG functionality may be needed by the CNG-PPF, interfacing the CNG-NFF.
Since some of the communication sessions supported by the CNG-PPF result in media sessions, the CNG-PPF may need to interface the CNG-ACF in order to support QoS provisioning for these types of services.
The Remote Access Discovery Agent (RADA) discovers and maintains a device-list for the services provided. The list is continuously updated, kept and provided for facilitating communication between devices.
When sessions (for example UPnP based) are initiated between a CND and a remote NGN device, they may be established by IMS SIP session establishment and then described in the SDP parts of the IMS SIP signalling. When establishing the UPnP session between the NGN and CPN endpoints the CNG-PPF needs to perform ALG functionality, by re-writing any CPN references within the UPnP messages and also control port forwarding through the CNG-NFF. Informative flows for the Remote Access feature are detailed in clause 7.4.
4.3.5.4 CNG-UIF: CNG-User Interface Function
The CNG-UIF entity should allow the user to configure many CNG parameters for the transport layer:
a) firewall rules, possibly defined for each user (e.g. parental control);
b) CNDs authorized within the CPN, with possible bandwidth restrictions.
The operator shall be able to prevent a user from modifying a specific subset of CPN parameters.
Thus this entity may have reference points with the CNG-AuF and the CNG-NFF of the CNG.
4.3.5.5 ISIM module
The ISIM (see figure 4) is a network access application dedicated to IMS access contained in a UICC. It may be implemented in a CNG.
Figure 4: Example of "UICC Card composition"
The ISIM includes:
a) The IMPI (IMS private identity).
b) At least one IMPU (IMS public Identity).
c) The operator's NGN Domain Name.
d) Support for sequence number checking in the context of the IMS Domain.
e) The same framework for algorithms as specified for the USIM applies for the ISIM.
f) An authentication element so as to support the AKA authentication.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)17
The ISIM is located in the ISIM Application Dedicated File (ADFISIM) and contains service and network related information. The ADFISIM provides various data contained in Elementary Files (EF), for instance the EFIMPI containing the private user identity. Details about this file structure can be found in TS 131 103 [9].
5 The CNG Reference points
5.1 CND side Reference points
5.1.1 Network attachment reference points
5.1.1.1 e1' reference point
The e1' reference point is defined between the CND and the CNG-AtF. The CNG-AtF provides IP addresses (IPv4 or
IPv6 format) to the CND through the CND-AtF, it may also send some configuration information for the CND (typically through DHCP).
The CND and CNG shall mutually exchange their identities (e.g. MAC address, DeviceID, etc.) on e1' reference point.
The CNG has to know which CNDs are behind itself within the CPN and each CND has to know its CNG.
This reference point is mandatory if the CNG runs in a routed mode
5.1.1.2 e3' reference point
The e3' reference point is defined between the CND and the CNG-CMF. The CNG-CMF may provide the CND with
parameters that are pre-configured in the CNGCF and sent to the CNG through the e3 reference point or, as an
alternative, directly defined by the user. The CNG-CMF also configures the CNG, using information received from the CNGCF or supplied by the user himself.
The CND should provide information on CND status to allow the CNGCF to make some diagnostic and performance tests through the CNG-CMF.
To sum up, the e3' reference point supports a variety of functionality to manage a collection of user equipment
(CNG/Customer Network Devices), including the following capabilities:
a) auto-configuration and service provisioning;
b) software/firmware management;
c) status and performance monitoring;
d) diagnostics.
This reference point is recommended as the e3 reference point could also be used.
The above mention functionalities can be also implemented directly using a direct e3 reference point between CND and
CNGCF as an e3 reference point defined in ES 282 004 [3].
The direct reference point between CND and CNG, e3', could be limited to service provisioning functions; this may be
used as an alternative to the corresponding functionalities on the e3 reference point between CND and CNGCF.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)18
5.1.1.3 au reference point
The au reference point is defined between the Customer Network Device and the CNG-AuF. There may be two types of
authentication/authorization, according to:
a) CPN pairing (attachment, encryption and security processes (WEP, WPA2, etc.)) based on specific CPN technologies (e.g. Wifi SSID, PLC technology).
b) Access rights for some LAN services like the CNG Configuration (through the CNG-UIF).
This reference point is recommended, except if a wireless access point is embedded in the CNG in which case it is mandatory.
5.1.2 Transport level reference points
5.1.2.1 Dj reference point
The Dj reference point is responsible for the exchange of media flows between the User Equipment (CNG or CND) and
the access node.
This reference point is mandatory. It is based on the ES 282 001 [1] specification.
5.1.2.2 Dj' reference point
The Dj' reference point is responsible for the exchange of media flows between the IPTV CND and the CNG. It is applicable only in case the CNG is supporting IPTV in routed mode, as specified in TS 185 009 [13].
Through Dj', the IPTV CND communicates with the CNG-IPTVF and its related functionalities (IGMP proxy and snooping).
This reference point is mandatory for IPTV CNDs performing CoD service (using RTSP) and BC service (using IGMP).
5.1.3 Service-related reference points
5.1.3.1 Gm' reference point
The Gm' reference point supports the communication between a CND and the CNG, e.g. related to registration and
session control.
The difference between Gm and Gm' is related to the conformance to the IMS and to the need to go through the B2BUA
to support local services. Further details about Gm' possible implementations can be found in the TR 185 007 [i.1].
This reference point is recommended.
5.1.3.2 u reference point
The u reference point gives the possibility to one or several users authorized (via the CNG-AuF) to have access to the CNG Configuration, through the CNG-UIF. The liaison should be as secure as possible (using HTTPs for instance).
This reference point is recommended.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)19
5.1.3.3 C reference point
The C reference point is defined between the CNG-PPF and the CND-PPF.
It provides some CND information (service discovery, description) to the CNG and allow its control.
Also, a communication between many types of Customer Network Device within the CPN may be established through the C reference point, using UPnP for instance.
This reference point is optional.
5.2 NGN side Reference points
5.2.1 Network attachment reference points
5.2.1.1 e1 reference point
This reference point is based on the TS 183 019 [7] specification.
The e1 reference point is dedicated to the network attachment of the User Equipment.
The e1 reference point is mandatory (in coherence with WG2 specifications).
5.2.1.2 e3 reference point
This reference point is based on the ES 282 004 [3].
The e3 reference point is defined between the CNG-CMF and the CNGCF and should be extended also between the
CNG-CMF and the CND for configuration purposes.
Through a remote management protocol it is possible to support a variety of functionalities to manage a collection of user equipment (CNG/Customer Network Devices), including the following capabilities:
a) auto-configuration and service provisioning;
b) software/firmware management;
c) status and performance monitoring;
d) diagnostics.
The e3 implementation between the CNG-CMF and the CNGCF is mandatory (in coherence with WG2 specifications),
whereas the e3 implementation between the CNG-CMF and the CND-CMF is recommended, as e3' should be an
alternative.
5.2.2 Service-related reference points
5.2.2.1 Gm reference point
The Gm reference point supports the communication between UE and the IMS, e.g. related to registration and session
control.
Gm between the P-CSCF and the SIP proxy B2BUA is used to support several actions:
a) send SIP messages to/from the NGN;
b) call forking at the CNG level.
The protocol used for the Gm reference point is SIP.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)20
To be noticed that the definition is extracted from the ES 282 007 [4].
This reference point is in line with the following specifications:
a) ES 283 003 [5].
b) TS 182 012 [6].
c) TS 131 103 [9].
This reference point is mandatory (in coherence with WG2 specifications).
5.2.2.2 Ut reference point
The Ut reference point enables the user to manage information related to his services, such as creation and assignment
of Public Service Identities, management of authorization policies that are used e.g. by Presence service, conference policy management, etc.
This reference point is in line with the ES 282 007 [4].
This reference point is optional (in coherence with WG2 specifications).
6 The CNG Data Model In case of an xDSL access network, the CNG shall support the gateway data model proposed by Broadband Forum in TR-098 [16] (data model for an internet gateway device).
In order to support IPTV CNDs, the CNG shall be compliant with Broadband Forum TR-069 [15] amendment 1 annex F (device - gateway association) and in order to solve the NAT traversal problem for ACS initiated session setup the CNG shall support the dynamic port mapping creation function as specified in TR-098 [16].
In order to support non IMS CND, the CNG shall support the set of parameters defined by Broadband Forum in TR-104 [17] (data model for VoIP functionalities).
The data model for cable-based CNG is for further studies.
7 Information flows NOTE: This clause is informative text reported in the form of examples, to give a better understanding of the
relationships between the CPN entities and functionalities. Exhaustive information flows will be given in a stage 3 document.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)21
7.1 Attachment flows The candidate protocol on e1' is DHCP specified in RFC 2131 [10]. In figure 5 the basic information flow is given.
CNDCND - AtF
CNGCNG - AtF
DHCP Discover
DHCP Offer
DHCP Request
DHCP Ack
CNDCND - AtF
CNGCNG - AtF
DHCP Discover
DHCP Offer
DHCP Request
DHCP Ack
Figure 5: CND Attachment on e1'
In order to mutually exchange the hardware identities between the CND and the CNG, the hardware identity can be defined for example as in TR-069 [15] (DeviceId) and the DHCP Option 125 can be used for the CND-CNG association as specified in TR-069, annex F [15].
7.2 Configuration and management flows The following information flow is an example of service provisioning functions supported by CNG (see figure 6).
CNDCND - CMF
CNGCNG - CMF
HTTP GET (Ask Identity)
200 OK (GET Response)
HTTP GET (Set Identity)
200 OK (GET Response)
CNDCND - CMF
CNGCNG - CMF
HTTP GET (Ask Identity)
200 OK (GET Response)
HTTP GET (Set Identity)
200 OK (GET Response)
Figure 6: Provisioning on e3'
With the first HTTP GET (Ask Identity), the CND asks the CNG for the list of available identities (IMPI, IMPU, etc.), and the CNG answers with the identities list in the HTTP GET Response. Then the CND chooses one identity and, in the second HTTP GET (Set Identity), provides the choice to the CNG, which then answers with confirmation in the HTTP Get Response.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)22
7.3 Signalling flows
The candidate protocol on Gm' is SIP specified in RFC 3261 [8], and optionally HTTP Digest as an authentication
method as specified in RFC 2617 [14].
The candidate protocol on Gm is SIP specified in TS 124 229 [11] and ES 283 003 [5].
7.3.1 CND attachment and local/IMS registration
The non-IMS devices considered in this case are devices associated to the VoIP phone number of the CNG.
Different kinds of devices are foreseen (see also TS 185 006 [12]), some examples are:
a) Fixed or Wireless SIP phone.
b) SIP Multi-mode (e.g. dual WI-Fi/3G phone).
c) SIP softphone on PC.
d) Other: playstation, STB, etc.
These SIP non-IMS devices have a local SIP identity, as defined as local SIP URI (e.g. device_kitchen) or public SIP URI (e.g. John123):
a) Vendor provides a local SIP identity for all SIP devices. This enables "Plug and play" functionality. User does not need to configure the SIP device. By default, this local identity can be the MAC address.
b) User can change the local identity provided by the vendor to another local identity or public SIP URI. The customer can change this parameterization, and select a specific name.
Or a local phone number for each device.
The attachment phase is:
1) For non IMS CND's the Gm' reference point is used (for local services), the DHCP server of the CNG will
return the DHCP option 120 to the CND, standardized to provision CNG SIP proxy IP address or domain-name. This option will contain the IP address of the CNG on the CPN side (ex: 192.168.1.1).
2) The device registers locally to the CNG SIP-IMS proxy (Registrar) using its local SIP URI. SIP REGISTER message is sent by the CNG to the NGN with the IMPU of the CNG which maps to the CND local SIP URI.
3) So as to allow the device to communicate through the NGN, the customer can configure the association between the local SIP URI of the device (pre-configured in the device) and the CNG's public IMS identity (IMPU), or the device can use its own public SIP URI (pre-configured in the device) to send the register through the CNG SIP proxy.
The authentication is handled directly by the CNG-SIP proxy B2BUA.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)23
CNG-B2BUA
REGISTER (local SIP URI)
200 (OK)
REGISTER (IMPI,IMPU, Aut_header)
200 OK
Adds challenge response
401 (Unauthorized)
REGISTER (IMPI,IMPU, response)
Adds Authorization header
IMS CoreNetwork
CND witha local Id CNG-B2BUA
REGISTER (local SIP URI)
200 (OK)
REGISTER (IMPI,IMPU, Aut_header)
200 OK
Adds challenge response
401 (Unauthorized)
REGISTER (IMPI,IMPU, response)
Adds Authorization header
IMS CoreNetwork
CND witha local Id
Figure 7: Non-IMS capable CND attachment and local/IMS registration
Other devices shall use their own IMPU (pre-configured in the device) to send the register directly to the NGN proxy. This should also be done through the CNG SIP proxy. It should be the case for instance for a nomadic device which should be able to register locally at the CNG level as it could use the option 120 not to know its registrar already provisioned, but to discover the outbound proxy within the CNG. This would give the opportunity for an IMS device to be involved in local SIP communications managed through the CNG SIP Proxy (e.g. call transfer). This case is described in figure 8.
with
CNGCNG SIP proxyIMS
with
CNG
REGISTER (IMPU)
200 OK
401
(SIP outbound proxy = CNG address)
)
SIP- IMS ProxySIP corenetwork
IMS
200 OK
REGISTER (IMPU,IMPI,challenge response)
SIP- IMS ProxySIP corenetwork
IMS
DHCP with option120
CNGCNG SIP proxy
401
200 OK
REGISTER (IMPU)
REGISTER (IMPU,IMPI,challenge response)
with
CNGCNG SIP proxyIMS
with
CNG
REGISTER (IMPU)
200 OK
401
(SIP outbound proxy = CNG address)
)
SIP- IMS ProxySIP corenetwork
IMS
200 OK
REGISTER (IMPU,IMPI,challenge response)
SIP- IMS ProxySIP corenetwork
IMS
DHCP with option120
CNGCNG SIP proxy B2BUA
401
200 OK
REGISTER (IMPU)
REGISTER (IMPU,IMPI,challenge response)
IMS CND
Figure 8: IMS capable CND attachment and IMS registration
NOTE: This scenario is not possible in case of IMS device implementing the AKA authentication mechanisms (IPsec tunnel through the CNG).
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)24
7.3.2 Outgoing call
7.3.2.1 SIP non-IMS CND
The SIP non-IMS device is provided with a public SIP URI or a local identity, as is the case in figure 9.
INVITE (local SIP URI)
200 OK
407 (challenge)
INVITE (IMPU, IMPI, challenge response)
SIP "fixed" terminal
IMS corenetwork
1xx
ACK
INVITE (IMPU)
RTP/RTCP
CND with a local Id (eg device_kitchen)
200 OK
407 (challenge)
INVITE (IMPU, IMPI, challenge response)
SIP "fixed" terminal CNG SIP Proxy
ACK
INVITE (IMPU)
RTP/RTCP
CND with a local Id (eg device_kitchen)
200 OK
1xx
ACK
INVITE (local SIP URI)
200 OK
407 (challenge)
INVITE (IMPU, IMPI, challenge response)
SIP "fixed" terminal
IMS corenetwork
1xx
ACK
INVITE (IMPU)
RTP/RTCP
CND with a local Id (eg device_kitchen)
200 OK
407 (challenge)
INVITE (IMPU, IMPI, challenge response)
SIP "fixed" terminal CNG SIP Proxy
ACK
INVITE (IMPU)
RTP/RTCP
CND with a local Id (eg device_kitchen)
200 OK
1xx
ACK
NOTE: The 407 (challenge) is optional.
Figure 9: Outgoing call for a non-IMS CND
For SIP non-IMS CND, the CNG SIP proxy can replace the device local SIP URI with its own IMPU in the SIP INVITE, in case the CNG IMPU is associated with several CNDs (only one register is sent to the P-CSCF for several devices with the same tel number).
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)25
7.3.2.2 IMS CND
INVITE (IMPU)
200 OK
407 (challenge)
INVITE (IMPU, IMPI, challenge response)
SIP "nomadic" terminal SIP-IMS Proxy
SIP corenetwork
1xx
ACK
INVITE (IMPU)
RTP/RTCP
IMS CNDCNG-SIP Proxy
B2BUA IMS Core Network
407 (challenge)
INVITE (IMPU, IMPI, challenge response
1xx
200 OK
ACK
NOTE: The 407 (challenge) is optional.
Figure 10: Outgoing call for a IMS CND
7.3.3 Internal call
The CNG SIP proxy can route local call between two devices of the CPN.
No NGN resource is used to establish internal call.
SIP signalling is not forwarded to core network and media streams are kept on the CPN directly between endpoints.
The SIP proxy identifies internal call after the analysis of the called party number.
The customer can dial:
a) Directly the local identity of the device (ex: kitchen, dect, John, etc.).
b) Or a private numbering plan. The commutation table is configurable for instance by the customer on the web server of the CNG.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)26
Figure 11: Internal call
7.3.4 Admission Control
The CNG-Admission Control Function (CNG-ACF) module calculates the available resources on the access line during the establishment of a new session, possibly limiting the number of sessions in advance, before the direct intervention of the RACS on the NGN side. As it has no means of reading signalling protocols other than unencrypted SIP, the result of this calculation may be wrong for the access line because of an underestimation of the total number of sessions. Still RACS will assure the proper result for the connection admission control over the access line and limit the session setup [i.7].
The module is considered as optional (as Gm' and Gm interfaces related to the SIP proxy).
The objective is to guaranty the quality of service for each new session and existing sessions previously established.
The B2BUA extracts from SIP message the SDP offer and announced capabilities (codec audio, video, etc.).
It asks to the CNG-ACF if announced capabilities are compliant with the available resource.
The CNG-ACF module returns 3 responses:
a) OK:
a) The resource is available for all announced codecs.
b) The initial SIP message is forwarded without any change on SDP part.
SIP 1 SIP 2CNG - SIP Proxy B2BUA
INVITE (local SIP URI_2)
INVITE (local SIP URI_2)
1xx
1xx
200 OK
200 OK
ACK
ACK
RTP/RTCP
SIP 1 SIP 2CNG - SIP Proxy B2BUA
INVITE (local SIP URI_2)
INVITE (local SIP URI_2)
1xx
1xx
200 OK
200 OK
ACK
ACK
RTP/RTCP
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)27
b) OK with restriction:
a) The initial SIP message is modified (incompatible codecs are suppressed from SDP part) and then forwarded.
b) The session can be established with an acceptable codec for network resource.
c) Not OK:
a) The B2BUA rejects the session establishment.
NOTE: The SIP profiles can be different from one side of the B2BUA to another.
Figure 12: Admission Control within the CNG
7.4 Remote Access flows
7.4.1 Remote access basic architecture
L2
CNG
Caller CNG SIP Proxy B2BUA Callee
SIP message with a SDP offer
1. Analysis of L2 available resources2. Analysis of announced codecs 3. Selection of the codecs compatible with available
bitrate
If CAC returns that all announced codecsare compatible with availablebitrate , the SIP message is forwardedwithout modification
If no codec is compatible with available bitrate, SIP error responseis sent
If CAC returns that some codecs are incompatible with available bitrate , the SIP-IMS proxy modifies the original SDP by suppressing these codecs and forwarding this modified SIP message
CND
LAN WAN
SIP
Codec reference •G711:bitrate = 100Kbps ; cpu=7%
•G722:bitrate = 100Kbps ; cpu =7% •G729:bitrate = 45Kps ; cpu = 5%
•H263:bitrate = 156Kbps ; cpu=9%
SIP
Dynamical pointers # bitrate
#CPU
ACF
media
CNG SIP Proxy
B2BUA
CNG
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)28
7.4.1.1 Remote Access Connection Set-up
This clause describes one procedure where information of which CND's are registered in the CNG and therefore accessible via Remote Access, is retrieved by the remote UE. The UE provides an application linking the procedures for Remote Access services.
Figure 13: Remote Access Connection Setup
Prerequisite, the CND in the CPN has to be registered (e.g. using UPnP or similar procedure) to the CNG before the following take place:
1) The remote access menu initiates SIP INVITE to the users home CNG. The request is granted by the IMS NW and sent to CNG.
2) CNG checks if the request shall be granted. It initiates mapping of addresses and ports and prepares for the remote access procedures by returning SIP 200 OK.
Optionally a secure tunnel is then setup between the remote UE and the CNG.
3) HTTP GET carries (e.g. DLNA or similar procedure) requesting CND information including device types and identities to be provided.
4) CNG checks its present CND registrations, DB info (e.g. DLNA or similar) and returns the CND's device type, identity and pointer to CND in HTTP 200 OK.
5) This session is terminated with SIP BYE.
The Remote UE now holds the list of available CND's, their identities and types. The end user chooses the CND of interest and initiates a new session according to the following.
6) SIP INVITE is now sent addressing the CND (in the SDP part). The request is granted by the IMS NW and sent to the CNG.
7) CNG checks if the request shall be granted. It initiates mapping of addresses and ports and prepares for the remote access procedures by returning SIP 200 OK. Optionally a secure tunnel is then setup between the remote UE and the CNG.
NOTE: This initiated session will be terminated (SIP BYE) in the end of the sequence.
7.4.1A Remote Access Connection Set-up using secure tunnel connection
This clause describes one procedure where a Remote Access connection is established. The clause describes one procedure where information of which CND’s are registered in the CNG and therefore accessible via Remote Access, is retrieved by the remote UE. The UE provides an application linking the procedures for Remote Access services.The initial setup establishes the connection between the two peers, the UE and the CNG. In later clauses the procedure regarding the establishment of the second tunnel is described.
Figure 13A: Remote Access Connection Setup
Prerequisite, in order to not have an empty device list, the CND’s in the CPN have to be registered (e.g. using UPnP™) to the CNG before the following take place:
1) The UE using the remote access menu initiates a SIP INVITE towards the Home CNG. The request is granted by the IMS core and sent to CNG.
2) CNG checks if the request shall be granted. It initiates mapping of addresses and ports and prepares for the remote access procedures by returning SIP 200 OK.
3) SIP ACK is sent to acknowledge the Remote Access session setup.
4) If no keys for the tunnel where distributed in the SDP part the key management procedures commence agreeing on keys and tunnel type.
5) A secure tunnel is setup between the remote UE and the CNG enabling Remote Access services.
6) After tunnel establishment then any side may send synchronisation messages. Traffic is then enabled and will be transferred between the two peers using the established tunnel connection carrying both e.g. the UPnP signalling as well as e.g. the UPnP media transfer.
7) If the Remote Access session is to be terminated, SIP BYE is sent.
(3) SIP ACK
Remote UE IMS CNG CND CND
(1) SIP INVITE:(Home CNG) SIP INVITE:(Home CNG)
CNG – CND Info exchange
CNG – CND Info exchange
(2) SIP 200 OK SIP 200 OK
(4) Key Management Procedure
(5) Establishment of VPN Tunnel
(7) SIP BYE
(6) Synchronization of Device List, Push, Pull, etc
SIP ACK
SIP BYE
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)30
7.4.1B Media delivery using multiple tunnel connection
This clause describes a procedure which may be used to establish multiple tunnel connections.
The clause describes the procedure where content is delivered from a particular CND to the remote UE. The information about which CND’s are available has been retrieved during the connection setup procedure. Prerequisite is the RA Connection set-up procedure displayed in chapter 7.4.1.
During the initial phase the CNG realizes that a new media stream between the UE and the CPN needs assurance of QoS. A second tunnel connection setup is therefore initiated for providing adequate QoS for the media delivery.
1) The CNG recognises the QoS request (e.g. for UPnP) from the CND. The request is evaluated and granted for the CPN. The CNG then initiates a SIP Re-INVITE towards the Remote UE. The request contains the QoS parameters sufficient for the media delivery connection. If the request is accepted by the IMS core it is sent further to the UE.
2) The UE checks if the request shall be granted. It prepares for the multiple tunnel procedures by returning SIP 200 OK.
3) SIP ACK is sent to acknowledge the multiple tunnel session setups.
4) Optionally, if no keys for the tunnel where distributed in the SDP part the key management procedures commence agreeing on keys and tunnel type.
5) A secure tunnel is setup between the remote UE and the CNG now enabling the multiple tunnel connection for the Remote Access service.
6) After tunnel establishment the media could be transferred between the two peers using the established connection. The tunnel will be used for e.g. UPnP media transfers.
SIP ACK
Remote UE IMS CNG CND
(1) SIP Re-INVITE:(Remote UE) e.g. UPnP: QoS request
SIP 200 OK (2) SIP 200 OK
(4) Optional: Key parameters exchange
(5) Establishment of VPN Tunnel
(7) SIP Re-INVITE
(6) Tunnel used for Media transfers.
(3) SIP ACK
SIP Re-INVITE
SIP Re-INVITE:(Remote UE)
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)31
7) When the multiple tunnel connection is not used, the second tunnel can be terminated by sending SIP Re-INVITE tearing it down.
The initial tunnel still exists according to clause 7.5 and Remote Access services are provided.
If the complete Remote Access session is to be terminated, SIP BYE is sent tearing down the whole connection including the initial tunnel as well.
7.4.1.2 Download of content using HTTP
This clause describes the procedure where content is downloaded from a particular CND to the remote UE. The information about which CND's are available has been retrieved during the connection setup procedure. The UE provides an application linking the procedures for Remote Access services.
Prerequisite is the RA Connection set-up procedure displayed in clause 7.4.1:
1) The Remote UE points out the CND of interest using the path descriptor received under point 4 in clause 7.3.1.
2) CND sends an acknowledgement back to the Remote UE also indicating where to retrieve additional info.
3) The Remote UE sends a request (e.g. UPnP or similar) to the CND for additional device and service information.
4) CND responds with information about the services supported in the device.
5) The Remote UE browses the directories (e.g. with UPnP or similar procedure) where available content for download are located and makes a choice.
6) CND is responding with information (e.g. UPnP or similar) about the content URL/URI.
7) The Remote UE requests the download of data by addressing the content URL/URI.
8) The particular file is downloaded to the UE.
9) The connection is terminated with SIP BYE tearing down the session initiated by SIP INVITE in RA Connection setup described in clause 7.3.1, point 6.
In case of consecutive download requests the first four steps do not need to be repeated if the CND device and service information is cached in the Remote UE.
In the following flows the HTTP protocol is shown as an example although other alternative choices could be considered.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)32
Remote UE IMS Core Network
(1) HTTP GET (Path Descriptor)
(5) HTTP (Content Directory Browse)
(7) HTTP GET (URL to content)
(9) SIP BYE
Connection setup procedure
(2) HTTP 200 OK
(3)HTTP GET (Device and service info)
(4) HTTP 200 OK
(8) HTTP 200 OK (Content download)
(6) HTTP (Content URL)
CNG CND
Figure 14: Download of content using HTTP
7.4.1.3 Upload of content using HTTP
This clause describes the procedure where content is uploaded to a particular CND from the remote UE. The information about which CND's are available has been retrieved during the connection setup procedure. The UE provides an application linking the procedures for Remote Access services.
Prerequisite is the RA Connection Setup procedure in clause 7.4.1:
1) The Remote UE points out the CND of interest using the path descriptor received under point 4 in clause 7.3.1.
2) CND sends an acknowledgement back to the Remote UE also indicating where to retrieve additional information.
3) The Remote UE sends a request (e.g. UPnP or similar) to the CND for additional device and service information.
4) CND responds with information about the services supported in the device.
5) The Remote UE browses the directories where content can be uploaded.
6) CND is responding with information about the content directory URL/URI.
7) The user selects the folder where content will be uploaded. An object is created for the pending file.
8) The Object description and URL/URI address is received by Remote UE.
9) The particular file (object) is uploaded to the CND.
10) CND is acknowledging the upload of content.
11) Disconnection is initiated with SIP BYE terminating the session initiated by SIP INVITE in RA Connection setup described in clause 7.3.1, point 6.
In case of consecutive upload requests the first four steps do not need to be repeated if the CND device and service information is cached in the Remote UE .
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)33
In the following flows the HTTP protocol is shown as an example although other alternative choices could be considered.
(1) HTTP GET (Path Descriptor)
(5) HTTP (Content Directory Browse)
(9) HTTP POST (Content)
(11) SIP BYE
Connection setup procedure
(2) HTTP 200 OK
(3) HTTP GET (Device and service info)
(4) HTTP 200 OK
(10) HTTP 200 OK
(6) HTTP (Content URL)
(7) HTTP (Create Object)
(8) HTTP 200 OK (URL and Object Id)
Remote UE IMS Core Network
CNG CND
Figure 15: Upload of content using HTTP
7.4.2 Remote Access using UPnP functionalities Ed's note: the security aspects have to be analysed for impacts.
This clause describes an architecture for Remote Access between two CPNs or between a Remote UE and a CPN using UPnP functionalities. The solution is based on two new functions in the CPN, which could be part of the CNG-PPF: the UPnP Reverse Proxy (RP) and the UPnP Virtual Media Server (VMS). We define these two new functions for allowing privacy for the shared house and usability for Remote UE.
The aim of the UPnP Reverse Proxy is to filter UPnP Requests on directory but also on actions for a Remote UE: For example, in case of a content sharing between two CPNs (User B accessing remotely to User A content), the UPnP Reverse Proxy in User A CPN will allow to browse and get content actions for the Remote UE and avoid delete, move…
On the other side (Remote UE CPN), the role of the UPnP VMS is to announce the CPNs where a user is sharing something for the Remote UE. UPnP VMS is compliant with UPnP A/V Media Server [MediaServer:3 Device Template Version 1.01]. If a UE contains bothand (for instance a mobile), then the same architecture could be used without going through a CNG
Two kinds of Access Control Lists (ACL) are introduced:
1) Sharing rules authorize User A to establish a session with User B. These rules are setup by User B. 2) The filtering rules govern which folder / files a User B share with User A. These rules are also setup by User B.
Both sharing and filtering rules are stored in User B UPnP RP. Only sharing rules are exported to the Remote Access AS functionality.
The Remote Access AS functionality could be a dedicated AS, a presence AS or located in the CNG. Indeed when User A shares content with User B it could be seen as a presence as user A content is available for user B. The RA AS has the following functionalities:
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)34
1) Presence by publishing a list of contents available for User B (see procedure n°1), according to the User A sharing rules. This functionality could be part of the CNG or be located in the IMS Network.
2) CPN Access Control by deciding whether or not a Remote UE is allowed to connect to a CPN. This
functionality could be part of the CNG or be located in the IMS Network.
3) check service rights (see procedure n°3). This functionality shall be located in the IMS Network In the following figure, the whole functionalities of the RA AS are co-located in the IMS Network.
Figure 16: Remote Access using UPnP functionalities, with the Remote Access AS functionalities co-located in the NGN Network
The procedures in the above figure are the following:
(0) User A, who wants to share content has to select a repository on a CND and add filtering & sharing rules on CNG UPnP RP
(1) CNG UPnP RP notifies the Remote Access AS that User A wants to share content with User B. These actions could be implemented by means of SIP presence messages if the Remote Access AS implements presence service, i.e users first subscribe to the Remote Access Service, then when User A publishes a new sharing rule with User B, the Remote Access AS notifies the User B with a remote access proposal from User A. Alternatively these actions could also be implemented by means of HTTP message if the RA AS supports web based service (HTTP server). In other words, CNG UPnP RP could send sharing rules to RA AS using HTTP protocol. In that case, notification to User B is not needed. User B directly asks the RA AS for a list of available content.
(2) Prerequisites : the UPnP VMS has the list of all CPNs sharing content with User B. (Using presence enabler or dedicated request from the Remote Access AS). User B browses UPnP VMS, then all the Remote CPNs are displayed on his UPnP MP as directories of UPnP VMS. User B selects User A directory. Alternatively when User B browses UPnP VMS then the UPnP VMS retrieves accessible CPN and contents list from RA AS (sent to User B CPN by CPN), and all the available contents on the User A Remote CPN are displayed on the User B UPnP MP
(3) A SIP INVITE is sent from CNG B to CNG A, to establish a new media session between the User A and User B. The IMS Network checks if CNG B and also CNG A have the RA service rights (for example the operator or owners may have the ability to switch on/off this functionality). Then the IMS Network triggers the Remote Access AS (located in the IMS Network), which checks if that User B can access to the CPN of the User A. If
User A CPN with shared content User B Remote CPN
RA AS
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)35
yes a SIP session is opened between CNG B and CNG A, so as to identify User B, and negotiate HTTP parameters. Indeed media flows are exchanged between CNG B and CNG A using HTTP so as to avoid HTTP/RTP translation (in case RTP would be used to convey media flows through the IMS Network).
(4) UPnP VMS sends a browse request to User A CNG (based on the SIP session defined before). UPnP RP sends back a UPnP answer with all shared directories for User B. On his CND, User B selects a directory. Request is forwarded by the UPnP VMS to the UPnP RP.
(5) Based on filtering rules, UPnP RP forwards the request to the apropriate CND in the User A CPN. (6) User B selects a Content to play, then a Re-INVITE SIP session may be sent from CNG B to CNG A, to
negociate the media to be shared (and send back the content URL to User B) and possibly QoS parameters. In the case when media/QoS negociation wouldn't be needed, the content URL could be sent to UserB during the browsing session, no need for a Re-INVITE then.
NOTE 1: In the following parts A and B SIP UAs could be either in the CND or embeded in the A and B CNG-SIP Proxy B2BUA functionality. UPnP Reverse Proxy (UPnP RP) and UPnP Virtual Media Server (VMS) are embeded in the CNG-Plug and Play function (CNG-PPF). NOTE 2: In the example above a Re-INVITE is used to transfer the content URL from User B to User A. An alternative approach is to use the filtering rules to construct a combined listing of shared directories and content URLs when responding to the browsing in (4). The upside to this is that no Re-INVITE is necessary when accessing the content, which reduces the delay. The downside is that no specific QoS parameters can be applied on a per-content basis.
7.4.2.1 Remote Access AS database configuration with access rights
This clause describes one procedure where a User defines a shared content to another user ( (0) & (1) steps in chapter 7.4.2).
Prerequisite : the B SIP UA sends a SIP Subscribe to the Remote Access AS
Figure 17: Remote Access AS database configuration by User A, with the Remote Access AS functionalities co-located in the NGN Network
NOTE: the Address Book is located in the Network, and could be duplicated in the User A CPN.
SIP dialogues
http dialogues
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)36
7.4.2.2 Remote Access set-up
This clause describes one procedure where a CNG UPnP VMS retrieves the shared CPNs ( (2) and partially (3) steps in chapter 7.4.2).
If the architecture is based on presence solution the User B CNG will receive a SIP Notify each time someone shares one content with it. Else (in case of Remote Access AS with Database) the UPnP VMS has to request the Remote Access AS presence functionality to retrieve all the CPNs on which content is available.
7.4.2.3 Remote Browsing
This clause describes a procedure which may be used to establish remote access browse session between two CPNs (partially (3) , (4) & (5) steps in chapter 7.5.2).
The clause describes particularly the procedure when shared folders are delivered from a UPnP Reverse Proxy to the Remote UE CND. Prerequisites: SIP UA is already registered by means of SIP REGISTER message in the IMS Network, so it can be directly contacted through its sip URI. Presence enabler could be used to informe about presence of shared content from contacts.
Figure 18: Remote browsing from User B on User Media Server
CNG internal dialogues
SIP dialogues
http dialogues
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)37
7.4.2.4 Media Delivery
This clause describes a procedure which may be used to establish remote access get content session between two CPNs or one CPN and a mobile. The clause describes particulary the procedure when shared content is delivered from a UPnP MS to the remote device, and the Re-INVITE approach mentioned in 7.4.2 is used. Prerequisites: Remote Browsing procedures have already been done.
A filtering can be performed by the User A UPnP RP as soon as the GetContent command is received, so as to prevent User B from changing the URL and access to an unauthorized content. Another filtering can be done on the kind of HTTP request sent to the UPnP RP: only "GET" and "BROWSE" could be authorized for User B, except if User B is User A (i.e. User A in a nomadic situation) for instance, in that case "DELETE", "PUT" could be authorized.
Figure 19: Media delivery, using a Re-INVITE approach to transfer content URLs
http dialogues
CNG internal dialogues
SIP dialogues
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)38
Annex A (informative): Bibliography ETSI TR 180 000: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Terminology".
IETF NAPT traversal Working Groups: BEHAVE for STUN TURN methods, MMUSIC for ICE, SIP for SIP Outbound.
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)39
Annex B (informative): Change History
Date WG Doc. CR Rev
CAT Title / Comment Current Version
New Version
Publication 2.3.1 Base draft for Release 3 (work item reference
update) 2.3.1 3.0.0
April 2009
WG5-07-005-R2 001 2 B WI05027: RA Multiple Tunnel flow 3.0.0 3.0.1
CR001 TB approved at TISPAN#21 + Update of clause and figure numbering
3.0.1 3.1.0
June 2010
002 1 B TS185003_CR_On_Remote_Access_using UPnP 3.1.0 3.1.1
ETSI
ETSI TS 185 003 V3.1.1 (2010-06)40
History
Document history
V2.0.0 March 2008 Publication
V2.3.1 June 2009 Publication
V3.0.0 August 2009 Input draft for R3
V3.0.1 August 2009 Provisional output draft for R3 including the CR WG5-07-005-R2 and editorial modifications approved during the TISPAN #21 meeting
V3.1.0 August 2009 CR001 TB approved at TISPAN#21 + Update of clause and figure numbering
V3.1.1 June 2010 CR002 TB approved at TISPAN#24-bis meeting
