• There are no items in your cart

TR 102 019 : 1.1.1

Current

Current

The latest, up-to-date edition.

SERVICES AND PROTOCOLS FOR ADVANCED NETWORKS (SPAN); DESIGN REQUIREMENTS FOR ITU J.ARCH, J.ISTP AND J.TGCP

Available format(s)

Hardcopy , PDF

Language(s)

English

Intellectual Property Rights
Foreword
1 Scope
2 References
3 Definitions and abbreviations
  3.1 Definitions
  3.2 Abbreviations
4 Overview and purpose
  4.1 History and relationships to other standards
  4.2 ITU-T IPCablecom framework
      4.2.1 IPCablecom reference architecture
      4.2.2 Interfaces
      4.2.3 Bundling and unbundling of components
      4.2.4 IPCablecom zones and domains
5 Requirements obtained from J.arch
  5.1 Overview
      5.1.1 Scope
      5.1.2 What is J.arch?
      5.1.3 Three architectures, possible three phases
  5.2 Commercial requirements for IPCablecom
      5.2.1 Implicit commercial requirements
      5.2.2 Legal/Regulator observations
  5.3 Technical requirements
      5.3.1 Architecture goals of J.archs
             5.3.1.1 General architecture goals
             5.3.1.2 Call signalling requirements
             5.3.1.3 Call features
             5.3.1.4 Quality of Service (QoS) requirements
             5.3.1.5 Codec and media stream requirements
             5.3.1.6 Device provisioning and OSS requirements
             5.3.1.7 Security requirements
             5.3.1.8 Managed IP network goal
      5.3.2 Requirements from components
             5.3.2.1 Trust
             5.3.2.2 Subscriber side requirements
             5.3.2.3 MTA Functional requirements
             5.3.2.4 Access Node (AN) MTA functional
                       requirements
             5.3.2.5 Access Node (AN) MTA managed IP
                       functional requirements
             5.3.2.6 CMS Call agent functions
             5.3.2.7 CMS Announcement controller functions
             5.3.2.8 Implicit CMS goal
             5.3.2.9 MGC requirements
             5.3.2.10 MGC functions
             5.3.2.11 MG requirements
             5.3.2.12 MG functions
             5.3.2.13 SS7 signalling gateway functions
             5.3.2.14 PSTN signalling requirements
             5.3.2.15 OSS requirements
             5.3.2.16 Media streams: RTP
             5.3.2.17 Provisioning
             5.3.2.18 Event management
             5.3.2.19 Quality of Service
             5.3.2.20 Announcement options
             5.3.2.21 Security: Privacy and fraud prevention
             5.3.2.22 Time of day requirements
             5.3.2.23 Clocks
             5.3.2.24 IP addressing
             5.3.2.25 Packet prioritisation
             5.3.2.26 Fax support
             5.3.2.27 Analogue modem support
