1.1 Purpose and Scope of this Document
This document presents Telcordia Technologies detailed specifications for the implementation of TCP/IP as the transport layer protocol for the interface between the Service Management System (SMS/800) and Service Control Points (SCPs).
This document will not address the SMS/800 application layer processing or the application messages, with the following exceptions:
- Application Messages will not change; however the UNR-MSG, GNT and SSC messages will not be used by the TCP/IP Implementation. There will be no further discussion of Application Messages in this document.
- The UAL Header has been shortened, and has been renamed the UPL Header. The values of the remaining attributes are defined, and they still perform the necessary services. The UPL Header is discussed in section 3.
Information provided in this document is intended to provide interested companies with detailed descriptions of Telcordia’s implementation of the TCP/IP Protocol to be used by SMS/800 and SCPs when information is exchanged between systems.
This document does not provide specifications for Application message structures and formats, message language conventions, detailed syntax and semantics for individual messages, and response requirements for each message defined. For this information, refer to TM-STS-000798, Call Management Services Data Base/Service Management System.
1.2 Document Organization
The remainder of this document is organized as follows:
Section 2 presents some general background information on 800 Data Base Service, the functionality of SMS/800 and functional overview of the interface.
Section 3 presents a discussion of the interface from the TCP/IP Protocol standpoint. Areas included are communications requirements and description of protocol layers.
Section 4 describes the message structure and its components. Section 5 presents the Application Messages.
Section 6 discusses naming conventions for nodes.
Section 7 presents the ASN.1 data representation, BER Protocol and the ASN.1 code for the interface.
Section 8 presents implementation requirements.
1.3 Requirements Labeling Conventions
Requirements and objectives are labeled using conventions that are explained in the following three sections.
1.3.1 Numbering of Requirement and Related Objects
Each Requirement, Objective, Condition, Conditional Requirement, and Conditional Objective object is identified by both a local and an absolute number. The local number consists of the object’s document section number and its sequence number in the section (e.g., R3-1 is the first Requirement in Section 3). The local number appears in the margin to the left of the Requirement. A Requirement object’s local number may change in subsequent issues of a document if other Requirements are added to the section or deleted.
The absolute number is a permanently assigned number that will remain for the life of the Requirement: it will not change with new issues of the document. The absolute number is presented in brackets (e.g., ) at the beginning of the requirement text.
Neither the local nor the absolute number of a Conditional Requirement or Conditional Objective depends on the number of the related Condition(s). If there is any ambiguity about which Conditions apply, the specific Condition(s) will be referred to by number in the text of the Conditional Requirement or Conditional Objective.
References to Requirements, Objectives, or Conditions published in other Generic Requirements documents will include both the document number and the Requirement object’s absolute number. For example, R2345-12 refers to Requirement  in GR-2345.
1.3.2 Requirement, Conditional Requirement, and Objective Object
A Requirement object may have numerous elements (paragraphs, lists, tables, equations, etc.). To aid the reader in identifying each part of the requirement, an ellipsis character (...) appears in the margin to the left of all elements of the Requirement.
Tables and Figures within Requirements are identified separately from others within the document text, and do not appear in the Table of Contents. They are numbered sequentially beginning with Table 1 and Figure 1.
The following terminology is used throughout this document:
Feature or function that, in the SMT software vendor’s view, is necessary to satisfy the needs of the user.
Failure to meet a Requirement may cause application restrictions, result in improper functioning of the product, or hinder operations. A Requirement contains the words shall or must and is flagged by the letter “R” in parentheses: (R)
- Conditional Requirement
Feature or function that, in the SMT software vendor’s view, is necessary in specific applications and may be reclassified as a requirement by a user, depending upon the applications environment in which the system is deployed. Conditional Requirements may depend on other Requirements, Objectives, or Conditional Requirements. A Conditional Requirement is flagged by the letters “CR” in parentheses: (CR).
Feature or function that, in the SMT software vendor’s view, is desirable and may be required. An Objective represents a goal to be achieved. An Objective is flagged by the letter “O” in parentheses: (O) and contains the words it is desirable or it is an objective.
- Conditional Objective
Feature or function that, in the SMT software vendor’s view, is desirable in specific applications and may be required by a client. It represents a goal to be achieved in the specified conditions. If a client identifies a Conditional Objective as necessary, it shall be treated as a requirement for the application(s). A Conditional Objective is flagged by the letters CO.
The circumstances that, in the SMT software vendor’s view, will cause a Conditional Requirement or Conditional Objective to apply. A Condition is flagged by the letters Cn.