SIST-TS ETSI/TS 101 909-12 V1.1.1:2005

• Abstract:

  Production of IPCablecom specification for the equivalence to J.165 suitable for the EU.

• Status: Published
• Publication Date: 31-Dec-2004
• ICS: 33.040.35 - Telephone networks
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Jan-2005
• Due Date: 01-Jan-2005
• Completion Date: 01-Jan-2005
• Ref Project: ETSI TS 101 909-12 V1.1.1 (2002-11) - Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 12: Internet Signalling Transport Protocol (ISTP)

SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 is the Slovenian adoption of ETSI TS 101 909-12 V1.1.1, a technical specification for the Internet Signalling Transport Protocol (ISTP). It specifies how IPCablecom elements carry SS7 ISUP and TCAP signalling over IP in a distributed cable-access architecture, mainly for cable operators, system integrators, and vendors building PSTN interworking equipment.

What does SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 specify?

SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 specifies ISTP for signalling interconnection between the IPCablecom control functions and the SS7 Signalling Gateway. In practice, it defines how SS7 ISUP and TCAP messages move between the IP side and the PSTN/ISDN side, and how the elements register, activate, map addresses, detect failures, and recover.

The document is organized into scope, references, definitions and abbreviations, signalling protocols, an overview and background section, architecture, functional areas, the protocol itself, and three informative annexes.

Annex	What it covers
Annex A	SCTP and TCP usage recommendations
Annex B	ISTP message flows and timer definitions
Annex C	Bibliography

The scope also states what sits outside ISTP: address layer management such as SNMP, security, measurements, implementation and vendor-dependent issues, and detailed CMS, MGC, and media-communication application design.

What are the key requirements of SIST-TS ETSI/TS 101 909-12 V1.1.1:2005?

SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 is mainly about reliable signalling transport, mapping between SS7 and IP identities, and controlled registration and recovery. The practical goal is that an operator can move call-control signalling between SS7 and distributed IP nodes without losing the ability to route, activate, deactivate, or recover traffic.

Transport and protocol stack

Clause 7 and clause 9 state that ISTP depends on a reliable underlying transport. SCTP is preferred, TCP is allowed as an option, and UDP is not acceptable for the intended reliability level. For an engineer, that means the signalling network must be built and tuned for dependable delivery, not treated like ordinary best-effort IP traffic.

Clause 9.1 also requires the use of raw ISUP and TCAP format when the Signalling Gateway connects to an ETSI-standard SS7 network. That matters because the IPCablecom side must comply with the ETSI ISUP and TCAP protocol as carried at the gateway boundary.

Registration, activation, and ownership

Clause 9.2 requires controlled registration of circuits and subsystems before they can be activated. Only one MGC element may be registered on a given circuit, and only one CMS/CA element may be registered for a given subsystem at the SG, although multiple nodes within the element can participate. In practice, this prevents conflicting ownership and makes failover deterministic.

The document also defines separate activation steps after registration. Registration validates the relationship, while activation actually allows traffic to flow. That split matters operationally because an operator can reserve resources first and bring them into service only when ready.

Mapping between SS7 and IPCablecom

Clause 8 and clause 9 define the mapping relationships that ISTP uses to route signalling. The important identities are SS7 point codes, circuit identification codes (CIC), subsystem identity numbers (SSN), MGC identifiers, IP communication addresses, and the ISTP Circuit Identity (CID). This means the gateway does not forward by address alone - it uses configured mappings to find the right MGC or CMS node.

For ISUP, the SG maps CID and related SS7 information to an IP destination. For TCAP, the SG uses the originating transaction identity information to route responses back to the right CMS or MGC node. That is what keeps transaction-based services, such as database queries, associated with the node that started them.

Failure detection, heartbeat, and congestion

Clause 8.6 and clause 9.3 require failure handling based on heartbeat and status reporting. ISTP uses heartbeat messages to detect whether a peer is still available, then switches to alternate communication addresses if needed. In practice, operators need multiple IP paths or addresses so that a single interface failure does not stop signalling.

Clause 8.13 and clause 9.3 also require congestion handling for both SS7 and IP-side conditions. The SG broadcasts congestion information to registered and active MGC and CMS elements, and the endpoints must react according to the interfacing SS7 requirements. This matters because signalling overload can affect call setup and database-query performance even when the transport link is still up.

