Table of Contents
- About the Authors
- Icons Used in This Book
- Command Syntax Conventions
- Part I. Introductions and Overviews
- Chapter 1. The Evolution of Signaling
- Chapter 2. Standards
- Chapter 3. The Role of SS7
- Chapter 4. SS7 Network Architecture and Protocols Introduction
- Chapter 5. The Public Switched Telephone Network (PSTN)
- Part II. Protocols Found in the Traditional SS7/C7 Stack
- Chapter 6. Message Transfer Part 2 (MTP2)
- Chapter 7. Message Transfer Part 3 (MTP3)
- Chapter 8. ISDN User Part (ISUP)
- Chapter 9. Signaling Connection Control Part (SCCP)
- Chapter 10. Transaction Capabilities Application Part (TCAP)
- Part III. Service-oriented Protocols
- Chapter 11. Intelligent Networks (IN)
- Chapter 12. Cellular Networks
- Chapter 13. GSM and ANSI-41 Mobile Application Part (MAP)
- Part IV. SS7/C7 Over IP
- Chapter 14. SS7 in the Converged World
- Part V. Supplementary Topics
- Chapter 15. SS7 Security and Monitoring
- Chapter 16. SS7 Testing
- Part VI. Appendixes
- Appendix A. MTP Messages (ANSI/ETSI/ITU)
- Appendix B. ISUP Messages (ANSI/UK/ETSI/ITU-T)
- Appendix C. SCCP Messages (ANSI/ETSI/ITU-T)
- Appendix D. TCAP Messages and Components
- Appendix E. ITU-T Q.931 Messages
- Appendix F. GSM and ANSI MAP Operations
- Appendix G. MTP Timers in ITU-T/ETSI/ANSI Applications
- Appendix H. ISUP Timers for ANSI/ETSI/ITU-T Applications
- Appendix I. GSM Mobile Country Codes (MCC) and Mobile Network Codes (MNC)
- Appendix J. ITU and ANSI Protocol Comparison
- Appendix K. SS7 Standards
- Appendix L. Tektronix Supporting Traffic
- Appendix M. Cause Values
The dialogue portion of the message is optional and is used to convey information about a dialogue between nodes at the component sublayer. It establishes a flow of information within a particular context for a transaction. Information, such as the protocol version and application context, is used to ensure that two nodes interpret the component sublayer's contents in the same manner using an agreed upon set of element definitions.
There are two categories of dialogues: structured and unstructured. An unstructured dialogue is one in which no reply is expected. This type of dialogue uses a Unidirectional message type at the transaction layer. A structured dialogue requires a reply.
Within these two general categories of dialogues, dialogue-control Application Protocol Data Units (APDU) are used to convey dialogue information between TC-Users. The following are four types of APDU:
- Dialogue Request
- Dialogue Response
- Dialogue Abort
- Dialogue Unidirectional
Following is a description of each of these APDU and the information elements contained therein. The ITU unstructured dialogue uses the following dialogue-control APDU:
- Unidirectional Dialogue— The Unidirectional Dialogue consists of an Application Context Name and optional Protocol Version and User Information. It is used to convey dialogue information in one direction, for which no reply is expected.
The structured dialogue uses the following dialogue-control APDUs:
- Dialogue Request— The Dialogue Request consists of an Application Context Name and, optionally, Protocol Version and User Information. It is used to request dialogue information from another node, such as the context between the nodes (what set of operations will be included) and to distinguish that the correct protocol version is being used to interpret the information that is being sent.
- Dialogue Response— The Dialogue Response is sent as a reply to a Dialogue Request. In addition to the information elements of the Dialogue Request, it includes a Result field and a Result Source Diagnostic element. The result indicates whether the dialogue has been accepted. If a Rejection indication is returned, the dialogue does not continue. In cases where rejection occurs, the Result Diagnostic indicates why a dialogue is rejected.
As you can see from the descriptions, a number of the dialogue information elements are common across the dialogue APDU types. Following is a brief description of the dialogue information elements:
- Application Context Name— Identifies the application to which the dialogue components apply.
- Protocol Version— Indicates the version of the dialogue portion that can be supported. This helps ensure proper interpretation of the dialogue information between TC-Users when new versions of the dialogue portion are created.
- User Information— Information exchanged between TC-Users that is defined by and relevant only to the application. The contents of the user information element are not standardized.
- Result— Provides the initiating TC-User with the result of the request to establish a dialogue.
- Result Source Diagnostic— Identifies the source of the Result element and provides additional diagnostic information.
- Abort Source— Identifies the source of an abnormal dialogue release. The source might be the TC-User or the dialogue portion of the message.
- Dialogue Abort— The Dialogue Abort is used to terminate a dialogue before it would normally be terminated. The Dialogue Abort contains only an Abort Source and, optionally, User Information. The Abort Source is used to indicate where the Abort was initiated—from the user or the service provider.
The ANSI Dialogue can contain any of the following optional Dialogue elements. Note that the Application Context and Security can use either an integer for identification or an OID (Object Identifier). The OID is a common structure used for identifying objects in communications protocols by using a hierarchical tree notation such as "3.2.4."
- Dialogue Portion Identifier— This identifier indicates the beginning of the dialogue portion of the message. The following elements are included within this dialogue section.
- Protocol Version— Identifies the version of TCAP to be used in interpreting the message; for example, T1.114 version 1992 versus TCAP T1.114 version 1996.
- Application Context Integer/Application Context OID— Identifies the context in which to interpret the message. Since TCAP is generic and the operations must always be interpreted in the context of a particular service or set of services that use unique identifiers for each operation, this can be used to specify the context.
- User Information– —Provides additional information that is only relevant to the application, to assist the receiving TC-User (such as an application) in interpreting the received TCAP data. An example is including a version number for the application that uses the encapsulated TCAP components.
- Security Context Integer/Security Context OID— Used for establishing a secure dialog. The Security Context is used to determine how other security information, such as Confidentiality, should be interpreted.
Used to specify how confidentiality is accomplished by providing encryption/decryption procedures. It contains the following optional fields. If neither of these optional fields is included, the confidentiality information is not used because no specification exists regarding how information should be protected or interpreted.
Confidentiality Algorithm ID—
An integer or OID that identifies the algorithm to use for decoding encrypted data.
Any information that can be encoded using Basic Encoding Rules (BER). The BER are the ITU X.690 ASN.1 (Abstract Syntax Notation) rules for encoding information into binary format for transmission.
- - Confidentiality Algorithm ID— An integer or OID that identifies the algorithm to use for decoding encrypted data.