6 Requirements obtained from J.istp
  6.1 Overview
      6.1.1 Scope
      6.1.2 What is J.istp?
             6.1.2.1 Note on SG and ISTP
             6.1.2.2 Protocol distribution in IPCablecom elements
             6.1.2.3 General ISTP functions
             6.1.2.4 ISTP specification goals
             6.1.2.5 ISTP in decomposed IPCablecom gateway
             6.1.2.6 Areas beyond the scope of J.istp
             6.1.2.7 ISTP and IETF
  6.2 J.istp: Technical requirements
      6.2.1 J.istp: Framework and architecture requirements
             6.2.1.1 High Level SG/ISTP requirements
             6.2.1.2 Support of J.arch framework service goals
             6.2.1.3 SG SS7 termination requirements
             6.2.1.4 Functional SG signalling requirements
             6.2.1.5 Functional SG interface requirements
             6.2.1.6 Architecture Zone/Domain goals
             6.2.1.7 Reliable underlying transport
      6.2.2 J.istp: Availability and Performance Requirements
             6.2.2.1 Distribution model Background
             6.2.2.2 Distribution Model
             6.2.2.3 Availability
             6.2.2.4 Call Availability and Recovery
             6.2.2.5 Call Performance
             6.2.2.6 Traffic Performance
      6.2.3 J.istp: Distribution model requirements
             6.2.3.1 Bi-directional mapping among components
             6.2.3.2 Numbering: MGC name to IP address
             6.2.3.3 Numbering: circuits and transactions
             6.2.3.4 Message distribution
             6.2.3.5 Alternate mapping on failure
             6.2.3.6 Relationships
             6.2.3.7 Initialisation
             6.2.3.8 Recovery
             6.2.3.9 Dynamic provisioning updates
             6.2.3.10 Administration
             6.2.3.11 ISTP Security
             6.2.3.12 Maintenance
             6.2.3.13 Measurement
             6.2.3.14 Alarms
             6.2.3.15 Congestion
             6.2.3.16 SG management notification
      6.2.4 J.istp: SS7 related protocol requirements
             6.2.4.1 ISTP protocol requirements
             6.2.4.2 ISTP connection requirements
             6.2.4.3 ISTP SS7 encoding requirements
             6.2.4.4 ISTP load-sharing and sequencing
             6.2.4.5 Circuit registration and activation
             6.2.4.6 Transaction subsystem registration
             6.2.4.7 Message failure detection and handling
             6.2.4.8 Heartbeat
             6.2.4.9 Signalling gateway accessibility procedures
             6.2.4.10 SG congestion handling
             6.2.4.11 IPCablecom component management procedures
             6.2.4.12 IP usage
      6.2.5 J.istp: Future work