Message format and parameter handling

Clause 9.4 defines the ISTP message structure with a message type, message nature, message length, and parameter blocks. Clause 9.5 then applies that structure to registration, activation, message transfer, heartbeat, and accessibility messages. An implementation must be prepared to receive parameters in any order, with mandatory parameters before optional ones.

The parameter definitions include items such as destination type, accessibility reason, transfer formats, routing label, party addresses, and quality of service. That tells implementers exactly what information must be carried when the SG forwards signalling or reports state.

Maintenance, initialization, and recovery

Clauses 8.5, 8.7, 8.10, and 8.12 define initialization, dynamic provisioning, maintenance, and alarms. ISTP supports cold start, element start, single-node start, and IP-only initialization, and it expects configuration data to remain consistent across nodes. It also defines maintenance actions such as enabling, disabling, waiting for traffic to clear, and restarting IP communications.

For recovery, the document distinguishes node recovery from element recovery. Node recovery is meant to preserve stable calls through a single node or path failure, while element recovery can move traffic to another element and may lose calls during the changeover. That distinction is important when planning redundancy and software replacement.

What terms does SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 define?

• Internet Signalling Transport Protocol (ISTP) - The protocol defined by this document for carrying SS7 signalling between the SS7 Signalling Gateway and IPCablecom control elements over IP.
• Signalling Gateway (SG) - The signalling agent at the edge of the IP network that translates and transports SS7 signalling for IPCablecom elements.
• Media Gateway Controller (MGC) - The control function that handles the trunk side of an IPCablecom communication and uses ISTP for SS7 interworking.
• Call Management Server (CMS) - The IPCablecom control function that provides call-agent and related control services, including TCAP-based services.
• Circuit Identity (CID) - The IPCablecom identity used to uniquely identify a trunk circuit within the gateway and route ISUP traffic.
• Circuit Identification Code (CIC) - The SS7 trunk identifier used together with point code and network identity.
• Origination Transaction Identity (OTID) - The SS7-side transaction identity used in TCAP routing and registration-related mapping.
• Signalling Connection Control Part (SCCP) - The SS7 layer whose subsystem registrations and transaction handling are part of ISTP operation.

Who uses SIST-TS ETSI/TS 101 909-12 V1.1.1:2005?

SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 is used by cable operators, telecom equipment vendors, and integrators working on IPCablecom networks that interwork with the PSTN. It is relevant to teams designing Signalling Gateways, Media Gateway Controllers, Call Management Servers, and the IP transport between them.

It also matters to operations and engineering staff who configure circuit ranges, subsystem registrations, timers, IP communication addresses, and failover behaviour. Quality and procurement teams use it to check whether an offered system supports the required SS7 interworking model and the intended redundancy approach.

What changed in SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 from the previous edition?

The introduction says this version is based on an earlier SPAN working text and that the main changes are a new mechanism for OTID assignment and additions in subsystem registration. It also notes that proposed text changes from Ray Forbes are covered.

Which standards are used with SIST-TS ETSI/TS 101 909-12 V1.1.1:2005?

• ETSI EN 300 356 - Supplies the ISUP specification used for SS7 call signalling.
• ETSI ETS 300 287-1 - Supplies the TCAP protocol specification used for transaction-based signalling.
• ETSI TS 101 909-1 - Provides the general IPCablecom framework that this part builds on.

What does the SIST-TS ETSI/TS 101 909-12 V1.1.1:2005 document contain?

The document contains architecture figures showing the IPCablecom-to-PSTN signalling model, the distributed node layout, and the protocol stack relationship between ISTP, SCCP, MTP, SCTP, TCP, and IP. It also contains a parameter table for the ISTP message format and separate message definitions for circuit registration, subsystem registration, message transfer, and flow control.

Annex B gives timer definitions and message-flow procedures for ISUP service, TCAP service, failover, and switchover. Annex A explains how SCTP and TCP should be used for ISTP transport, including considerations such as stream mapping and packet handling.

The body of the document is practical rather than descriptive: it lays out how to initialize the stack, how to assign and register circuit identities, how to route messages, how to detect outages, and how to notify peers about accessibility or congestion changes. For implementers, that makes the document useful both for protocol software and for system integration testing.

