ETSI TS 103 161-17 V1.1.1 (2011-04)

Access, Terminals, Transmission and Multiplexing (ATTM); Integrated Broadband Cable and Television Networks; IPCablecom 1.5; Part 17: CMS Subscriber Provisioning Specification

DTS/ATTM-003011-17

General Information

• Status: Published
• Publication Date: 12-Apr-2011
• Technical Committee: ATTM AT3 - Integrated broadband cable and television networks
• Current Stage: 12 - Completion
• Due Date: 03-Mar-2011
• Completion Date: 13-Apr-2011

Standards Content (Sample)

Technical Specification
Access, Terminals, Transmission and Multiplexing (ATTM);
Integrated Broadband Cable and Television Networks;
IPCablecom 1.5;
Part 17: CMS Subscriber Provisioning Specification

2 ETSI TS 103 161-17 V1.1.1 (2011-04)

Reference
DTS/ATTM-003011-17
Keywords
access, broadband, cable, IP, multimedia, PSTN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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.

© European Telecommunications Standards Institute 2011.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP 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.
ETSI
3 ETSI TS 103 161-17 V1.1.1 (2011-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Void . 9
5 Technical Overview . 9
5.1 Void . 9
5.2 IPCablecom Reference Architecture . 9
5.3 Components and Interfaces . 10
5.4 Components . 11
5.4.1 Back Office Components (Service Provider Business and Service Management Systems) . 11
5.4.2 Provisioning Server. 11
5.4.3 CMS . 11
5.4.4 MTA . 11
5.4.5 TFTP . 11
5.5 Interface Descriptions . 11
5.5.1 Pkt-p1 . 11
5.5.2 Pkt-p4 . 11
5.5.3 Pkt-prov-p1 . 11
6 Assumptions . 12
7 Subscriber Provisioning . 12
7.1 Customer Records (Billing) . 12
7.2 Equipment Setup and Configuration . 12
7.2.1 CMS Basic POTS Provisioning (BPP) . 12
7.2.2 CMS Call Feature Provisioning (CFP) . 12
7.3 Static Versus Dynamic Subscriber Provisioning Data . 13
8 Requirements . 13
8.1 General Requirements . 13
8.2 Transport Requirements . 13
9 Data Model . . 14
9.1 Overview . 14
9.1.1 PcspService Object . 15
9.1.2 PcspMta Object . 15
9.1.3 PktcEndpoint Object . 16
9.1.4 PktcCMS Object . 16
9.1.5 Inter Object Relationships . 16
9.2 Relations are encoded using the PcspRelation entity.XML Encoding . 16
9.2.1 The PCSP XML Schema . 17
9.2.2 Sample PCSP Entity Encodings. 17
9.2.3 Object Extensions . 17
10 Messaging . 17
10.1 Overview . 17
10.2 CMS and PS Messaging Role Requirements . 18
10.3 WSDL Document . 19
11 Security. 19
ETSI
4 ETSI TS 103 161-17 V1.1.1 (2011-04)
Annex A (normative): PCSP XML Schema . 20
Annex B (informative): Sample Entity Encodings . 37
B.1 PcspService Object Example . 37
B.2 PcspEndpoint Object Example . 39
B.3 PcspMTA Object Example . . 39
B.4 PcspCMS Object Example . 39
B.5 PcspRelation Example . . 39
Annex C (informative): Sample Object Extension . 41
C.1 Extended PcspService Object Example. 41
C.2 The Extension Schema . 42
Annex D (normative): WSDL Document For PCSP Messaging . 43
Annex E (informative): Data Encoding Evaluation . 47
E.1 XML . 47
E.2 ASN.1/BER . . 47
E.3 Proprietary ASCII . 47
E.4 SDP (session description protocol) . . 47
E.5 RADIUS . . 48
E.6 SQL . 48
E.7 Options Summary . 48
E.8 Recommendation: XML . 48
Annex F (informative): Transport Protocol Evaluation . 49
F.1 TFTP with IPsec . 49
F.2 Batched RADIUS - multiple records in single request via event msgs . 49
F.3 Diameter . 49
F.4 Distributed Object Systems . 49
F.4.1 CORBA/IIOP . 49
F.5 DCOM . 50
F.6 HTTP . 50
F.7 Options Summary . 51
F.8 Recommendation: HTTP 1.1 . 51
Annex G (informative): Bibliography . 52
History . 53

ETSI
5 ETSI TS 103 161-17 V1.1.1 (2011-04)
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 Access, Terminals, Transmission
and Multiplexing (ATTM).
The present document is part 17 of a multi-part deliverable covering Access, Terminals, Transmission and Multiplexing
(ATTM); Integrated Broadband Cable and Television Networks; IPCablecom 1.5, as identified below:
Part 1: "Overview";
Part 2: "Architectural framework for the delivery of time critical services over cable Television networks using
cable modems";
Part 3: "Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television
Networks using Cable Modems";
Part 4: "Network Call Signalling Protocol";
Part 5: "Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks
using Cable Modems";
Part 6: "Event Message Specification";
Part 7: "Media Terminal Adapter (MTA) Management Information Base (MIB)";
Part 8: "Network Call Signalling (NCS) MIB Requirements";
Part 9: "Security";
Part 10: "Management Information Base (MIB) Framework";
Part 11: "Media Terminal Adapter (MTA) device provisioning";
Part 12: "Management Event Mechanism";
Part 13: "Trunking Gateway Control Protocol - MGCP option";
Part 14: "Embedded MTA Analog Interface and Powering Specification";
Part 15 "Analog Trunking for PBX Specification";
Part 16: "Signalling for Call Management Server";
Part 17: "CMS Subscriber Provisioning Specification";
Part 18: "Media Terminal Adapter Extension MIB";
Part 19: "IPCablecom Audio Server Protocol Specification - MGCP option";
Part 20: "Management Event MIB Specification";
ETSI
6 ETSI TS 103 161-17 V1.1.1 (2011-04)
Part 21: "Signalling Extension MIB Specification".
NOTE 1: Additional parts may be proposed and will be added to the list in future versions.
NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future
enhancements.
ETSI
7 ETSI TS 103 161-17 V1.1.1 (2011-04)
1 Scope
The present document defines the interface used between the Call Management Server (CMS) and Provisioning Server
(PS) for the exchange of service provisioning information. The interface employs a Web Service model. Specified in
Web Service Description Language 1.1 (WSDL 1.1), the interface transports XML encoded objects within Simple
Object Access Protocol 1.1 (SOAP 1.1) encoded messages over an HTTP 1.1 transport. This interface is secured via
IPSec.
The data model transported upon this interface is specifically designed to be extensible, allowing incorporation of as yet
undefined IPCablecom features and specific vendor extensions.
The scope of the present document is limited to the provisioning of an IPCablecom CMS by a single service provider.
Additionally:
• The CMS provisioning interface is limited to the exchange of service activation data between the CMS and the
PS. The interface between the PS and the back-office Operations Support System (OSS) is out of scope.
• CMS element management and network element provisioning (dial plans, etc.) are out of scope.
• Customer record creation/billing is considered part of the back-office OSS application and is currently out of
scope.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
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 necessary for the application of the present document.
[1] PacketCable 1.5 PKT-TR-ARCH1.5-V02-700412: "Architecture Framework Technical Report",
April 12 2007, Cable Television Laboratories, Inc.
[2] PacketCable 1.5 PKT-SP-PROV1.5-I04-090624: "MTA Device Provisioning Specification",
June 24 2009, Cable Television Laboratories, Inc.
[3] PacketCable 1.5 PKT-SP-SEC1.5-I03-090624: "Security Specificaiton", June 24 2009, Cable
Television Laboratories, Inc.
[4] Void.
[5] Void.
[6] Void.
ETSI
8 ETSI TS 103 161-17 V1.1.1 (2011-04)
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Web Services Description Language.
NOTE: Available at http://www.w3.org/TR/wsdl.
[i.2] Simple Object Access Protocol.
NOTE: Available at http://www.w3.org/TR/SOAP.
[i.3] XML Protocol.
NOTE: Available at http://www.w3.org/2000/xp.
[i.4] DOCSIS SP-CMCI-C01-081104: "Data-Over-Cable Service Interface Specifications, Cable
Modem to Customer Premise Equipment Interface Specification, CMCI, November 4, 2008,
Cable Television Laboratories, Inc.
[i.5] IETF RFC 1123: "Requirements for Internet Hosts - Application and Support".
[i.6] Extensible Markup Language (XML) 1.0.
NOTE: Available at: http://www.w3.org/TR/REC-xml.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
active: service flow is said to be "active" when it is permitted to forward data packets
NOTE: A service flow must first be admitted before it is active.
endpoint: Terminal, Gateway or Multipoint Conference Unit
Internet key exchange: key-management mechanism used to negotiate and derive keys for SAs in IPSec
local number portability: allows a customer to retain the same number when switching from one local service
provider to another
media gateway: provides the bearer circuit interfaces to the PSTN and transcodes the media stream
pre-shared key: shared secret key passed to both parties in a communication flow, using an unspecified manual or
out-of-band mechanism
registration, admissions and status: RAS Channel is an unreliable channel used to convey the RAS messages and
bandwidth changes between two H.323 entities
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA Authentication, Authorization and Accounting
BPP Basic POTS Provisioning
CFP Call Feature Provisioning
CM DOCSIS Cable Modem
CMS Call Management Server
ETSI
9 ETSI TS 103 161-17 V1.1.1 (2011-04)
CMS Cryptographic Message Syntax
CMTS Cable Modem Termination System
Codec COder-DECoder
CSR Customer Service Representative
DOCSIS Data-Over-Cable Service Interface Specifications
DQoS Dynamic Quality of Service
ESP IPSec Encapsulating Security Payload
FQDN Fully Qualified Domain Name
HTTP Hypertext Transfer Protocol
IETF Internet Engineering Task Force
IKE Internet Key Exchange
IP Internet Protocol
IPSec Internet Protocol Security
LNP Local Number Portability
MGCP Media Gateway Control Protocol
MIB Management Information Base
MTA Multimedia Terminal Adapter
NCS Network Call Signalling
OSS Operations Support System
PCSP IPCablecom CMS Subscriber Provisioning
PS Provisioning Server
PSTN Public Switched Telephone Network
RAS Registration, Admissions and Status
RFC Request for Comments
SDP Session Description Protocol
SNMP Simple Network Management Protocol
SOAP Simple Object Access Protocol
STP Signalling Transfer Point
TFTP Trivial File Transfer Protocol
TLV Type-Length-Value
UDP User Datagram Protocol
4 Void
5 Technical Overview
5.1 Void
Figure 1: Void
5.2 IPCablecom Reference Architecture
Figure 2 shows the reference architecture for the IPCablecom 1.5 Network. Refer to the Architecture Document [1] for
more detailed information on this reference architecture.
ETSI
10 ETSI TS 103 161-17 V1.1.1 (2011-04)
Call
Embedded MTA
Announcement Server
Management
Cable
Server
MTA Announcement Controller
Modem
(CMS )
(ANC)
HFC access
Announcement Player
network CMTS
(AN P)
(DOCSIS)
Signalling
Gateway
(SG)
Managed IP Network
Media
PSTN
Gateway
Controller
(MGC)
Media
HFC access
Gateway
CMTS
network
(MG)
(DOCSIS)
Key Distribution Server (KDC)
Embedded MTA
Provisioning Server
Cable
DHCP Servers
MTA
Modem OSS
DNS Servers
Backoffice
TFTP or HTTP Servers
SYSLOG Server
Record Keeping Server (RKS)
Figure 2: IPCablecom 1.5 Network Component Reference Model
5.3 Components and Interfaces
Provisioning is defined as the operations necessary to provide a specified service to a customer. IPCablecom service
provisioning can be viewed as two distinct operations: MTA provisioning and CMS subscriber provisioning. Figure 3
presents the provisioning related interfaces maintained by the PS and other authorized Back Office Components to
various IPCablecom elements. Interfaces not explicitly labelled are undefined and out of scope for IPCablecom.
The present document is intended to set the requirements for the provisioning interface between the CMS and the PS or
optionally other authorized Back Office Components (see Pkt-prov-p1 in figure 3).
Back Office
Components
(Vendor Dependent Interfaces)
Pkt-Prov-p1
Pkt-Prov-p1
CMS PS TFTP/HTTP
Pkt-p1
Pkt-p4
MTA
Figure 3: Provisioning Component Interfaces
ETSI
11 ETSI TS 103 161-17 V1.1.1 (2011-04)
5.4 Components
5.4.1 Back Office Components (Service Provider Business and Service
Management Systems)
These are the Back Office Components that a service provider uses to manage customers and other components that
make up their business. These systems provide the IPCablecom provisioning process with service orders or optionally
individual workflow tasks to activate services for customers. These systems may also receive accounting or usage data
used to create customer-billing events.
5.4.2 Provisioning Server
This system forms the interface between the provider's Back Office Components and some or all of the IPCablecom
elements. IPCablecom does not address the implementation of this system or its relationship to other OSSs that a
service provider might employ.
The Provisioning Server is defined in [2] as consisting of a provisioning application that contains provisioning logic and
a provisioning SNMP entity that provides access to active components. Here we will refer to the Provisioning Server
without distinguishing between these two entities.
5.4.3 CMS
The Call Management Server component is described in [1]. This component provides call control and signalling-
related services for the MTA and CMTS components in the IPCablecom network.
5.4.4 MTA
A Media Terminal Adapter is an IPCablecom client device that contains a subscriber-side interface to the customer's
CPE (e.g. telephone) and a network side signalling interface to call control elements in the network. This component is
described in [1].
5.4.5 TFTP
A configuration file service that is the basis for most device configuration in an IPCablecom network. This could be a
standalone TFTP Service that delivers statically-defined files to devices or a dynamic service that creates configurations
on-the-fly from other data sources.
5.5 Interface Descriptions
5.5.1 Pkt-p1
This interface is defined in [2].
5.5.2 Pkt-p4
This interface is defined in [2].
5.5.3 Pkt-prov-p1
The interface defined in the present document.
ETSI
12 ETSI TS 103 161-17 V1.1.1 (2011-04)
6 Assumptions
• The Back Office components is responsible for coordinating endpoint updates with affected network entities
(MTAs, CMTSs, etc.) and the CMS.
• CMS will not play a manager role nor does it specify SNMP communications to an MTA during CMS
provisioning.
• The CMS and PS reside in the same secure provisioning domain. Security related information will be outlined
in the Security Document [3].
7 Subscriber Provisioning
Subscriber provisioning consists of:
• Customer record/billing support.
• Equipment setup/configuration.
7.1 Customer Records (Billing)
Establishment of a customer record that contains the information needed to deliver service, bill, and collect payment
from a customer. Customer record creation/billing is considered part of the back office OSS application and is currently
out of scope for IPCablecom.
7.2 Equipment Setup and Configuration
This may include physical installation and/or connection of equipment as well as any software and/or database updates
necessary to actually deliver the service to the customer. Equipment setup affects two major components in an
IPCablecom environment:
• Customer premises equipment. For IPCablecom, this is the MTA. The provisioning for the MTA is defined
in [2] and will not be discussed in the present document.
• Call Management Server. Provisioning of the CMS itself can be broken down into two main areas: basic POTS
provisioning and call feature provisioning.
7.2.1 CMS Basic POTS Provisioning (BPP)
BPP provides the CMS with the minimal set of data necessary for routing of simple telephony service (POTS) in the
IPCablecom network. This minimal set of data consists of a telephone number mapped to its associated MTA's FQDN
and NCS endpoint identifier. This data will be used to setup translation tables enabling the CMS to route calls to the
appropriate device/port given a specific telephone number. BPP provisioning for each customer is required before that
customer can receive any calls in an IPCablecom network.
7.2.2 CMS Call Feature Provisioning (CFP)
In addition to BPP, CFP is performed to provide call features to a customer. CFP is more complicated than BPP as the
parameters passed may vary on a feature-by-feature basis and may also be dependent on vendor specific
implementations.
ETSI
13 ETSI TS 103 161-17 V1.1.1 (2011-04)
7.3 Static Versus Dynamic Subscriber Provisioning Data
Data required by the CMS for subscriber provisioning falls into two classifications:
1) Static, billed, permanently assigned service state. This data does not change call to call. Examples would be
DQoS settings, call feature subscribed/non-subscribed states, caller ID information, etc.
2) Dynamic, non-billed, semi permanent service state. Often this information is subscriber alterable, either at an
endpoint via *XX key code or via a web interface into the CMS. An example would be the user settable
parameters of a call feature, such as Call Forward Busy Line (CFBL). The CFBL forwarding number is
dynamic, non-billed service state. The subscribed/non-subscribed state of CFBL is static data maintained by
the PS.
In the IPCablecom CMS/PS scope, the PS owns all static provisioning state, and the CMS owns all dynamic
provisioning state.
8 Requirements
8.1 General Requirements
• The interface shall make no assumptions regarding PS and CMS implementation technologies.