7 Requirements obtained from J.tgcp
  7.1 Overview
      7.1.1 Scope
      7.1.2 What is J.tgcp?
             7.1.2.1 Note on MG, MGC, TGCP and MGCI
             7.1.2.2 TGCP in the protocol stack
             7.1.2.3 J.tgcp Trunking Gateway Document
             7.1.2.4 First level decomposition of a Managed IP
                       Network
             7.1.2.5 Areas beyond the scope of J.tgcp
  7.2 J.tgcp: Technical requirements
      7.2.1 J.tgcp: Framework and Architecture Requirements
             7.2.1.1 Support of J.arch framework service goals
             7.2.1.2 High level control requirements
             7.2.1.3 High level IP side management requirements
             7.2.1.4 TGCP high level trunk side requirements
             7.2.1.5 Other Trunking Gateway Requirements
             7.2.1.6 Distribution model
      7.2.2 J.tgcp: MGCI API requirements
             7.2.2.1 Model and naming convention
             7.2.2.2 Endpoint name
             7.2.2.3 Trunk name
             7.2.2.4 Call and Connection names
             7.2.2.5 MGC naming
             7.2.2.6 MGC name binding
             7.2.2.7 Digit Maps
             7.2.2.8 Packages
             7.2.2.9 Experimental Packages
             7.2.2.10 Wildcard support
             7.2.2.11 Events and Signals on connections
             7.2.2.12 Session Description Protocol
             7.2.2.13 Gateway control functions
      7.2.3 J.tgcp: Control Function Requirements
             7.2.3.1 Commands
             7.2.3.2 Calls
             7.2.3.3 Connection mode parameter
             7.2.3.4 Audio connection modes
             7.2.3.5 Loop-back and continuity testing
             7.2.3.6 Continuity test (COT)
             7.2.3.7 Audio requirements on testing
      7.2.4 Requirements from notification request message
             and parameters
             7.2.4.1 Notification request command
             7.2.4.2 Media stream notification requirements
             7.2.4.3 Dynamic configuration of events
             7.2.4.4 Default vs. dynamically set events
             7.2.4.5 Event requests
             7.2.4.6 Event scripting
             7.2.4.7 Event request vs. signal request
             7.2.4.8 Quarantine handling
      7.2.5 Requirements from Notify message and parameters
             7.2.5.1 Notify requirements
      7.2.6 Requirements from create connection message and
             parameters
             7.2.6.1 Connection definition
             7.2.6.2 Local connection characteristics
             7.2.6.3 Local connection options for IP security
             7.2.6.4 Local connection LI requirements
             7.2.6.5 Remote connections
             7.2.6.6 Local connection modes
      7.2.7 Requirements from Modify Connection message and
             parameters
             7.2.7.1 Modify connection
             7.2.7.2 Synchronized create and modify connection
      7.2.8 Requirements from Delete Connection (from MGC)
             message and parameters
             7.2.8.1 Delete message usage
             7.2.8.2 Return performance data
             7.2.8.3 Synchronized notify and delete connection
      7.2.9 Requirements from Delete Connection (from MG) message
             and parameters
             7.2.9.1 Delete connection forced by MG
             7.2.9.2 Delete multiple or all connections
             7.2.9.3 Auditing
      7.2.10 Requirements from audit endpoint message and
             parameters
             7.2.10.1 Audit endpoint
      7.2.11 Requirements from audit connection message and
             parameters
             7.2.11.1 Auditing connections
      7.2.12 Requirements from restart in progress message
             and parameters
             7.2.12.1 Restart in progress
             7.2.12.2 Restart method types
             7.2.12.3 MG restart in progress response
      7.2.13 J.tgcp: API recovery requirements
             7.2.13.1 Autonomous fault detection and recovery
             7.2.13.2 Endpoint/MGC recovery model
             7.2.13.3 Detection of lost association
             7.2.13.4 Repetition mechanism
             7.2.13.5 Repeat transmission algorithm
             7.2.13.6 Repeat algorithm timers
             7.2.13.7 Race conditions
             7.2.13.8 Quarantine list accumulation and sending
             7.2.13.9 Explicit detection and transactional
                       semantics
             7.2.13.10 Ordering of commands, and treatment of
                       disorder
             7.2.13.11 Restart time shifting
             7.2.13.12 Restart execution
             7.2.13.13 Disconnected endpoints management
             7.2.13.14 Consistent return and reason codes
      7.2.14 J.tgcp: Requirements from TGCP not all ready
             covered by the MGCI API
             7.2.14.1 Consistent command structure
             7.2.14.2 Command Header
             7.2.14.3 Command line
             7.2.14.4 Requested verb naming
             7.2.14.5 Transition identity handling
             7.2.14.6 Name and protocol version coding
             7.2.14.7 Parameter lines
             7.2.14.8 Requirements on parameters in parameter
                       line
             7.2.14.9 Response header
             7.2.14.10 Retry at the protocol levels
             7.2.14.11 Post-retry at the protocol level
             7.2.14.12 Piggy-backing protocol
             7.2.14.13 Transaction identifier sharing
             7.2.14.14 Response acknowledgement of confirmed
                       transactions: 3 way handshake
             7.2.14.15 Transaction confirmation algorithm
             7.2.14.16 Provisional response
             7.2.14.17 Security
      7.2.15 J.tgcp: Requirements from annex A, event packages
             7.2.15.1 Event package overall
             7.2.15.2 Continuity tone (COT) and fax tone
             7.2.15.3 Call tones
             7.2.15.4 Operation failure
             7.2.15.5 Long duration and media start events
      7.2.16 J.tgcp: Requirements from MF operator services
             7.2.16.1 Introduction
             7.2.16.2 Outgoing operator service package events/signals
             7.2.16.3 MF terminating protocol package
      7.2.17 Future work
Annex A: Bibliography
History

Specifies the design and specification requirements obtained from reverse engineering a set of ITU recommendations, consisting of J.arch (architectural framework), J.istp (IPCablecom Signalling Transfer Protocol), and J.tgcp (Trunking Gateway Control Protocol). These documents are part of a set of ITU documents describing the IPCablecom framework and its subparts.

Committee
SPAN
DocumentType
Standard
Pages
75
PublisherName
European Telecommunications Standards Institute
Status
Current

View more information
US$47.91
Excluding Tax where applicable

Access your standards online with a subscription

Features

  • Simple online access to standards, technical information and regulations.

  • Critical updates of standards and customisable alerts and notifications.

  • Multi-user online standards collection: secure, flexible and cost effective.