SLOVENSKI STANDARD
01-januar-2005
'LJLWDOQLãLURNRSDVRYQLNDEHOVNLGRVWRSGRMDYQLKWHOHNRPXQLNDFLMVNLKRPUHåLM±
9HþSUHGVWDYQRVWQHþDVRYQRNULWLþQHVWRULWYH,3±GHO,QWHUQHWQLWUDQVSRUWQL
SURWRNROVLJQDOL]DFLMH,673
Digital Broadband Cable Access to the Public Telecommunications Network; IP
Multimedia Time Critical Services; Part 12: Internet Signalling Transport Protocol (ISTP)
Ta slovenski standard je istoveten z: TS 101 909-12 Version 1.1.1
ICS:
33.040.35 Telefonska omrežja Telephone networks
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Specification
Digital Broadband Cable Access to the
Public Telecommunications Network;
IP Multimedia Time Critical Services;
Part 12: Internet Signalling Transport Protocol (ISTP)

2 ETSI TS 101 909-12 V1.1.1 (2002-11)

Reference
DTS/SPAN-130290
Keywords
IP, protocol, transport
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, send your comment to:
[e-mail]
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 2002.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI 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.
ETSI
3 ETSI TS 101 909-12 V1.1.1 (2002-11)
Contents
Intellectual Property Rights.6
Foreword.6
Introduction .6
1 Scope.7
2 References.7
3 Definitions, abbreviations and conventions .7
3.1 Definitions.7
3.2 Abbreviations.8
3.3 Convention.9
4 Signalling Protocols.9
5 Void.9
6 Overview and background motivation .9
6.1 Service goals.9
6.2 IPCablecom reference architecture.10
6.3 Introduction to ISTP.11
6.4 Specification goals.13
6.5 Specification interfaces.13
7 Architecture.13
7.1 IPCablecom to PSTN .13
7.2 Signalling architecture network model.14
7.3 Distribution Model.16
7.4 Guaranteed performance.17
7.5 Protocol stack.18
8 Functional areas.18
8.1 Mapping relationships.18
8.1.1 SS7 numbering.19
8.1.2 IPCablecom numbering.19
8.1.3 ISTP numbering.20
8.2 Message distribution.20
8.3 Dynamic Mapping.20
8.4 Relationships.21
8.5 Initialization.21
8.6 Recovery.22
8.7 Dynamic provisioning.23
8.8 Administration.23
8.9 Security.23
8.10 Maintenance.23
8.11 Measurement.23
8.12 Alarms.24
8.13 Congestion.24
8.14 Management of lower layers .24
9 Protocol.24
9.1 General requirements.24
9.1.1 Communication with the lower layers .24
9.1.2 Encoding rules.25
9.1.3 SS7 Load-sharing and sequencing .25
9.2 Procedures.25
9.2.1 Registration of circuit identifiers .25
9.2.1.1 Circuit registration.26
9.2.1.2 Circuit deregistration.26
ETSI
4 ETSI TS 101 909-12 V1.1.1 (2002-11)
9.2.2 Activation of registered circuits.27
9.2.2.1 Circuit activation.27
9.2.2.2 Forced exclusive circuit activation.27
9.2.2.3 New work circuit activation .28
9.2.2.4 Circuit deactivation.28
9.2.3 Registration of subsystem transactions .28
9.2.3.1 Subsystem registration.29
9.2.3.2 Subsystem transaction deregistration .29
9.2.4 Activation of registered subsystem transactions .29
9.2.4.1 Subsystem activation.30
9.2.4.2 Forced exclusive subsystem activation .30
9.2.4.3 Subsystem deactivation.30
9.2.5 Message transfer.31
9.2.5.1 ISUP message transfer .31
9.2.5.2 TCAP message transfer.31
9.3 Failure detection and handling .31
9.3.1 Heartbeat.32
9.3.2 Signalling gateway procedures .32
9.3.2.1 Signalling point accessibility .32
9.3.2.2 Subsystem accessibility.32
9.3.2.3 SS7 network accessibility .32
9.3.2.4 MGC/CMS accessibility.33
9.3.2.5 Congestion on the SS7 network .33
9.3.2.6 Congestion on the IP network .33
9.3.3 MGC and CMS procedures.33
9.3.3.1 Signalling point accessibility .33
9.3.3.2 SS7 Network accessibility.33
9.3.3.3 Signalling gateway accessibility .33
9.3.3.4 SS7 Network congestion.34
9.3.3.5 Congestion on the IP network .34
9.4 Message format.34
9.4.1 Message types.35
9.4.2 Message nature.35
9.4.3 Parameters.36
9.4.3.1 asciiString.36
9.4.3.2 cic.36
9.4.3.3 CircuitRange.36
9.4.3.4 DestinationType.37
9.4.3.5 InaccesibilityReason.37
9.4.3.6 Integer.37
9.4.3.7 isupClientReturnValue.37
9.4.3.8 isupTransferFormat.37
9.4.3.9 NormalizedISUPMsg.38
9.4.3.10 NormalizedTCAPMsg.38
9.4.3.11 pointCode.38
9.4.3.12 QualityOfService.38
9.4.3.13 rawISUPMsg.38
9.4.3.14 rawTCAPMsg.38
9.4.3.15 routingLabel.38
9.4.3.16 sccpPartyAddress.39
9.4.3.17 stream.39
9.4.3.18 subsystem.39
9.4.3.19 subsystemActionReturnValue.39
9.4.3.20 tcapTransferFormat.40
9.5 Messages.40
9.5.1 Circuit registration and activation messages.40
9.5.1.1 Circuit registration.40
9.5.1.2 Circuit deregistration.40
9.5.1.3 Circuit activation.41
9.5.1.4 Forced exclusive circuit activation.41
9.5.1.5 New work circuit activation .41
9.5.1.6 Circuit deactivation.41
ETSI
5 ETSI TS 101 909-12 V1.1.1 (2002-11)
9.5.1.7 Forced circuit deactivation.41
9.5.1.8 New work circuit deactivation .41
9.5.2 Subsystem transaction registration and activation messages .42
9.5.2.1 Subsystem registration.42
9.5.2.2 Subsystem deregistration.42
9.5.2.3 Subsystem activation.42
9.5.2.4 Exclusive subsystem activation.43
9.5.2.5 Subsystem deactivation.43
9.5.2.6 Forced subsystem deactivation.43
9.5.3 Message transfer.43
9.5.3.1 ISUP-Message-Transfer.43
9.5.3.2 TCAP-Message-Transfer.43
9.5.4 Flow control.44
9.5.4.1 Heartbeat.44
9.5.4.2 Signalling point inaccessible.44
9.5.4.3 Signalling point accessible.45
9.5.4.4 Subsystem inaccessible.45
9.5.4.5 Subsystem accessible.45
9.5.4.6 Signalling point congestion.45
9.5.4.7 Local Congestion.46
9.5.4.8 SS7 Network accessible .46
9.5.4.9 SS7 Network inaccessible .46
Annex A (informative): SCTP and TCP usage Recommendations.47
A.1 SCTP Usage recommendations.47
A.1.1 SCTP Stream Mapping.47
A.1.2 SCTP Congestion Information .47
A.2 TCP usage recommendations .47
A.2.1 Delaying of packets .48
A.2.2 Non-blocking interface.48
A.2.3 Disable TCP socket linger.48
Annex B (informative): ISTP message flows and timer definitions.49
B.1 Timers.49
B.2 MGC requests ISUP service procedure.50
B.3 MGC terminates ISUP service procedure .51
B.4 Residential CA requests TCAP service procedure.52
B.5 Residential CA terminates TCAP service procedure .53
B.6 MGC failover procedure .54
B.7 MGC switchover procedure .55
Annex C (informative): Bibliography.56
History .57