Multiple partnering vendors will undoubtedly provide CMS and PS implementations on various hardware,
software, and development language platforms. A platform and language neutral interface is required.
• The interface shall support Basic POTS Provisioning.

The interface's data model shall include the minimum amount of information required to support basic POTS
service.
• The interface shall support Call Feature Provisioning.

The interface's data model shall support subscription to any IPCablecom call feature.
• The interface's data model shall be extensible.

The present focus of the interface is telephony data. However, to the extent possible, the interface should be
extensible for future IPCablecom Multimedia services. It is desirable to have a single, extensible provisioning
data model and transport to support all IPCablecom features and capabilities, some of which are not yet
defined.
• The interface shall not impact any MTA operations in progress.

Endpoint specific data may be added, deleted, or modified on the MTA without affecting other MTA
endpoints or sessions in progress. CMS endpoint provisioning scenarios that would result in an endpoint/MTA
to be taken out of service must be carefully documented.
• The interface shall be capable of accommodating present (NCS) and future signalling protocols.
8.2 Transport Requirements
• The transport shall make no assumptions regarding the physical networking infrastructure between a PS and a
CMS.
It is anticipated that multiple service providers will be interoperating over a single access network. Thus,
multiple enterprises will be communicating, potentially using CMS and PS implementations from various
vendors, over various network infrastructures (firewalls, proxies, etc.). The CMS/PS transport protocol should
facilitate the ability to penetrate arbitrary network infrastructure.
• The transport shall support unidirectional transfer of single data model objects from the PS to the CMS.
ETSI
14 ETSI TS 103 161-17 V1.1.1 (2011-04)
• The transport shall support efficient streaming of multiple data model objects from the PS to the CMS.
• The transport may support unidirectional transfer of single data model objects from the CMS to the PS.
• The transport may support efficient streaming of multiple data model objects from the CMS to the PS.
• The transport shall include semantics to support new, updated, and removed data model objects.
• The transport shall support informational requests between PS and CMS.
• The transport shall handle conditions such as CMS busy, errors, etc.
• The transport shall provide positive/negative acknowledgement of operation received.