ETSI
6 ETSI TS 101 909-12 V1.1.1 (2002-11)
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 Services and Protocols for
Advanced Networks (SPAN).
The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [3].
Introduction
This version is based on the 8TD112r2 from SPAN #78 in June 02 and the direct continuation of D8-36 presented at
TC-AT-D in July 02. The main changes are due to the new mechnism for OTID assignment and the additions in the
Subsystem registration. Proposed text changes from Ray Forbes are also covered.
ETSI
7 ETSI TS 101 909-12 V1.1.1 (2002-11)
1 Scope
The present document describes the Internet Signalling Transport Protocol (ISTP) to implement Signalling System
No. 7 signalling interconnection to a distributed IPCablecom architecture.
The present document addresses the protocol to implement ETSI SS7 used for signalling interconnection in a
distributed IPCablecom architecture. Specifically, it defines the messages and procedures for transporting SS7 ISUP,
and TCAP messages as defined by ETSI specifications between the IPCablecom control functions (Media Gateway
Controller and Call Management Server) and the SS7 Signalling Gateway. The IPCablecom Networks are always
connected to the PSTN/ISDN using standard ETSI SS7 interfaces Ref (ISUP, MTP and SCCP)
Areas beyond the scope of the present document include:
• address layer management (SNMP), security, and measurements; these are covered in other IPCablecom
Recommendations;
• implementation and vendor dependant issues, such as performance, functional distribution, network
configuration, etc.;
• details about CMS, MGC, and other media communication applications.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• 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.
• For a non-specific reference, the latest version applies.
[1] ETSI EN 300 356: "Integrated Services Digital Network (ISDN); Signalling System No.7 (SS7);
ISDN User Part (ISUP) version 4 for the international interface".
[2] ETSI ETS 300 287-1 (Edition 2): "Integrated Services Digital Network (ISDN); Signalling System
No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification [ITU-T
Recommendations Q.771 to Q.775 (1993), modified]".
[3] ETSI TS 101 909-1: "Digital Broadband Cable Access to the Public Telecommunications
Network; IP Multimedia Time Critical Services; Part 1: General ".
3 Definitions, abbreviations and conventions
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Access Node (AN): As used in the present document, an Access Node is a layer two termination device that terminates
the network end of the J.112 connection. It is technology specific. In ITU-T Recommendation J.112 annex A it is called
the INA while in Annex B it is the CMTS.
Cable Modem (CM): layer two termination device that terminates the customer end of the J.112 connection
ETSI
8 ETSI TS 101 909-12 V1.1.1 (2002-11)
Gateway: devices bridging between the IPCablecom IP Voice Communication world and the PSTN
NOTE: Examples are the Media Gateway which provides the bearer circuit interfaces to the PSTN and transcodes
the media stream, and the Signalling Gateway which sends and receives circuit switched network
signalling to the edge of the IPCablecom network.
IPCablecom: ETSI project that includes an architecture and a series of Recommendations that enable the delivery of
real time services over the cable television networks using cable modems
Signalling Gateway (SG): signalling agent that receives/sends SCN native signalling at the edge of the IP network
NOTE: In particular the SS7 SG function translates variants ISUP and TCAP in an SS7-Internet Gateway to a
common version of ISUP and TCAP.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AN Access Node
ANS Announcement Server
ATM Asynchronous Transfer Mode
CA Call Agent
CIC Circuit Identification Code
CID Circuit ID
CM Cable Modem
CMS Call Management Server
DNS Directory Name Server
DPC Destination Point Code
HFC Hybrid Fibre/Coaxial [cable]
IP Internet Protocol
ISTP Internet Signalling Transport Protocol
ISUP ISDN User Part
LAN Local Area Network
MAC Media Access Control
MG Media Gateway
MGC Media Gateway Controller
MTA Media Terminal Adapter
MTP Message Transfer Part
NI Network Identifier
OPC Origination Point Code
OTID Origination Transaction Identity
PHY Physical Layer
PSTN Public Switched Telephone Network
QoS Quality of Service
RTP Real Time Protocol
SCCP Signalling Connection Control Part
SCP Service Control Point
SCTP Stream Control Transmission Protocol
SG Signalling Gateway
SIP Session Initiation Protocol
SLS Signalling Link Selection
SS7 Signalling System No. 7
SSN Switching Signalling Node
SSP Signal Switching Point
TCAP Transaction Capabilities Application Part
TCP Transmission Control Protocol
UDP User Datagram Protocol
WAN Wide Area Network
ETSI
9 ETSI TS 101 909-12 V1.1.1 (2002-11)
3.3 Convention
If the present document is implemented, the key words "MUST" and "SHALL" are to be interpreted as indicating a
mandatory aspect of the present document.
4 Signalling Protocols
The signalling protocols used for interconnection in a distributed IPCablecom PSTN gateway architecture shall be
designed to support ETSI Signalling System No. 7 (SS7).
5 Void
6 Overview and background motivation
6.1 Service goals
Cable operators are interested in deploying high-speed data and multimedia communications services on cable
television systems. It is necessary to have a series of interface Recommendations that will permit the early definition,
design, development, and deployment of packetized data-based services over cable systems on a uniform, consistent,
open, non-proprietary, multi-vendor interoperable basis. The intended system enables Internet Protocol (IP) based voice
communications, video, and data services to be provided to the customer over an all-coaxial or hybrid-fibre/coax (HFC)
cable access network by utilizing ITU-T Recommendation J.112 as the basic foundation for data transport. This is
shown in simplified form in figure 1.
Wide-Area Access Node
Network AN
AN Cable Cable CM Customer Premises
Network Side Network Modem Equipment Interface
Interface (CM)
Customer Premises
Equipment
T0912270-01
Transparent IP traffic through the system
(118825
Figure 1: Transparent IP traffic through the data-over-cable system
The transmission path over the cable system is realized at the headend by an Access Node and at each customer location
by a CM. The intent is for operators to transfer IP traffic transparently between these interfaces, thereby providing the
basic transport mechanism for data-based multimedia services.
When providing voice and other multimedia services over the J.112 access network; many issues need to be addressed
for incoming and outgoing communications. These issues include but are not limited to:
• voice or other media content conversion;
• call control signalling;
• quality of service control;
• call control signalling interoperability with the existing public network;
ETSI
10 ETSI TS 101 909-12 V1.1.1 (2002-11)
• media interfaces to the existing public network;
• data transactions to public databases;
• routing mechanisms;
• billing;
• operations and maintenance;
• security;
• privacy.
The IPCablecom project is addressing these issues through the development and publication of reference architecture
and a series of corresponding interface specifications. The present document, the IPCablecom Internet Signalling
Transport Protocol (ISTP) addresses the issue of call control signalling interoperability with the existing public
network.
6.2 IPCablecom reference architecture
The conceptual diagram in figure 2 portrays a high level architectural view of the IPCablecom network.
Subscriber equipment consists of a Media Terminal Adapter (MTA), the primary purpose is to provide a gateway
between the subscriber-side voice/video media devices and the rest of the IPCablecom network. Two types of MTAs
exist. The first is a standalone MTA that connects via a local area network (LAN) interface (e.g. IEEE 802.3) to a CM.
The second is an embedded MTA, which integrates the standalone MTA functions with the CM media access control
(MAC) and physical layer (PHY) functions in the same physical package.
Physical connectivity to the backbone consists of an all-coax or a hybrid fibre-coax (HFC) J.112 enabled cable access
network with J.112 Quality of Service (QoS). The J.112 HFC access network terminates at the head end Access Node.
The Access Node provides either a bridging point or a routing point to the backbone managed IP network.
The Call Management Server (CMS) provides control, routing, and signalling services in connection with voice
communications provided via IPCablecom. It is responsible for authorization and plays a roll in feature implementation.
The media servers provide support services for media streams such as conference mixing bridges and announcement
servers.
CMS is a meta-term for a collection of functions (both specified and unspecified within IPCablecom) within a server or
cluster of servers that work together to perform "line-side" control functions within an IPCablecom network. The
simplest way to think of a CMS is to imagine the functions of a local switch call controller being extrapolated and
placed into a server farm. The CMS includes a minimum of a call agent and a gate controller. It may have feature and
routing logic. It may or may not contain a media gateway controller, meaning that it can implement some transit switch
functionality as well as local. A SIP-proxy may also be contained within a CMS, although IPCablecom does not include
SIP in the architecture.
A Call Agent is a specific control function contained within the CMS. It implements the server side of the protocol
interface and controls MTAs. The MGC is a specific control function that may be contained within a CMS or may be
standalone in the network. It implements the server side of the TGCP protocol interface and is used to control PSTN
media trunking gateways.
The Public Switched Telephone Network (PSTN) gateway provides access from the subscriber network into the PSTN
network. For outgoing communications, the Media Gateway (MG) converts the voice samples arriving in RTP packets
into the appropriate TDM format and delivers the resulting voice stream to the public network. The Media Gateway
Controller (MGC) provides signalling information related to the communication to the PSTN through the services of the
Signalling Gateway (SG). This signalling information exchanged with the PSTN is used by the components of the
IPCablecom network to manage the communication's progress and provide required features and functionality. In
addition, IPCablecom gateways also interwork with the public databases of the PSTN using SS7 TCAP queries,
allowing the IPCablecom network to query for publicly available data (freephone numbers, local number portability
service, credit card data, etc.).
ETSI
11 ETSI TS 101 909-12 V1.1.1 (2002-11)
For incoming communications, IPCablecom equipment will convert arriving TDM circuit voice to RTP packets
carrying appropriately coded samples. It will also take the incoming communication related SS7 ISUP signalling and
convert it to signalling understood by IPCablecom devices.
The OSS back office provides support services such as billing, provisioning, fault determination, problem resolution,
and other support services.
Note that ISTP makes no assumptions on how the CMS and MGC and other ISTP-User functions are distributed or
physically located: they all MAY be collocated, each distributed on separate computers, or all distributed as separate
nodes and processes across a wide network and a large number of computers. ISTP was designed to handle all these
cases.
Embedded
Call Management
Server
Cable
MTA
Modem
HFC
CMTS
network
Announcement Servers
Media
(DOCSIS) Conference Mixing Bridges
Standalone
Servers
...
MTA
Cable
MTA
Media
Modem
Gateway
Managed IP Backbone
PSTN
Media Gateway
(QoS Features)
Controller
(Headend, Local, Regional)
Embedded
Signaling
Cable
MTA
Gateway
Modem
HFC
CMTS
network
(DOCSIS)
Standalone
Billing
OSS
MTA
Provisioning
Backoffice
Problem Resolution
Cable
DHCP Servers
MTA
Modem
TFTP Servers
...
Figure 2: IPCablecom reference architecture
6.3 Introduction to ISTP
ISTP contains features for initialization; address mapping from the SS7 domain to the IP domain; message delivery for
SS7 Integrated Services Digital Networks (ISDN) User Part (ISUP), Transaction Capabilities Application Part (TCAP);
congestion management; fault management; maintenance operations; and redundant configuration support. ISTP
bridges the gap between basic IP transport mechanisms and application level signalling. Although not a translation of
the SS7 Message Transport Protocol 3 (MTP3) and Signalling Connection and Control Protocol (SCCP) protocols,
ISTP implements analogues to some of the MTP3 and SCCP functions in a fashion appropriate to distributed systems
communicating over an IP network.
Thus ISTP distributes transparently the ISUP and TCAP functions into multiple elements while retaining the
computational intensive SCCP/MTP2/MTP3 SS7 stack elements in the Signalling Gateway (see figure 3). This also
keeps the SCCP Global Title tables in a secure central location, as preferred by SS7 network operators. This breakdown
also allows ISTP-User applications to have access to all the TCAP and ISUP data, which may be necessary for some
advanced features. It provides the maximum isolation from SS7 details while providing full transaction and signalling
information. It also allows new ISTP-User applications that require other SS7 application part protocols, such as GSM
MAP and IS41 MAP, to be added in a graceful and backward compatible manner by installing the MAP agents over
ISTP as needed.
ETSI
12 ETSI TS 101 909-12 V1.1.1 (2002-11)
ISTP-USER at the SG ISTP-USER at an I PCablecom Node
(Nodal Interworking Function)
SCCP
ISUP
TCAP application
subsystems
CID based
SSN based
distribution
ISUP
TCAP
distribution
ISTP
ISTP
SCCP
e.g. SCTP
MTP L3
e.g. SCTP
MTP L2 IP
IP
MTP L1
physical layer
physical layer
SS7 network IP based network
Figure 3: Protocol stack in IPCablecom elements
The ISTP is designed to support a wide variety of configurations, ranging from a non-redundant SS7 Signalling
Gateway serving a single non-redundant Media Gateway Controller to a distributed, fully redundant SS7 Signalling
Gateway serving multiple distributed and redundant Media Gateway Controllers and Call Management Servers, and
potentially other network elements.
NOTE: The term ISTP-User will be a generic term for any element, node, or process that uses the ISTP stack for
signalling communications. For the first phase of IPCablecom this includes the CMS, MGC and SG. In
the future, other types of elements may include the stack.
The ISTP contains functions for:
• Initialization.
• Registration Of Circuit IDs With The SS7 Gateway.
• Address Mapping Between The SS7 and IP domains.
• ISUP Maps Based On Point Code and Circuit Identification Code.
• TCAP Maps Based On Point Code and Origination Transaction ID (OTID) from the SS7 side of the SG to the
transaction ID used on the IPCablecom side and vice versa.
• ISUP/TCAP Message Delivery Using Reliable Transport.
...