The transport shall implement an at-least-once type of message semantics. The sender shall not discard its
request until the receiver acknowledges it (acknowledgements are not acknowledged.) The transport must be
able to detect data corruption during transport, etc. and notify the sender of such conditions.
• The transport shall provide positive/negative acknowledgement of operation handled.
• The PS shall be able to initiate a transfer of data model objects ("push").
• The transport shall be secure.
9 Data Model
This clause provides a high level description of the PCSP data model and its XML encoding. It is intended as
descriptive and non-authoritative. The authoritative definition of the data model and its encoding is found in the PCSP
XML schema in annex A.
9.1 Overview
The data model for IPCablecom CMS provisioning is displayed in figure 4. It consists of two categories of entities:
• Objects.
• Relations between objects.
PcspCMS
-FQDN (key)
-Extensions
1 1
0.*
0.*
PcspService
-Service ID (key)
PcspMTA
-Billing ID
PcspEndpoint
-FQDN (key)
-IsPrimary flag
-Endpoint ID (key)
-Port
-AdminStatus
-AdminStatus
-CMTS FQDN
-Caller ID params
-Codec params
-Timezone
-Offnet PIC codes
-Protocol params
-Protocol params
0.* 0.1 1.*
-LNP params
-Extensions
-Codec params
-Announcement params
-Extensions
-Call Feature subscriptions
-Extensions
Figure 4: CMS Provisioning Data Model
ETSI
15 ETSI TS 103 161-17 V1.1.1 (2011-04)
The following entities shall be supported:
• The PcspService object is the entity to which an IPCablecom 1.5 customer subscribes. It represents a phone
number and all related functionality (call features, etc).
• A PcspMTA object represents a Media Terminal Adapter, which aggregates one or more endpoints physically
contained within the MTA.
• The PcspEndpoint object represents a physical endpoint on an MTA/Gateway.
• A PcspCMS object maintains associations between endpoints/CMSs and services/CMSs.
• PcspRelations represent associations between objects. In figure 4, they are presented as connections between
objects.
PcspService and PcspEndpoint are distinct objects in order to support multiple services (phone numbers) per endpoint.
Distinct PcspMta and PcspEndpoint objects allow an MTA's endpoints to be managed by different service providers.
The PcspCms object essentially maintains a collection of endpoints and services.
All objects are extensible.
9.1.1 PcspService Object
The service object is the entity to which an IPCablecom 1.5 customer subscribes. It represents a phone number and all
related functionality. The data model allows more than one service to be provisioned to a single endpoint.
The PcspService object contains the following generic information (for complete details, see the PCSP XML schema):
• ServiceId - a unique identifier for the service.
• BillingId - the identifier of another service, which will be billed for activity on this service.
• IsPrimary flag - with multiple services provisioned upon an endpoint, one service shall have this flag set to
indicate the default service to use for outgoing calls.
• PrimaryRingPattern - index into MTA cadence table, selecting a ring pattern for this service.
• Administrative status of this service (suspended, enabled, number has changed, etc.).
• DisplayName - the display information used for Call Name Delivery feature (CNAM).
• DisplayNumber - the display information used for Call Number Delivery feature (CND).
• Announcement settings (enable, language, time zone, etc.).
• Carrier codes (long distance carrier code, intra-lata carrier code, international carrier code).
• Local number portability control (porting status, STP lookup flag, etc).
• Call features - A service includes a list of subscribed call feature objects.
• Extensions - This object is extensible in two locations: the main body of the object and the call feature list.
9.1.2 PcspMta Object
A Media Terminal Adapter aggregates one or more endpoints (physically contained within the MTA). It contains the
following generic information (for complete details, see the PCSP XML schema):
• MTA's FQDN, uniquely identifying this MTA.
• MTA's NCS listener port (default: 2427).
• FQDN of controlling CMTS.
• Time zone within which this MTA is physically located.
ETSI
16 ETSI TS 103 161-17 V1.1.1 (2011-04)
• Signalling protocol designation. This is the default protocol selection for all contained endpoints, unless
overridden by an individual endpoint.
• Codec designation - default codec selection for all contained endpoints, unless overridden by an individual
endpoint.
• IPSec Control Flag - The IPSec Control Flag indicates whether IPSec is used for NCS Signalling between the
CMS and the MTA. By default, IPSec is turned on all endpoints, but can be provisioned otherwise on a per
endpoint basis.
• MTA Profile Name - Optional; An MTA Profile Indicator identifiable by the CMS.
• A single point for extension.
9.1.3 PktcEndpoint Object
An endpoint is a physical port on a MTA/Gateway. It contains the following generic information (for complete details,
see the PCSP XML schema):
• EndpointId - uniquely identifies this endpoint.
• Signalling protocol selection. Optionally overrides MTA setting.
• Administrative status of the endpoint (disconnected, normal service, test mode, etc.).
• Codec selection. Optionally overrides MTA setting.
• IPSec Control Flag - Optionally overrides the MTA setting.
• A single point for extension.
9.1.4 PktcCMS Object
This object maintains associations between Endpoints/CMSs and Services/CMSs. It contains the following generic
information (for complete details, see the PCSP XML schema):
• FQDN uniquely identifying this CMS.
• A single point for extension.
9.1.5 Inter Object Relationships
Within figure 4, the lines connecting the classes represent object "relations" (sometimes called associations). The
relations depicted in figure 4 shall be supported:
• Service/CMS. A typical CMS will own a block of phone numbers.
• Endpoint/CMS. An endpoint requires a CMS for signalling purposes.
• Service/Endpoint. A phone number must be attached to a physical endpoint.
• Endpoint/MTA. MTAs physically contain endpoints.
9.2 Relations are encoded using the PcspRelation entity.XML
Encoding
Objects of the data model will be encoded using XML.
ETSI
17 ETSI TS 103 161-17 V1.1.1 (2011-04)
9.2.1 The PCSP XML Schema
Annex A contains the PCSP XML schema. The schema defines the XML encoding syntax for the following entities (the
entities shall conform to the schema):
• The PcspService, PcspEndpoint, PcspMta, and PcspCms objects. These are the main data model objects.
• PcspRelation. This is used to establish or teardown relations between objects.
• PcspImportExport. A general purpose document format that can contain a large number of objects or relations.
This will typically be used to export full data sets from a PS to a CMS.
The schema should be employed by validating XML parsers to determine syntactic correctness of encoded entities.
9.2.2 Sample PCSP Entity Encodings
Sample XML encodings of all the PCSP data model entities can be found in annex B.
9.2.3 Object Extensions
The PCSP XML schema permits extensions for all objects (PcspService, PcspEndpoint, PscpMta and PcspCms).
Extensions are accomplished via the element placed in each object. Most objects specify this element at
the end of the main body of the object. PcspService includes an additional element at the end of the call
feature list.
There are a few simple rules for the element:
• All elements shall specify a namespace definition.
• All sub-elements of must be namespace qualified.
These two rules permit the XML parsing system to validate the content against a vendor supplied XML
schema file. Annex C contains an extension example.
10 Messaging
10.1 Overview
The PCSP interface follows a Web Service paradigm. The interface employs SOAP 1.1 messages to transfer XML
encoded entities (from the PCSP data model) between client and server. Messages are transported between client and
server using the HTTP 1.1 protocol. For a complete discussion of the transport considerations, see annex F.
The interface is modelled on a synchronous request/response pattern (or remote procedure call - RPC). The following
messaging patterns are supported between client and server:
• PUT message. Client writes one or more XML encoded objects or relations to the server. Both creation of new
objects and modification of existing objects are supported.
• DELETE message. Client requests one or more objects or relations be deleted from the server.
• GET message. Read one or more XML encoded objects from the server (objects only…relations are not
supported).
• CMDSTATUS message. Used to transfer "out of band" commands and status between the client and server.
Client can notify server of various state conditions. Client can command server to perform various actions.
This message is vendor extensible.
ETSI
18 ETSI TS 103 161-17 V1.1.1 (2011-04)
10.2 CMS and PS Messaging Role Requirements
In general, both CMS and PS may be implemented to fully support client and server messaging roles. However, within
the scope of IPCablecom CMS provisioning, the CMS and PS assume the role requirements specified in table 1.
Table 1: CMS and PS Messaging Roles
Message CMS as client CMS as server PS as client PS as server
GET OPTIONAL SHALL SHALL OPTIONAL
PUT OPTIONAL SHALL SHALL OPTIONAL
DELETE OPTIONAL SHALL SHALL OPTIONAL
CMDSTATUS SHALL SHALL SHALL SHALL

The following points should be noted:
• A CMS shall support the server role for GET, PUT and DELETE.
• A PS shall support the client role for GET, PUT and DELETE.
• CMS and PS shall support client and server roles for CMDSTATUS.
• All other behaviour is OPTIONAL.
These requirements enforce provisioning data flows from the PS to the CMS and also ensure that the CMS is not
required to push dynamic data changes (user adjustable call feature changes, etc.) back to the PS.
The PS is able to read specific objects from the CMS. This use case is supported primarily to allow the PS to retrieve
user call feature settings ("dynamic data") owned by the CMS. This is accomplished by reading specific PcspServic
...