Chapter 8 - Overview of TCAP

Chapter 8 Overview of TCAP

		The Transaction Capabilities Application Part (TCAP) is designed for non-circuit related messages. These messages are destined for database entities as well as actual end office switches. The TCAP protocol provides a means for reliable transfer of information from one application at a switch location to another application within another network entity. To understand this, it is probably best to look at some of the actual applications and problems that we face in the telephone network today.

		The first usage of the TCAP protocol was 800 number translation. An 800 number cannot be routed through the telephone network, because the area code "800" does not specify any particular exchange. To overcome this problem, the number must be converted into a routable number. This requires a database.

		The database for 800 numbers provides a routing number which the local office can then use to route the call through the Public Switched Telephone Network (PSTN). This database is usually centrally located within the service provider's network. It does not make good sense to place this database in too many multiple locations, since that would make maintenance of the database more difficult.

		The problem with centralized databases is providing access to them. All switches in the network must be able to access the database and retrieve the routing number for the 800 numbers used in their network. To compound the problem, in today's network, all 800 numbers must be routable by all carriers. This means that no matter which telephone company "owns" the 800 number, all other telephone companies must be able to access the proper database and retrieve the routing number for that 800 number. This is known as transportable 800 numbers.

 

Making 800 numbers transportable also allows subscribers to keep the 800 numbers they have had provided by another carrier, even when they change carriers. Previous to the transportability ruling, if subscribers changed carriers, they had to surrender their 800 number and obtain a new number from the new carrier. This is no longer the case.

		The TCAP protocol provides the parameters and the services to maintain a dialog with a database. The protocol contains message types which are used by the Service Control Point (SCP) to query a database for specific information. This information is then carried back to the requesting central office switch using the same TCAP protocol. In short, TCAP messages are designed for accessing either a database or another switch and either retrieving information or invoking features using its parameters and message types.

		Cellular networks have the same types of needs, since they are very dependent on databases and remote control of switch features. The cellular networks have previously used proprietary networks, prohibiting the ability to access remote databases in other networks. It is for this reason that the cellular industry has begun deploying SS7.

		TCAP provides the mechanism for transferring information from one switch to another switch, even if they are a substantial distance apart. The information is not related to any one circuit (such as in an ISDN User Part (ISUP) message), and the information must be transferred through the network using end-to-end signaling.

		ISUP messages do not use end-to-end signaling, and must follow the same path used to establish the circuit connection. This means the message must be passed along from one exchange to another, with intermediate Signaling Transfer Points (STPs) through-switching the ISUP messages to the next exchange. This is one of the fundamental differences between TCAP and ISUP.

		Another difference between the two protocols is the transport used. ISUP uses the Message Transfer Part (MTP) for routing the message from one exchange to another. The MTP protocol does not support end-to-end signaling. So TCAP must use an additional protocol as a transport. The Signaling Connection Control Part (SCCP) protocol is used with MTP to route messages end to end.

		The SCCP protocol provides the additional controls needed when passing messages from end to end. However, MTP must also be used to provide the routing functions from one node to the next node. The MTP also provides the basic error detection and correction needed for reliable message transfer.

		Now that we have identified the mechanism used for through-switching informational messages from one exchange to another, we can begin looking at specific applications. There are many applications within the telephone company network. Many of these applications have not even been developed yet. We will talk about both present and future applications.

		We have already discussed the use of TCAP for accessing a database (using the 800 number scenario). There are many other databases used in the telephone network besides the 800 database. Every telephone number has records associated with it. These records identify who the subscriber is and what types of services they have subscribed to.

		These Line Information Databases (LIDBs) belong to the individual telephone companies that provide services to their subscribers. For this discussion, we will use the feature call forwarding as an example. Call forwarding allows subscribers to forward their phone calls to other subscriber telephone numbers, until the call forwarding is canceled. All calls to the subscriber telephone number are then redirected to the forwarded number.

		This feature requires the use of the LIDBs to verify that the subscriber is allowed to use this feature. When a subscriber invokes the forwarding feature, the information about where the call is forwarded to is stored in the end switch. The database is used when the feature is accessed (by dialing some sort of feature code). The database verifies that the subscriber is allowed to use this feature.

		This is probably the simplest of applications. Let's look at a more sophisticated function of TCAP. The TCAP protocol also provides the mechanism to access other remote switches and activate features within that switch. The switch must have the feature capability already; TCAP only invokes the feature remotely.

		Later, we talk about a scenario using another feature called automatic callback. In this feature, when a subscriber dials a number that is busy, the subscriber can enter in a feature code and hang up. When the dialed number becomes available, the local exchange notifies the caller's local switch by sending a TCAP message. This TCAP message allows the local switch to ring the phone of the caller. The distant switch has reserved the called party's line so no other phone calls can be routed to it.

		When the calling party answers the phone, normal call setup procedures are used to establish the connection between the two exchanges. TCAP, in this case, serves as an alerting mechanism, sending an informational message (not circuit related) to another entity within the network. This can be extended to many other types of applications where remote invocation is an option.

		In the cellular network, TCAP has become the solution to roaming. Prior to the deployment of SS7 in the cellular network, when cellular subscribers took their phones to other areas serviced by other cellular providers, they would have to call ahead and obtain roaming numbers. The roaming number was only good for a specific geographic area (regional service area [RSA]).

		When the roaming number was dialed, the cellular network immediately knew how to route the call, because the roaming number could be routed like any other Plain Old Telephone Service (POTS) number. The problem was that roaming was not seamless and required user intervention.

		Some cellular subscribers found themselves having to have two and three numbers for their cellular phone, depending on where they were. This defeats the purpose of having a mobile telephone. This was the reason for the seamless roaming.

		The missing element was the ability to update the network databases with the current location of the cellular telephone subscriber. This information is updated every few minutes by the cell site sending a message to the mobile switching center (MSC) identifying the mobile subscriber and the cell site reporting the subscriber's presence.

		An application entity called IS-41 provides procedures for updating databases on the status of cellular subscribers. Every cellular subscriber has a home database, called the Home Location Register (HLR), which keeps a record on where the cellular subscriber is located. This record is what gets updated every few minutes.

		TCAP is used to carry these update messages from one database (the Visitor Location Register [VLR]) to the subscriber's HLR. When a call comes in for the subscriber, the call is routed to the home regional service area, which must then look at the HLR to determine how to connect the call to the subscriber. The HLR then provides the information (location and status) so the PSTN knows how to connect the call.

		When the subscriber moves to another area, the TCAP protocol is used once again to update the HLR on the new location and cancel the subscriber's registration in the previous regional service area. This is completely transparent to the subscriber and allows cellular subscribers the freedom to move around the network without ever having to register with other service providers. The network keeps track of their locations the entire time the cellular phone is activated.

		In the Intelligent Network (IN), TCAP is the protocol that will be used to invoke features in remote switches. As we discussed earlier with the automatic callback feature, TCAP allows features to be activated and deactivated remotely. In the IN, services will be activated and deactivated the same as features.

 

	Services include high-speed data transmission or video circuit connections. TCAP will provide access to the database, which will activate these services for the subscriber. As we discussed in the first chapter, subscribers will activate and deactivate these services through a terminal located on their premises and connected to the SS7 network via a data link.

		TCAP Functionality

		The TCAP provides a way for end users in the SS7 network to access other end users on a peer-to-peer level. In the SS7 network, end users are seen as applications within the network entities.

		The SS7 protocol provides a means for database access between signaling points as well as access to remote operations. The latter function is somewhat newer to the SS7 protocol stack, and is slowly finding applications in the network. The Advanced Intelligent Network (AIN) will depend heavily on the ability for a signaling point to access another signaling point remotely and to invoke an operation or feature within the remote signaling point.

		The cellular network also depends today on remote access to other signaling nodes. For example, when a cellular switching center needs to hand over control of a call to another switching center, signaling information regarding that call must be transferred to the remote switching center. SS7 provides the means to accomplish this task.

		In the IN, features such as automatic callback require the ability for an end office switch to send a message to another end office switch concerning the status of a previously called number. SS7 provides this ability.

		The protocol used for these types of transactions is the TCAP. The TCAP protocol originally provided database access, yet the intention has always been there to provide the facilities within the protocol to invoke remote features and access remote applications within the signaling network.

		Description of TCAP

		An application uses an application process to communicate with the other entities in the network. The application process then communicates with the TCAP and other protocols to transfer the information across the network.

		The function that allows applications to communicate with one another is a communications function called the application service element (ASE). The TCAP and the MAP are both examples of ASEs (see Figure 8.1).

 

		Figure 8.1 The ASE provides a communication interface to application entities (AEs) such the MAP and the Operations, Maintenance, and Administration Part (OMAP).

		An application service element provides the communications services for applications within any signaling point. These communications are peer-level communications. An application process acts as the coordinator of network services such as ISDN call setup and mobile services. The application process can be found below the function of applications, but above the ASE.

		An application can use more than one application service element for any one transaction. This is necessary to provide flexibility in the communications function, allowing the addressing of multiple entities within one message.

		Another method of reaching several entities within one transaction is the use of subsystem numbers for addressing. The subsystem numbers found in the called and calling party addresses in SCCP are the addresses of applications. By using a subsystem number rather than a point code, the transaction message can be sent to multiple signaling points or can even be rerouted by network management in the event of a failure.

		One of the newer protocols to join TCAP is the MAP. This protocol is found in IS-41 cellular networks, and is used for transporting roaming information and other signaling from one cellular network to another.

		The TCAP and the MAP protocols are capable of transferring information and invoking operations within other entities. This is probably the most important aspect to understanding that these protocols not only transfer information from one to another, but also invoke operations (or tasks) within a remote entity. An operation may be a particular function within the switching equipment or a database located at an end node.

		The TCAP protocol is capable of both invoking an operation and returning the results of that operation, using the services of the SCCP protocol. SCCP provides the network services, while the MTP provides the physical layer and data link layer functionality.

		An application process is considered a function above layer seven of the OSI model. An example of an application may be the LIDB or OMAP. These applications are found in various signaling points, depending on the location of the signaling point in the network and its function within the network (i.e., STP, gateway STP, or translation STP).

		In order for an application to send information and communicate to another application at a remote signaling point, a communications protocol must be used. This protocol should be able to address the application and invoke an operation or task within the application. For example, if a node needs to invoke a CLASS feature at a distant node for a call in progress, a message would need to be sent to the distant signaling point informing it of the operation needed. The receiving signaling point should be given enough information about the call to be able to invoke the specified CLASS feature.

		The address of the message sent would be of the application providing the operation. This address is not an address used within the rest of the network, but references only the various applications supported within a network. The addressing scheme used for these applications is the subsystem number. The subsystem number does not have to be known at every node within the network. Global title can be used to route a message to the adjacent node of the application, at which point global title translation must provide the subsystem number and the point code of the application.

 

Today, only connectionless services (datagram) are supported. In some cases, a connection with a peer application may be necessary, in which case connection-oriented services must be employed to establish a connection with the application and maintain the connection until the originating signaling point has completed its transactions.

		In the U.S., support of connection-oriented services is not yet endorsed. Both ANSI and Bellcore standards mention connection-oriented services and even define their functions. Yet, no application requiring connection-oriented services has emerged. Connectionless services are supported and are what U.S. networks use for communicating between application processes.

		Because datagrams are used for information transfer between applications, some sort of reference must be used to associate multiple messages to a single transaction and multiple components to a single operation. Two forms of referencing are used: the transaction ID and the invoke ID.

		A transaction ID is used as a reference within a dialog so the receiver can associate the received message with a transaction in progress. This transaction ID is significant only to the local receiver, but is sent to the remote as a reference to be used in any responses.

		An invoke ID is used to identify invoke components which are used to invoke an operation within the entity. One transaction may consist of several invokes. The receiver of an invoke is typically expected to respond with a return result, in which case a correlation ID is used to identify which invoke component the result is referencing. The correlation ID is a mirrored image of the invoke ID.

		ASP Services

		The Application Service Part (ASP) consists of the layers above the SCCP and below the TCAP. It provides the functions of layers four through six of the OSI model. These functions are not presently required in the SS7 network, and are under further study; however, the ITU-TS and ANSI standards do reference these as viable functions.

		The lack of connection-oriented services in today's network is why the ASP is not currently needed. However, as the network matures and new technologies emerge, connection-oriented services will become a necessity for certain applications. This will force the need for the functions of these middle layers.

		TCAP Message Structure

		The message units within TCAP are partitioned into three portions: the transaction portion, the component portion, and the dialog portion. The transaction portion provides the information necessary for the signaling point to route the component information to its destination. Included in the transaction portion is the transaction ID, which is used as a reference for tracking all TCAP messages.

		The component portion gets its information from the operation protocol data unit (OPDU), received from the application. The OPDU contains the primitives and parameters necessary to invoke an operation or request services from another entity (such as database query).

		The dialog portion is used to identify the version of transaction being used. It also provides security information if encryption is used on the transaction. The dialog portion is an optional field within TCAP.

		To fully understand the structure of these primitives, review the section in the chapter for SCCP, titled ''Primitives." This section discusses the use of primitives and interfaces between SCCP and MTP. The structure of all primitives is the same throughout the layers of SS7. The interface between TCAP and the lower layers of the stack looks like:

		P-UNITDATA Generic Name Specific Name Parameter

		The P- indicates the location of the interface. These primitives consist of the same generic names described in the SCCP chapter (see Chapter 7). The specific names used are described in the following paragraphs.

		The operation protocol data unit consists of several types of data units. Each type indicates the type of service or operation to be invoked by the receiver. These OPDUs are then carried through the SS7 network in the form of a TCAP message. The component portion of the TCAP message is used to transport these OPDUs to their destinations. The following OPDUs are found in TCAP:

		Invoke

		Return result

 

Return error

		Reject

		The Invoke OPDU is used to request an operation from another application. For example, for the MAP to be able to notify a remote MSC to take control of a cellular call in progress, an Invoke OPDU must be created from the originating MSC. The invoke OPDU is then used to form a TCAP message which, in turn, is transferred to the destination MSC through the SS7 network.

		Upon receipt of the Invoke message, the remote MSC then initiates the operations required using the parameters provided in the component portion of the TCAP message. The Invoke may require a return message to indicate successful completion of an operation. The Return Result OPDU is used by the destination application to indicate successful completion of an operation. This, in turn, creates the appropriate TCAP message, with the component portion carrying the Return Result and its parameters.

		If the operation was unsuccessful, a Return Error or Reject OPDU is created at the destination MSC and used to create the TCAP message to be returned to the originator of the invoke message.

		TCAP messages contain information elements that are used to convey the information being transported to the remote application. These information elements are always structured the same, regardless of their contents. The first field of every information element is the tag (referred to as an identifier in ANSI).

		The tag (or identifier) indicates the type of information element being sent and, in doing so, allows the receiver to determine how the contents will be interpreted. The tag is one octet and is coded to describe the handling of the contents (see Figure 8.2).

		Following the tag is the length field. The length field indicates the number of octets to be found in the contents field. The contents field is the location of the information being conveyed. This is not a fixed field, but a variable, depending on the type of components used.

		The contents field consists of one or more components. In the case where more than one information element may exist in the contents field, the same structure as previously described is used (that is, tag, length, and contents) for each information element. However, the length field indicates the length of the individual information element rather than the whole information element and all its components.

		Figure 8.2 Tag class from ITU Q.733.

 

		The tag is coded with a class, form, and tag code. The tag code may exceed the one-octet length in some cases, but is usually maintained within the first octet. The structure of a tag is shown in Figure 8.2.

		Tag Class

		The tag class is used to indicate whether this particular information element uses a common structure or if the contents are proprietary. This information is used by the receiver to determine how the message is to be interpreted and handled. As seen in Figure 8.2, the tag class uses bits HG. There are four values in this field:

Universal	0 0
Application-wide	0 1
Context-specific	1 0
Private use	1 1

		The universal tag is one that is compliant with ITU-TS Recommendation X.208 and is used for all types of application entities. Universal tags are compatible with other recommendations and can be used with X.400 MHS, as well as with other ITU-TS standards.

		Application-wide indicates that the tag can be used with all applications within the SS7 standard. These tags do not conform to any other recommendations. Application-wide tags in the U.S. refer to the international standardized TCAP.

		Context-specific indicates that the context of the received information is determined by the preceding component (information element). When more than one component is necessary, the first component received indicates how subsequent components are to be interpreted (if they carry a tag class of context-specific). The same component in a different message may be interpreted differently, depending on its usage within that message. Context-specific is used with components that are part of a series of components. These are referred to as constructors, meaning that each component builds off another.

		The private use class indicates that the component is specific to a national standard (such as ANSI) or a private proprietary standard. ITU-TS recommendations indicate that this field is used for national or private use and does not define any of the components that use this tag class. The ANSI standards do define specific national TCAP components not found in ITU-TS that are coded as private class.

 

		Form

		An information element may require subsequent information elements or may be a single value. The F bit is used to code each information element as either a primitive (single value) or constructor (multiple information elements). The values are shown as follows:

Primitive	0
Constructor	1

		Tag Code

		The code indicates the type of information element being sent. This field is expandable beyond the five-bit structure by using extension bits. In the event that an extension is needed, the first five bits (EDCBA) of the first octet in the identifier are set to 11111. This indicates that the tag code is found in the second and subsequent octets. If the second octet is extended, bit H is set to 1, indicating an extension. In each subsequent octet, bit H indicates whether there is an extension (1) or no extension (0).

		In the following discussions, each information element and its contents will be described. The coding (national, private, primitive, etc.) will be provided within the description.

		The TCAP message (Figure 8.3) consists of three parts, as mentioned previously. The first part is labeled the transaction portion, and provides the information necessary to identify the nature of the transaction. The transaction portion is a mandatory field for all TCAP messages.

		The second part is labeled the dialog portion, and is used to identify the version of the transaction as well as security information (in the event the transaction is encrypted). This part was recently added to TCAP.

		The third part is labeled the component portion and is the part that contains the contents of the primitives sent down from the various applications. The component portion also contains the parameters that identify the specific details of the TCAP message. A dialog is maintained by sending a series of components in one or more TCAP messages and correlating those which are associated with a specific transaction and operation.

		The protocol provides various parameters within the component portion that allows it to emulate a logical connection (hence, fulfilling the need for connection-oriented services without the need for connection-oriented SCCP).

 

		Figure 8.3 This figure shows the components of a TCAP message.

Package Type	H	G	F	E	D	C	B	A
Unidirectional	1	1	1	0	0	0	0	1
Query w/Permission	1	1	1	0	0	0	1	0
Query w/out Permission	1	1	1	0	0	0	1	1
Response	1	1	1	0	0	1	0	0
Conversation w/Permission	1	1	1	0	0	1	0	1
Conversation w/out Permission	1	1	1	0	0	1	1	0
Abort	1	1	0	1	0	1	1	0

		Figure 8.4 These are the package types used in TCAP.

		Following is a description of all the fields within the transaction portion.

		Package Type Identifiers

		The package type identifier describes the type of transaction being sent (see Figure 8.4). A transaction may be a one-way transmittal, or it may require a two-way dialog. These requirements are determined by the package type. The following descriptions provided describe the function of each of these package types in a connectionless environment. Connection-oriented services are discussed separately, since these services are not yet implemented in U.S. networks.

		Following is a description of each package type identifier and its mandatory values. An asterisk in front of a parameter indicates that the field is mandatory but may be empty (set to all zeros).

		Unidirectional

		This type of TCAP is sent in one direction only and does not require a return message (or response). No transaction identifier is required for unidirectional messages. Unidirectional messages are used for sending information to an application when a transaction does not need to be established. No correlation between multiple components is necessary.

		The unidirectional TCAP consists of the following fields (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

		*Transaction identifier (null) (M)

		*Transaction ID length (null) (M)

		Dialog portion (O)

		Component sequence identifier (M)

		Component sequence length (M)

		Query with Permission

		A Query is used to access information stored within a database. It is also used to initiate the transaction, and triggers the assignment of a transaction identifier. If a dialog is to take place, a Query will be followed by a Conversation. The dialog allows for information to be exchanged between the two applications without impediment.

		The receiving signaling point of a Query With Permission is granted permission to end a transaction if it deems it necessary. Upon receipt of a Query With Permission, the receiving application must decide whether it wishes to establish a transaction and maintain a dialog (using Conversation components). In the event that it does not wish to establish a transaction, the Response component is sent. This releases the application from any transaction. No transaction ID is established.

		If the receiving application does wish to establish a transaction, the Conversation component is sent (either with or without permission), and a dialog can be maintained between the two applications.

		When an application needs to enter into a transaction with a remote application, and it does not anticipate sending additional components for the transaction, a Query With Permission is generated.

		The Query With Permission consists of the following fields (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

		Transaction ID identifier (M)

		Transaction ID length (M)

		Originating transaction ID (M)

		Dialog portion (O)

		Component sequence identifier (M)

		Comment sequence length (M)

		Component sequence (M)

		Query Without Permission

		The Query Without Permission is identical to the Query With Permission for the exception of the permission granted. The receiver of this message is not granted permission to end the transaction. This, of course, does not include termination for network management reasons. As mentioned in the preceding paragraph, ending a transaction is accomplished by releasing the transaction ID.

		When an application needs to enter into a transaction with a remote application, and the originator of the transaction anticipates additional components related to the transaction to be sent, a Query With Permission is generated. This prevents the remote application from ending the transaction before all the components have been received.

		The Query Without Permission consists of the following mandatory parameters (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

 

Transaction ID identifier (M)

		Transaction ID length (M)

		Originating transaction ID (M)

		Dialog portion (O)

		Component sequence length (M)

		Component sequence identifier (M)

		Component sequence (M)

		Response

		The Response is used to end a TCAP transaction. In the case of a Query, the Response is used to return the requested data. In the case of a dialog between two applications, the Response is the last transmission sent.

		The Response consists of the following parameters (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

		Transaction ID identifier (M)

		Transaction ID length (M)

		Responding transaction ID (M)

		Dialog portion (O)

		Component sequence identifier (M)

		Component sequence length (M)

		Component sequence (M)

		Conversation with Permission

		This TCAP message is sent after a Query, and is used to carry out a dialog between two applications. The package type Conversation continues between the two entities until the transaction is complete, at which point a Response is sent by either party.

		When the Conversation component is sent, the transaction ID received from the originating node is duplicated and placed in the originating transaction ID field. Besides the originating transaction ID, the receiving node also creates a transaction ID corresponding to the transaction established locally. This transaction ID is significant only to the remote application and is placed in the responding transaction ID field.

 

Once the Conversation component is sent, all subsequent messages must contain one of the Conversation components (with or without permission). This component is then used to maintain a dialog between the two applications until the transaction is finished and one of the applications sends a Response component.

		The Permission indicator grants the receiver of this message the ability to end the transaction (by releasing the transaction ID). Either party can end the transaction.

		Permission is granted when an application has responded to all received components and does not anticipate the need to send further components related to a transaction. In essence, the application uses the permission indicator to ensure that the transaction is maintained until all the components related to a specific transaction can be sent. This prevents the remote application from ending the transaction prematurely.

		If an application during a dialog determines the need to gain control over the release of a transaction (even if it previously relinquished control), then it may send a Conversation Without Permission even when it had previously relinquished control.

		A transaction is ended by an application sending a Response component. The transaction can be ended even when permission is not granted in special circumstances (resource management intervention, for example).

		The Conversation With Permission consists of the following parameters (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

		Transaction ID identifier (M)

		Transaction ID length (M)

		Originating transaction ID (M)

		Responding transaction ID (M)

		Dialog portion (O)

		Component sequence identifier (M)

		Component sequence length (M)

		Component sequence (M)

		Conversation Without Permission

		This message is the same as the Conversation With Permission for the exception of being able to end a transaction. As previously described, this component is sent to prevent the remote application from ending a transaction before the originating application has completed transmission of all its components. It consists of the following parameters (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

		Transaction ID identifier (M)

		Transaction ID length (M)

		Originating transaction ID (M)

		Responding transaction ID (M)

		Dialog portion (O)

		Component sequence identifier (M)

		Component sequence length (M)

		Component sequence (M)

		P-Abort

		A P-Abort is used when the originating entity must end a transaction. It is important to remember that when a transaction is aborted or ended under normal conditions, the application is responsible for the action. A transaction can be ended by the protocol or lower layers of the stack in a number of ways. At this level, the TCAP identifies why the abort was necessary (as determined by the application) and forwards the reason or causes to the remote entity.

		The P-Abort consists of the following parameters (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

		Transaction ID identifier (M)

		Transaction ID length (M)

		Responding transaction ID (M)

		Dialog portion (O)

		P-Abort cause identifier (M)

		P-Abort cause length (M)

		P-Abort cause (M)

 

U-Abort

		The User abort is used when the User of TCAP aborts a transaction. It is used in the same way as the P-Abort, but contains slightly different information. Tbe U-Abort consists of the following parameters (an M indicates a mandatory field, while O indicates an optional field):

		Package type identifier (M)

		Total TCAP message length (M)

		Transaction ID identifier (M)

		Transaction ID length (M)

		Responding transaction ID (M)

		Dialog portion (O)

		U-Abort information identifier (M)

		U-Abort information length (M)

		U-Abort information (M)

		Each of the package types identified here contains a number of additional parameters (as noted in the preceding descriptions). These parameters contain the specific information regarding the transaction taking place.

		These package types are identified in the transaction portion. Following the transaction portion is the dialog portion. The dialog portion contains information regarding the version of the transaction and security information if any of the transaction is encrypted. The dialog portion is an optional part of TCAP. Following is a listing of each of the dialog portion fields:

		Protocol version identifier

		Protocol version length (O)

		Application context identifier (O)

		Application context length (O)

		Application context name (O)

		User information identifier (O)

		User information length (O)

		User information (O)

		Security context identifier (O)

		Security context length (O)

 

Security context (O)

		Confidentiality identifier (O)

		Confidentiality length (O)

		Confidentiality information (O)

		The application context fields are only used in unidirectional, query, user abort, and the first backward conversation or response TCAP messages.

		Following the dialog portion is the component portion, which consists of one or more components. The component structures were described earlier as ''information elements." Each information element may be a primitive (single value) or a constructor (multiple components).

		The component types listed consist of the information elements described earlier. An identifier is used as a tag for an information element. The parameters for each of these fields are described later in the chapter. They are listed here as an introduction to the structure of a TCAP message. Following is a listing of each of the component types and the fields that are sent with each component:

		Invoke Component

		Component type identifier

		Component length

		*Component ID identifier

		*Component ID length

		*Component IDs

		Operation code identifier

		Operation code length

		Operation code

		*Parameter set/sequence identifier

		*Parameter set/sequence length

		*Parameter set/sequence

		Return Result Component

		Component type identifier

		Component length

		*Component ID identifier

		*Component ID length

		*Component IDs

 

Parameter set/sequence identifier

		*Parameter set/sequence length

		*Parameter set/sequence

		Return Error Component

		Component type identifier

		Component length

		*Component ID identifier

		*Component ID length

		*Component IDs

		Error code identifier

		Error code length

		Error code

		*Parameter set/sequence identifier

		*Parameter set/sequence length

		*Parameter set/sequence

		Reject Component

		Component type identifier

		Component length

		*Component ID identifier

		*Component ID length

		*Component IDs

		Problem code identifier

		Problem code length

		Problem code

		*Parameter set/sequence identifier

		*Parameter set/sequence length

		*Parameter set/sequence

		All component fields are mandatory. Those with an asterisk indicate mandatory fields that can be empty (all bits set to zero, or null). The length indicators provide the number of octets for the fields immediately following, not including the length field itself. This and all other fields are explained further later in this chapter.

 

Again, the two portions of the TCAP message are used in different ways. The transaction portion is used by the receiver of this message to determine which transaction this message is associated with (if one is in progress) or to begin a new transaction. The component portion is used by the receiver to invoke an operation at a remote application. The component portion may consist of one or more information elements providing a sequence of operations to be performed. Each of these information elements can be correlated through a correlation ID, which is used to associate multiple components to an operation.

		Connectionless TCAP Functionality

		The connectionless services deployed in today's network provide for some connection-oriented emulation. However, there have been procedures defined for connection-oriented services in both the ANSI standards and Bellcore standards. This indicates that there may come a day when TCAP and SCCP will need to support full connection-oriented services.

		There are three levels of identification provided for transactions and their operations. The first and highest level of reference is the transaction ID. The transaction ID is used when multiple transactions are sent to an application to correlate the received transaction with other transactions already in progress. But within a transaction may be components related to multiple operations.

		The correlation ID is used to correlate multiple components to a component already received. The receiver of a TCAP transaction associates the transaction ID to an earlier transaction, and then correlates the various components to operations already in progress based on the correlation ID. It is also the correlation ID that keeps multiple components associated with one another.

		When an Invoke component is sent, it may or may not require a response. The response sent must reference the Invoke it is associated with. This is done through the Invoke ID. The invoke ID is then mirrored in the Return Result component's correlation ID. When a component is responding to an Invoke component, it must also be determined whether this is the last component or if additional components will be sent as a response. This is determined by the TCAP function using the Invoke (last/not last) and Return Result (last/not last) components.

		You cannot have multiple operations using the same invoke ID. The invoke ID cannot be reassigned until all the components expected have been received and all Return Results have been sent. The application will then inform the application process to end the transaction, which releases all transaction IDs, correlation IDs, and invoke IDs associated with the transaction.

		The application process provides the necessary data to TCAP for invoking an operation. When an invoke is requested, the components and their parameters are provided to TCAP for inclusion in an Invoke message. There may be more than one transaction at one time, and each transaction may have multiple operations running concurrently. TCAP must be able to address these operations individually and as a group.

		TCAP can send multiple components and address multiple operations in one TCAP transaction. This means that a single TCAP message may contain information for several operations that are not associated. The use of the correlation ID and transaction ID keeps the various parameters straight within a TCAP transaction.

		Handover Procedures

		An application can request the application process to send a component or multiple components to another remote application entity for processing. When this occurs, a handover must be generated by TCAP. The handover may be temporary or permanent.

		The purpose of the handover is to send the information required of the remote application to perform the operations being requested of it. A single component may be all that is required, or several components may be required. In the case of a temporary handover, any responses by the new application are sent to the application that initiated the handover.

		When a permanent handover occurs, the new application can be directed to send all responses directly to the originating application. In essence, the application is directed to assume control of the transactions and operations being requested. The application does not have any knowledge of the application that requested the handover. All transactions are treated as if they were addressed directly to the application.

		The information required of the application is provided in an Invoke component, which possesses the handover operation parameter. For example, if a dialog is in progress between applications A and B, with B being the remote application and A being the originating application, B would send an Invoke component to application C with the temporary handover operation. Besides the temporary handover operation, the transaction ID of B, the SCCP calling party address of B, and the package type that application C should use in its messages to application A are all provided as parameters of the Invoke component.

 

	Recovery Procedures

		In the event that an error occurs, TCAP invokes one of three levels of recovery procedures. The three levels of recovery correspond directly with the three types of errors that could occur. Errors can be classified as protocol errors, application errors, or end-user errors. Application errors are detected first, then application errors, and then end-user errors.

		TCAP defines only the procedures used to recover from errors between TCAP and the application process. Any error procedures within the application process or the application are implementation dependent and beyond the scope of the SS7 standards. TCAP is responsible for reporting the errors to the application process, which, in turn, will report it to the application, which determines the correct recovery procedure if the error is at the application level.

		Protocol Errors

		Protocol errors involve incorrect TCAP messages. Incorrect means the TCAP message contained package types or components that are invalid (or unrecognized), called for an operation that the application process did not recognize, or referenced a transaction ID or correlation ID that was not in progress.

		Protocol errors can be detected by TCAP or the application process. It is reported to the remote application process using the Reject component. The Reject component must also provide the type of error (cause). This is sent to the remote application process that is then responsible for recovering from the error.

		These types of errors are different from other protocol errors in the way recovery is invoked. In most protocols, when an error is detected by a remote entity, the remote entity discards the erred packet and requests a retransmission. In TCAP, the erred packet is still discarded, but a Return Result is sent back to the originator to inform them why the packet was rejected. It is then up to the originator of the erred message to determine if retransmission is necessary. If the application process decides to retransmit, the message is re-sent as if for the first time.

		Application Errors

		Application errors are errors involving the application process, and indicate a violation of the application process procedures. These errors can also indicate common resources (such as recordings) that are unavailable.

 

An unexpected sequence of components and an unexpected data value are also types of errors that occur at the application process level. These errors mean that the application process was expecting components in an order different from how they were received (in comparison to a script or some other program). An unexpected data value means that data was received which does not match what should have been received for the received component.

		A missing customer record and overdue reply are also listed as possible causes of application errors. These errors are reported using the Return Error component.

		End-user Abnormalities

		These errors are found last by the application process, and indicate an error caused by the end user of the application. Two causes cited in the ANSI standard are caller abandonment and improper call response.

		Caller abandonment indicates that a caller hung up before the transaction could be completed. This does not necessarily mean that an error occurred, but that the transaction could not be completed as normal.

		Improper caller response indicates that a caller did not dial the proper information during a call where callers are asked by a recording to input some form of information (such as the calling card number when billing a call to a calling card).

		Reject Component

		The Reject component reports many of these errors. In the Reject component, the type of problem is identified and the problem is identified. The type of problem is divided into categories that correspond to the various portions of the TCAP message structure. Errors are identified as transaction portion, general, Invoke component, Return Result component, or Return Error component.

		Errors in the transaction portion are identity errors occurring within the transaction portion of the TCAP message. These include the package type and transaction ID. The errors are reported using the Reject component, and they report errors in the transaction portion of the message.

		The type of errors that can occur in the transaction portion include an unrecognized package type, a badly structured transaction portion, an unrecognized transaction ID, a permission release problem, or an unavailable resource.

 

Unknown package types indicate that a package type was indicated but is not defined as received in the signaling network. In the case of an international network, this would indicate that a package type is not defined in the ITU-TS standards. The package type is the parameter that identifies what type of TCAP message is being sent and is used by the receiver to determine how to handle the received message.

		A badly structured transaction portion indicates a problem with the encoding of the message. For example, the length may not be as indicated, or may be in conflict with the expected length for the indicated package type. The total TCAP message length is used to indicate the length of the entire TCAP message.

		An unrecognized transaction ID indicates that the transaction ID indicated in the message is not currently in progress. Either the transaction has been ended and the transaction ID released or the message has an incorrect transaction ID. The receiver of this message is responding to a previous Invoke or Conversation component that provided the transaction ID of the originator. This message could also indicate that the originating Invoke component may have had an incorrect originating transaction ID, which is mirrored and returned with any responses.

		A permission to release problem is an error currently under study and is not presently defined. The only mention of this error is in the ANSI T1.114 standard. It does not appear in the Bellcore TR-NWT-000246 publication.

		When applications require other resources, such as recordings, there may come an instance when those resources are not available. When this happens, the operation being requested is rejected. The originating application can then determine whether to try again later.

		General problems are related to problems recognizing the component portion, or indicate some problem with the component portion. This includes an unrecognized component type, an incorrect component portion, or a badly structured component portion. In all these cases, the component portion cannot be recognized and is rejected. These errors are not related to problems with the various components inside the component portion. These errors indicate a problem with the entire component portion itself.

		Along with problems with the component portion, there may occur errors within each component. The protocol is capable of reporting errors related to specific component types. Error reports for Invoke components, Return Result components, and Return Error components can be generated when a problem is detected with the component itself. A problem with one component does not reflect a problem with the entire transaction-only with the specified component. Therefore, the rest of the components that may exist within the component portion may be processed without error, unless they are all associated with the same operation, in which case the whole transaction is affected.

		Invoke component errors include the receipt of duplicate invoke IDs, unrecognized operation codes, incorrect parameters, or unrecognized correlation IDs. Duplicate invoke IDs and correlation IDs indicate that these numbers have already been assigned for an operation or transaction already in progress and cannot be reused until they are released. An unrecognized operation code indicates that the received operation code is not presently defined, and an incorrect parameter indicates that a parameter other than what was expected was received.

		There are three types of errors related to the Return Result component. When a component is received with a correlation ID that is not recognized (because it does not match any transactions in progress), an error is returned as unrecognized correlation ID. An Invoke component that was not successful may result in the return of a result that is not expected (other than a success indication). In this event, an unexpected return result error is generated. If a parameter is undefined or unexpected (does not match what should have been received for the type of component), an error of incorrect parameter is returned.

		Errors related to the Return Error component include unrecognized correlation ID, unexpected return error, unrecognized error, unexpected error, and incorrect parameter. An unrecognized correlation ID indicates that the correlation ID received does not match any operation presently in progress.

		An unexpected return error occurs when a return error component is received that does not report failure of the invoked operation. A return error may also contain an unrecognized error, which is one not defined by the application process. If the returned error is not applicable to the invoked operation, then it is marked as unexpected. An incorrect parameter or unexpected parameter will also generate an error.

		Return Error Component

		This component is used to report a failure of an operation. It is also possible for this component to report the success of an operation and the failure of an operation. At any rate, the operation fails.

		Included in this component is the error that occurred and the application process that was in error. If an invoke ID or correlation ID was provided in either the Invoke component or the Return Result component, then it also is reflected in the Return Error component.

		Return Result Component

		This component reports the success of an operation. It also reports any end-user errors that may have occurred. The successful operation is identified, as well as parameters that identify the end-user error.

		And end-user error does not necessarily cause an operation to fail. The invoked operation may be successful, but may have caused a problem within the application entity. This would cause the Return Result to report the end-user failure.

		Problems relating to the transaction portion of the TCAP message follow a different procedure. Since the transaction portion is what the receiver uses to determine the handling of a received TCAP, any errors result in the application process not knowing how to handle the message. The usual procedure in this case is to discard the message. There are instances, however, when this is not favorable. Whenever enough information can be obtained from the message, some sort of error report should be returned to the user, indicating the type of error. The Abort component is used to report such errors.

		The Abort component is used whenever any type of component is received where either the originating and/or responding transaction ID can be derived from the message. In all other instances, the TCAP is discarded, with no report to the user. Without the transaction ID, any report to the user would be fruitless.

		Definition of TCAP Parameters

		The preceding section describes the various functions of the TCAP message and its components. This section identifies the values of these components and their parameters. The values given are derived from the Bellcore TR-NWT-000246 publication, Issue 2, Revision 2, December 1992.

		Transaction Portion

		The transaction portion (Figure 8.5) identifies whether or not the component portion consists of a single transaction or multiple transactions, and alerts the receiving application as to how to handle the message. Important to the receiver is the type of structure used within TCAP. This is determined by the package type. Also significant is the length of the TCAP message in its entirety.

 

		Figure 8.5 This figure identifies the components of the transaction portion.

		The transaction portion provides the necessary data for the receiver to be able to determine the nature of the message and its relation to any existing transactions in progress. Following are the package types and their bit values used in the transaction portion to identify the type of TCAP message being presented.

Package Type Identifiers	H	G	F	E	D	C	B	A
Unidirectional	1	1	1	0	0	0	0	1
Query With Permission	1	1	1	0	0	0	1	0
Query Without Permission	1	1	1	0	0	0	1	1
Response	1	1	1	0	0	1	0	0
Conversation With Permission	1	1	1	0	0	1	0	1
Conversation Without Permission	1	1	1	0	0	1	1	0
Abort	1	1	0	1	0	1	1	0

		Total TCAP Message Length

		This indicates the total length of the TCAP message (including all components and parameters). Within each component in the component message is a length indicator to indicate the length of that individual component. All variable parameters also include length indicators.

 

Transaction ID Identifier 1 1 0 0 0 1 1 1

		This indicates that a transaction ID is present and will follow this field, it is coded as national, primitive (see discussion in previous section describing the encoding used for national and international messages). As mentioned in the discussion at the beginning of this chapter, the transaction ID is of local significance only. This identifier only suggests the presence of the transaction ID and does not represent the ID itself.

		Transaction ID Length

		This indicates the length of the transaction ID, including both the originating and responding transaction ID, if applicable. If the package type is unidirectional, the length will be equal to zero. Only the unidirectional package type will have a length of zero, because a transaction ID is not assigned to this package type.

		If the package type is one which contains only the originating transaction ID, the length will be equal to four octets. The originating ID is sent to the remote application to be used as a reference in any responses.

		If the remote application is sending a component which will require a response of some nature, then the originating transaction ID and a response ID will be sent. The originating transaction ID is sent to associate the response to the transaction of the originator. The response transaction ID is sent to be used by the originator when it sends a response back to the remote application. These dual transaction IDs occur when there is a dialog between two applications, and Invoke components are sent from one entity to another.

		Transaction IDs

		The number of transaction IDs given depends on the package type. The following indicates when multiple transaction IDs are provided.

Package Type	Originating ID	Responding ID
Unidirectional	No	No
Query With Permission	Yes	No
Query Without Permission	Yes	No
Response	No	Yes
Conversation With Permission	Yes	Yes
Conversation Without Permission	Yes	Yes
Abort	No	Yes

		Originating Transaction ID

		This identifies the transaction ID assigned by the originator of the message. The length is four octets, and it is the first field when multiple transaction IDs are presented.

 

As previously described, this is sent by the originator to the remote application to be used as a reference in any responses.

		Responding Transaction ID

		This identifies the transaction ID generated by the responding application. This is independent of the originating transaction ID, and is of significance to the responding application only. This field is used when the responding application expects a response from the originator of an Invoke operation component. This is a four-octet field and follows the originating transaction ID.

		P-Abort Cause Identifier 1 1 0 1 0 1 1 1

		This identifier indicates that the Abort cause value follows. This identifier is coded as national, primitive. An Abort cause is sent when a transaction is aborted before it had time to get completed. An Abort, as described earlier, indicates a problem within the application entity rather than a protocol error.

		P-Abort Cause Length

		The length does not include this and the identifier field-it includes only the cause field. The cause field is always one octet in length; thus, this field will always carry a value of one octet.

P-Abort Cause	H	G	F	E	D	C	B	A
Unrecognized package type	0	0	0	0	0	0	0	0
Incorrect transaction portion	0	0	0	0	0	0	0	1
Badly structured transaction portion	0	0	0	0	0	0	1	0
Unrecognized transaction ID	0	0	0	0	0	0	1	1
Permission to release problem	0	0	0	0	0	1	0	0
Resource unavailable	0	0	0	0	0	1	0	1

		The cause code informs the receiver of an Abort and what caused the application process at the remote end to suddenly abort a transaction in progress. An unrecognized package type indicates that the package type received is not currently defined at that application entity.

		An incorrect transaction portion indicates that an identifier in the transaction portion was unexpected (not what should have been received in comparison with the rest of the transaction portion and the transaction in progress).

		A badly structured transaction portion indicates that there is a problem with the encoding of the transaction portion. This could mean that the transaction portion is not of the correct length for the indicated identifiers, or that there are missing fields.

 

An unrecognized transaction ID occurs when a TCAP is received with a transaction ID that does not reflect a transaction currently in progress. The receiving application does not know to which transaction and operations to associate the message; therefore, it will abort the transaction and return the cause to the sender.

		The cause, permission to release problem, is not currently defined and is for further study. The last cause code, resource unavailable, is returned when a transaction is aborted because resources necessary to perform the operations specified (such as recordings or data-bases) are not available.

		User Abort Information Identifier 1 1 0 1 1 0 0 0

		The identifier indicates that the user abort information field is to follow. This identifier is coded as national, primitive. A user can initiate an Abort when an unexpected event occurs, such as when the caller hangs up before the transaction can be completed. The user in this message is not the calling or called party, but an application entity.

		User Abort Information Length

		The length does not include this and the identifier field-it includes only the user abort information field. The information field is a variable field.

		User Abort Information

		This variable field is used by TCAP to provide information regarding a user abort. The user abort indicates the reason that a user (application) aborted a transaction before it could be completed. The abort codes are not defined in ANSI or Bellcore, because these are implementation-specific codes defined by the various manufacturers.

		Component Sequence Identifier 1 1 1 0 1 0 0 0

		This field is used to notify the receiver that a sequence of components will follow this field. This identifier is coded as national, constructor. The component sequence identifier does not identify how many components are to follow, only that they will follow. This is really used as a header to the component portion, and all TCAP messages will contain this identifier.

		Component Sequence Length

		The length of the entire component portion is indicated in this field. The length does not include the length field itself or the identifier before it.

 

Dialog Portion

		The dialog portion is an optional part of TCAP. It contains information regarding security, encryption, and protocol version of data contained in the user part of TCAP. Following are the parameters of the dialog portion.

Dialog Portion	H	G	F	E	D	C	B	A
Dialog portion	1	1	1	1	1	0	0	1
Protocol version	1	1	0	1	1	0	1	0
Integer application context	1	1	0	1	1	0	1	1
Object identifier application context	1	1	0	1	1	1	0	0
User information	1	1	1	0	1	0	0	0
Integer security context	1	0	0	0	0	0	0	0
Object identifier security context	1	0	0	0	0	0	0	1
Confidentiality	1	0	1	0	0	0	1	0
Integer confidentiality algorithm	1	0	0	0	0	0	0	0
Object identifier confidentiality algorithm	1	0	0	0	1	0	0	1

		The dialog portion identifier indicates that a dialog portion is included in the TCAP message. This is an optional field, used when the user data contained in the TCAP message is secure data. Following the dialog portion identifier is the dialog portion length field. This provides the length (in octets) of the entire dialog portion of the TCAP message, not including this length field or the dialog portion identifier.

		The protocol version identifier indicates the protocol version follows. The protocol version length indicates the length of just the protocol version part of the dialog portion. The protocol version field indicates which version of the T1.114 protocol is being sent in the TCAP message. This allows nodes to determine which TCAP version of the T1.114 protocol is being sent in the TCAP message. This allows nodes to determine which TCAP version (for example, ANSI T1.114, 1997) is being used to encode the SS7 message.

		The application context identifier indicates that an application context name follows. This is used by the applications at the receiving nodes. It is accompanied by user data in the user information fields of the dialog portion. The identifier is followed by the application context length, which provides the length of the application context name only.

		The user information identifier indicates that user information is provided in the dialog portion. The user information length follows, indicating the length of the user information portion only, not counting the user information identifier or the length fields.

 

The security context identifier indicates that security information is contained in the dialog portion. It is followed by the security context length field. The security context provides information regarding the encryption of user information when encryption is used. This allows for secure transmission of user information when TCAP is being used to access databases which may have sensitive data.

		The last part of the dialog portion is the confidentiality fields. The confidentiality identifier indicates that a confidentiality algorithm follows, after the confidentiality length field.

		Component Portion

		The component portion contains one or more components and their associated parameters. These components are used to invoke operations and return results to the invoking application.

		A component may consist of the component itself, which indicates how the receiver will respond (if any response is necessary), the operation to be performed (optional), and any required parameters to be used when invoking the specified operation.

		Components will always have an identifier, length field, and contents, which specify what the component is asking of the receiver. Their values and descriptions are shown as follows.

Component Type Identifier	H	G	F	E	D	C	B	A
Invoke (last)	1	1	1	0	1	0	0	1
Return Result (last)	1	1	1	0	1	0	1	0
Return Error	1	1	1	0	1	0	1	1
Reject	1	1	1	0	1	1	0	0
Invoke (not last)	1	1	1	0	1	1	0	1
Return Result (not last)	1	1	1	0	1	1	1	0

		An Invoke (last) is used to invoke an operation at a remote application entity. For example, if a signaling point wanted to invoke some feature (operation) at another remote signaling point, a TCAP with an Invoke component would be sent to the remote signaling point, which would then act upon the Invoke request accordingly. The indication of ''last" means there are no more Invoke components for this transaction.

		The Invoke (not last) is the same as just described, with the exception of the "not last" indicator, which alerts the receiver that additional Invokes are to be sent in relation to this transaction.

		The Return Result (last) is used to return the results of an invoked operation. Not all operations require the Return Result to be sent. The indicator of "last" means there will be additional results sent in response to the specified Invoke and transaction. These are usually accompanied by a correlation ID, which is used to associate the Return Result with an earlier Invoke component.

		Return Error components are used to return an error code in the event of an operational error. An operational error is one which occurs at the application level, and does not necessarily indicate a protocol problem.

		The Reject component indicates a problem with protocol and means that the component was rejected because of an incorrect component portion in an earlier Invoke.

		Component Length

		The length field identifies how many octets are left in the component. This field and the identifier are not included in the length. There may be multiple components in one component portion; each component includes a component length field. This is not the length of the entire component portion (as seen in the transaction portion). This is only the length for this component (in which it is carried).

		Component ID Identifier 1 1 0 0 1 1 1 1

		This field indicates that a component has an invoke ID and, possibly, a correlation ID. As mentioned earlier, these IDs are of local significance only, and are sent so that Return Results can be correlated with an earlier Invoke request. The invoke ID is assigned by the originator of an Invoke, and requires that any Return Result will require a correlation ID. The correlation ID is the same ID as the invoke ID, and is returned within the Return Result so the originator of an Invoke can correlate returns with their respective Invokes.

		Component ID Length

		The length field indicates the total length of the component ID field only. The ID length may be zero (unidirectional only), four (invoke ID only), or eight octets in length (both invoke ID and correlation ID provided). A Return Result can have only a correlation ID; therefore, the length for a Return Result will always be four octets. The same is true for Return Error and Reject.

		As seen in the following table, only the Invoke can carry both an invoke ID and a correlation ID.

		Component IDs

		The component may have an invoke ID and a correlation ID, based on the following criteria. These IDs are used to associate multiple components with operations and transactions already in progress.

 

Component Type	Invoke ID	Correlation ID
Invoke	Optional	Yes
Return Result	No	Yes
Return Error	No	Yes
Reject	No	Yes

		Invoke ID

		The invoke ID is a one-octet identifier assigned to a component that is invoking an operation. This is an optional field, and is of local significance only.

		Correlation ID

		The correlation ID is used whenever a component is responding to another component. If responding to a component that contained an invoke ID, the correlation ID is mandatory. The correlation ID is a mirror image of an invoke ID, and is used as a reference for associated invoke IDs with previous invokes.

Operation Code Identifier	H	G	F	E	D	C	B	A
National TCAP	1	1	0	1	0	0	0	0
Private TCAP	1	1	0	1	0	0	0	1

		National TCAP operation codes are defined in both ANSI and Bellcore standards. These are TCAP messages which must be common in all systems interworking with Bell Operating Company (BOC) networks and other ANSI networks.

		Private TCAP operation codes are of significance only to private networks and are not compatible with any networks that interwork. Private networks cannot be connected to the Public Switched Telephone Network (PSTN) because the message types will conflict with national standards.

		Operation Code Length

		The length field identifies the length of the operation code field only and does not include itself or the identifier field. If the operation code is national TCAP, the length will be two octets. If the operation code is private TCAP, there is no limitation on the length.

		Operation Codes

		The operation codes are implementation specific, and are used by the application entities as instructions on how to carry out the component action. TCAP as a protocol does not interact with the operations; it only delivers them to the appropriate application process.

		Operation codes may vary from network to network, because they are very network dependent. This section identifies those operation codes used within the Bellcore networks as identified in the Bellcore publication, TR-NWT-000246, T1.114.5, Issue 2, Revision 3, December 1992. The EIA/TIA has also specified operation codes for usage in the cellular network. The operation codes used in cellular provide a means for mobile switching centers to pass information from one to another, as well as to invoke operations at remote MSCs.

		The operation code is a two-octet field divided into the operation family and the operation specifier. The operation family is a seven-bit field (bits A-G), and identifies the group or category related to this operation. Bit H indicates whether or not a response is expected.

		The second octet of the operation code consists of the operation specifier, which is used to identify the operation being requested. The specifier is the specific instruction being asked of the application.

Operation Families	G	F	E	D	C	B	A
Parameter	0	0	0	0	0	0	1
Charging	0	0	0	0	0	1	0
Provide Instructions	0	0	0	0	0	1	1
Connection Control	0	0	0	0	1	0	0
Caller Interaction	0	0	0	0	1	0	1
Send Notification	0	0	0	0	1	1	0
Network Management	0	0	0	0	1	1	1
Procedural	0	0	0	1	0	0	0
Operation Control	0	0	0	1	0	0	1
Report Event	0	0	0	1	0	1	0
Miscellaneous	1	1	1	1	1	1	0

		The operation family does not provide enough information for the application to process the operation. This only serves as a category for the operation code. As you will notice in the rest of this section, the operation codes themselves are not all unique codes. They each use an ascending order beginning with the binary value of 0000 0001. The operation family field then becomes the delimiter between the various operation codes.

Parameter	H	G	F	E	D	C	B	A
Provide value	0	0	0	0	0	0	0	1
Set value	0	0	0	0	0	0	1	0

		The parameter family provides instructions on how to use the parameters accompanying this parameter. There are two options: provide value and set value. The provide value indicator instructs the receiver to provide the requested value for the given parameter. The parameter portion of the TCAP message contains the actual parameter to which this operation refers.

		The option set value instructs the receiver to set the value for the given parameter. This is for further study and has not yet been implemented. One example of how this operation code may be used is in the case where a signaling point has control of a call, but does not have the necessary resources available to continue processing (such as recordings). A temporary handover procedure is invoked, and the provide value indicator shown here could be included in the parameters sent to the remote application to indicate the need for resources.

Charging	H	G	F	E	D	C	B	A
Bill call	0	0	0	0	0	0	0	1

		Presently, there is only one option for this operation code. The bill call option is used to notify the receiving application that a billing record is to be created for the calling party indicated in the parameters.

Provide Instructions	H	G	F	E	D	C	B	A
Start	0	0	0	0	0	0	0	1
Assist	0	0	0	0	0	0	1	0

		This operation code is used to request instructions during an assist procedure. The start option is for further study, while the assist option indicates that the assist procedure has been requested and the receiver of an assist is asking the sender for instructions.

Connection Control	H	G	F	E	D	C	B	A
Connect	0	0	0	0	0	0	0	1
Temporary connect	0	0	0	0	0	0	1	0
Disconnect	0	0	0	0	0	0	1	1
Forward disconnect	0	0	0	0	0	1	0	0

		The four codes used in this operation are grouped into associated pairs. The connect and disconnect are related, and will require further study. When a connect is issued, the disconnect is used to terminate the connection.

		The temporary connect is used when an error is encountered and a connection to another database for completion of processing is required. The temporary connect operation must also be accompanied by parameters providing the subsystem number of the database, the routing number of the exchange to which a connection is being requested, and a reference number for correlation of transactions between the database and the requesting exchange.

		When the temporary connect is received, the receiving entity knows that the forward disconnect will follow. The forward disconnect is used to terminate a temporary connection.

Caller Interaction	H	G	F	E	D	C	B	A
Play announcement	0	0	0	0	0	0	0	1
Play announcement and collect digits	0	0	0	0	0	0	1	0

Caller Interaction	H	G	F	E	D	C	B	A
Indicate information waiting	0	0	0	0	0	0	1	1
Indicate information provided	0	0	0	0	0	1	0	0

		The caller interaction family of operations allows announcements to be specified and provides a mechanism for application processes to communicate with one another regarding the state of expected information. The first two options, play announcement and play announcement and collect digits, are identical, with the exception of the latter, which waits and collects dialed digits from the user. The dialed digits can then be routed to a voice response unit for processing.

		The indicators for information waiting allow one application process to inform another application process that there is information waiting and, when the information has been transferred, that the information has been provided.

Send Notification	H	G	F	E	D	C	B	A
When party free	0	0	0	0	0	0	0	1

		The operation in this operation family is used for certain CLASS features such as automatic callback, where a caller reaches a busy signal and requests notification from the network when the party becomes available. When the called party becomes available by placing the receiver back on-hook, the remote exchange is notified via TCAP that the called party is available. ISUP call setup is then used to set the call up as if it were a normal call.

Network Management	H	G	F	E	D	C	B	A
Automatic code gap	0	0	0	0	0	0	0	1

		The automatic code gap is used by network management to temporarily inhibit specified codes for the specified time. Additional parameters indicate the time the codes are to be inhibited and the duration between operations.

Procedural	H	G	F	E	D	C	B	A
Temporary handover	0	0	0	0	0	0	0	1
Report assist termination	0	0	0	0	0	0	1	0
Security	0	0	0	0	0	0	1	1

		This operation family is used to control procedural operations. The temporary handover operation indicates that a temporary handover is presently in progress. When the temporary handover procedure has been completed, the receiver of this message will then release all resources dedicated to this operation.

		The report assist termination is used to end an assist procedure.

 

Operation Control	H	G	F	E	D	C	B	A
Cancel	0	0	0	0	0	0	0	1

		The cancel operation is used with the send notification operation to cancel a when party free operation. This is presently the only operation that can be canceled. The service key parameter accompanies this operation and provides the called party number.

Report Event	H	G	F	E	D	C	B	A
Voice message available	0	0	0	0	0	0	0	1
Voice message retrieved	0	0	0	0	0	0	1	0

		This operation family is used with the Voice Message Storage Retrieval (VMSR) systems. When a subscriber uses such a service, and the VMSR system is located at another exchange (other than the subscriber's), the voice message available option is used to alert the subscriber's exchange of a message. The calling number of the party that left the message can be included, as well as the time the message was left. A Return Result is sent when the operation has been successful.

		The voice message retrieved operation is used to remove the message available indicator from a subscriber's VMSR. Both the subscriber's number and the identification of the VMSR system used by the subscriber are provided with this operation code.

Miscellaneous	H	G	F	E	D	C	B	A
Queue call	0	0	0	0	0	0	0	1
Dequeue call	0	0	0	0	0	0	1	0

		Error Codes

		These error codes are used to indicate the reason for an unsuccessful completion of an operation. The error code is sent in a Return Error component to the originator of the operation request. The error codes are coded as either national or private. The error codes identified as follows are national error codes as defined in Bellcore publication TR-NWT-000246, Issue 2, Revision 2, December 1992.

Error Code	H	G	F	E	D	C	B	A
Unexpected component sequence	0	0	0	0	0	0	0	1
Unexpected data value	0	0	0	0	0	0	1	0
Unavailable resource	0	0	0	0	0	0	1	1
Missing customer record	0	0	0	0	0	1	0	0
Spare	0	0	0	0	0	1	0	1
Data unavailable	0	0	0	0	0	1	1	0
Task refused	0	0	0	0	0	1	1	1
Queue full	0	0	0	0	1	0	0	0

Error Code	H	G	F	E	D	C	B	A
No queue	0	0	0	0	1	0	0	1
Timer expired	0	0	0	0	1	0	1	0
Data already exists	0	0	0	0	1	0	1	1
Unauthorized request	0	0	0	0	1	1	0	0
Not queued	0	0	0	0	1	1	0	1
Unassigned DN	0	0	0	0	1	1	1	0
Spare	0	0	0	0	1	1	1	1
Notification unavailable to destination DN	0	0	0	1	0	0	0	0
VMSR system ID did not match user profile	0	0	0	1	0	0	0	1

		An unexpected component sequence indicates that one or more components were received which did not match what should have been received (was expected), considering the previous components received from the same originator. Likewise, an unexpected data value indicates that data received within a component was not what should have been sent, considering the type of component.

		When resources required to carry out an Invoke are not available, the receiving application will return an error of unavailable resources. The originator must then determine if it will petition another application at another signaling point, or possibly even within the same signaling point. Resources include things like recordings and databases.

		When accessing a database to add information to a customer database or when retrieving information from a customer record, the identity of the called party will be used to identify the record. If the record does not exist, an error of missing customer record will be sent to the originating application. Customer records are used to determine the billing options for a call as well as the type of features a subscriber can use.

		With certain CLASS features, the customer record will also provide specific instructions on how to handle specific services on a per-call basis.

		Data unavailable could indicate that the database containing requested information is not available. This could be the case if there was a failure within the subsystem or if the application process failed and was unable to reach the database.

		Task refused is returned when the application entity has been requested to perform some sort of task, but the entity chosen cannot perform the task. No reason is given, only the Reject.

		With custom calling features and CLASS, certain features require a queue to temporarily store numbers. For example, automatic callback and automatic recall require the last dialed number or the last number that called to be stored in a queue until the feature is invoked. The feature (application entity) then accesses this

queue to complete the processing of the feature. There are three states associated with these queues: queue full, no queue, and not queued. Not queued is used when a number is to be removed from a called party queue.

		When a parameter is sent with data that has already been received, the reject cause will be data already exists. Only a parameter change operation can change data that has already been received. Several reject causes are related to directory numbers (DNs). These reject causes are sent for a variety of reasons, but are usually related to the lack of resources or unauthorized to access services and/or databases being requested.

		A VMSR system is now being offered in many areas. This allows voice-mail equipment to be installed at the central office, rather than the subscriber purchasing a voice-mail system. The subscriber must purchase the service, and the service must be an entry in the customer record before access is allowed. If access is attempted and the directory number is not a subscriber to the VMSR system, a reject cause of VMSR system identification did not match user profile is sent.

		Parameters

		Parameters are associated with individual components and are the last items in the component portion of the TCAP message. There are three elements in any parameter: the parameter identifier, length, and contents.

		The parameter identifier is used to identify the individual parameters, and consists of a one-octet field. All parameter identifiers are listed in the following table. The length field indicates the length of the contents field, which is a variable field. The contents can be one-octet specifiers or implementation-dependent codes.

		The following parameters are found in the Bellcore publication, TR-NWT-000246, Issue 2, Revision 2, December 1992.

Parameter Name	H	G	F	E	D	C	B	A
Timestamp	0	0	0	1	0	1	1	1
ACG indicators	1	0	0	0	0	0	0	1
Standard announcement	1	0	0	0	0	0	1	0
Customized announcement	1	0	0	0	0	0	1	1
Digits	1	0	0	0	0	1	0	0
Standard user error code	1	0	0	0	0	1	0	1
Problem data	1	0	0	0	0	1	1	0
SCCP calling party address	1	0	0	0	0	1	1	1

Parameter Name	H	G	F	E	D	C	B	A
Transaction ID	1	0	0	0	1	0	0	0
Package type	1	0	0	0	1	0	0	1
Service key	1	0	1	0	1	0	1	0
Busy/idle status	1	0	0	0	1	0	1	1
Call forwarding status	1	0	0	0	1	1	0	0
Originating restrictions	1	0	0	0	1	1	0	1
Terminating restrictions	1	0	0	0	1	1	1	0
DN to line service type mapping	1	0	0	0	1	1	1	1
Duration	1	0	0	1	0	0	0	0
Returned data	1	0	1	1	0	0	0	1
Bearer capability requested	1	0	0	1	0	0	1	0
Bearer capability supported	1	0	0	1	0	0	1	1
Reference ID	1	0	0	1	0	1	0	0
Business group	1	0	0	1	0	1	0	1
Signaling network identifier	1	0	1	1	0	1	1	0
Generic name	1	0	0	1	0	1	1	1
Message waiting indicator type	1	0	0	1	1	0	0	0
Look ahead for busy	1	0	0	1	1	0	0	1
Circuit identification code	1	0	0	1	1	0	1	0
Precedence identifier	1	0	0	1	1	0	1	1
Call reference identifier	1	0	0	1	1	1	0	0

		Parameter Values

		Following are all the parameters just listed and the values of their contents. Parameters complement the components already described and their operation codes. Operation codes may choose any number of the following parameters as a set. These are all national parameters as described, and are defined in the Bellcore publication TR-NWT-000246, Issue 2, Revision 2, December 1992.

Timestamp	H	G	F	E	D	C	B	A
Octets 1 2	Year in binary (e.g., 93)
Octets 3 4	Month in binary (e.g., 07)
Octets 5 6	Day in binary (e.g., 28)
Octets 7 8	Hour in binary (e.g., 17)
Octets 9 10	Minutes in binary (e.g., 30)
Octet 11	+ or (ahead or behind GMT)
Octets 12 13	Hours (see above description)
Octets 14 15	Minutes (see above description)

		The timestamp provides the time and date an event occurred. Both local time and the difference between local time and Greenwich Mean Time (GMT) are provided. The first hour and minutes are those of local time and the second hour and minutes fields reflect the difference between local time and GMT. For example, if the local time is 1730, and the local time is in Atlanta (which is five hours behind Greenwich time), the second hour and minutes field would reflect a difference of 20500.

Automatic Code Gap	H	G	F	E	D	C	B	A
Control Cause Indication
Vacant code	0	0	0	0	0	0	0	1
Out-of-band	0	0	0	0	0	0	1	0
Database overload	0	0	0	0	0	0	1	1
Destination mass calling	0	0	0	0	0	1	0	0
Operation Support System (OSS) initiated	0	0	0	0	0	1	0	1

		The Automatic Code Gap (ACG) is a network management function that allows the network to throttle traffic for a specified period of time. ACG can be initiated manually or automatically. The preceding codes indicate the cause for invoking ACG.

		Vacant code indicates that calls are being received for an unassigned code. Out-of-band is related to calls for a band that a subscriber does not subscribe to. Database overload indicates a database that is overloaded, while destination mass calling indicates that an excessive number of calls are being received for a destination.

		When the ACG is initiated manually, it is initiated by an Operations Support System (OSS). When this is the case, the cause code will indicate that the OSS initiated the ACG.

Duration (in seconds)	H	G	F	E	D	C	B	A
Not used	0	0	0	0	0	0	0	0
1	0	0	0	0	0	0	0	1
2	0	0	0	0	0	0	1	0
4	0	0	0	0	0	0	1	1
8	0	0	0	0	0	1	0	0
16	0	0	0	0	0	1	0	1
32	0	0	0	0	0	1	1	0
64	0	0	0	0	0	1	1	1
128	0	0	0	0	1	0	0	0
256	0	0	0	0	1	0	0	1
512	0	0	0	0	1	0	1	0
1024	0	0	0	0	1	0	1	1
2048	0	0	0	0	1	1	0	0

		One-octet field indicating the time duration in seconds that an ACG should be applied.

 

Gap (in seconds)	H	G	F	E	D	C	B	A
Remove gap control	0	0	0	0	0	0	0	0
0.00	0	0	0	0	0	0	0	1
0.10	0	0	0	0	0	0	1	0
0.25	0	0	0	0	0	0	1	1
0.50	0	0	0	0	0	1	0	0
1.00	0	0	0	0	0	1	0	1
2.00	0	0	0	0	0	1	1	0
5.00	0	0	0	0	1	0	0	0
15.00	0	0	0	0	1	0	0	1
30.00	0	0	0	0	1	0	1	0
60.00	0	0	0	0	1	0	1	1
120.00	0	0	0	0	1	1	0	0
300.00	0	0	0	0	1	1	0	1
600.00	0	0	0	0	1	1	1	0
Stop all calls	0	0	0	0	1	1	1	1

		One-octet field indicates the interval between applications of the ACG control. Time is measured in seconds.

Standard Announcement	H	G	F	E	D	C	B	A
Not used	0	0	0	0	0	0	0	0
Out-of-band	0	0	0	0	0	0	0	1
Vacant code	0	0	0	0	0	0	1	0
Disconnected number	0	0	0	0	0	0	1	1
Reorder (120 pulses per minute) tone	0	0	0	0	0	1	0	0
Busy (60 pulses per minute)	0	0	0	0	0	1	0	1
No circuit available	0	0	0	0	0	1	1	0
Reorder recording	0	0	0	0	0	1	1	1
Audible ringing	0	0	0	0	1	0	0	0

		When an announcement is to be applied to a particular call, either a standard announcement or a customized announcement may get requested. The standard announcements for a Bellcore network are depicted in the preceding table.

		Customized Announcement

		These are implementation dependent and allow networks to address their own network-specific announcements. The parameter consists of two elements: the announcement set and the individual announcement. Length is variable.

		Customized announcements are unique within the network in which they reside. Independent companies and private networks may implement their own announcement for usage within their own networks. Both standard and customized announcements can be used within the same network. These two conventions allow either one to be requested for a specific call.

Digits	H	G	F	E	D	C	B	A
	Type of digits
	Nature of number
	Number plan & Encoding
	Number of digits
	Digits
Type of digits
Not used	0	0	0	0	0	0	0	0
Called party number	0	0	0	0	0	0	0	1
Calling party number	0	0	0	0	0	0	1	0
Caller interaction	0	0	0	0	0	0	1	1
Routing number	0	0	0	0	0	1	0	0
Billing number	0	0	0	0	0	1	0	1
Destination number	0	0	0	0	0	1	1	0
Local Access and Transport Area (LATA)	0	0	0	0	0	1	1	1
Carrier	0	0	0	0	1	0	0	0
Last calling party	0	0	0	0	1	0	1	0
Calling directory number	0	0	0	0	1	0	1	1
VMSR identified	0	0	0	0	1	1	0	0
Original called number	0	0	0	0	1	1	0	1
Redirecting number	0	0	0	0	1	1	1	0
Connected number	0	0	0	0	1	1	1	1

		When digits are being received in TCAP for invoking features, the type of digits (source) and the coding of the digits (BCD) must be specified so that the receiving entity knows how to decode the digits. The preceding types indicate the source type of the digits and allow the receiver to determine how to handle the received digits.

		In some cases (CLASS features, that is), the subscriber may be requested to dial digits. When this is the case, the digits type is caller interaction. An example of this would be when a caller inputs a calling card number when requested by an announcement.

		Dialed numbers can also be used for network routing (routing number) or billing information (billing number). When information is being requested regarding a particular line, the destination number may be provided as a reference to the subscriber who owns that line.

		Digits can also specify the Local Access Transport Area (LATA) a particular caller is calling from, to be used in routing and accessing line information. All carriers are numbered as well. When callers wish to dial their long distance carrier's operator direct, they dial a 10xxx number, the last three digits being the carrier number. These

digits can be carried through TCAP, as well, to access a billing record and record usage of a carrier or when a customer line record is accessed to specify the long distance carrier for that subscriber.

		Last calling party digits identify the last directory number to dial a certain number. This is used with CLASS features such as automatic callback to identify the directory number of the last party to call a number. Last party called identifies the last party that was called (directory number).

		A Voice Mail Send / Receive (VMSR) is also identified by digits, and is referred to in messages accessing and/or invoking a VMSR system for a call.

		Redirecting number identifies the number of the party who last invoked a forwarding to a specific number. For example, with follow-me forwarding, a number can be reforwarded from any phone whenever needed. The redirecting number indicates the last directory number to forward the specified number.

Nature of number

H

G

F

E

D

C

B

A

National

0

International

1

No presentation restriction

0

Presentation restriction

1

		Encoding

		H

		G

		F

		E

		D

		C

		B

		A

Not used

0

0

0

0

Binary Coded Decimal (BCD)

0

0

0

1

IA5

0

0

1

0

		Numbering plan

		H

		G

		F

		E

		D

		C

		B

		A

Unknown or not applicable

0

0

0

0

ISDN numbering

0

0

0

1

Telephony numbering

0

0

1

0

Data numbering

0

0

1

1

Telex numbering

0

1

0

0

Maritime mobile numbering

0

1

0

1

Land mobile numbering

0

1

1

0

Private numbering plan

0

1

1

1

		Number of digits

		H

		G

		F

		E

		D

		C

		B

		A

For BCD encoding:

2nd digit

1st digit

nth digit

(n 1)th digit

		Digits are coded as follows:

Digit 0 or filler

0

0

0

0

Digit 1

0

0

0

1

Digit 2

0

0

1

0

Digit 3

0

0

1

1

Digits are coded as follows:
Digit 4	0	1	0	0
Digit 5	0	1	0	1
Digit 6	0	1	1	0
Digit 7	0	1	1	1
Digit 8	1	0	0	0
Digit 9	1	0	0	1
Spare	1	0	1	0
Code 11	1	0	1	1
Code 12	1	1	0	0
*	1	1	0	1
#	1	1	1	0
ST	1	1	1	1

		All of the preceding identify the type of digits as well as the digits themselves. These are used when presenting digits into the TCAP message so the receiver can understand the origin of the digits and know how they are to be decoded. Digits appear in a variety of TCAP transactions, and are being used more and more as Advanced Intelligent Network (AIN) features begin working their way into the network.

Standard User Error Code	H	G	F	E	D	C	B	A
Not used	0	0	0	0	0	0	0	0
Caller abandon	0	0	0	0	0	0	0	1
Improper caller response	0	0	0	0	0	0	1	0

		User error codes define the reason for a user-induced failure. When a transaction is interrupted and aborted because of subscriber actions, these cause codes are used to describe the reason. Presently, only two causes are defined.

		Caller abandon indicates that a subscriber (calling party) hung up before the transaction could be completed. The transaction could have been a calling card call to another number, which involves TCAP to access the calling card database for verification and billing. If any type of call forwarding or access to a voice-mail system (VMSR) is used, TCAP is required for completing the informational transactions.

		Improper caller response indicates that the caller was queried to enter digits and did not enter the correct digits, or entered in the wrong number of digits. A good example of this would be entering in a calling card number when prompted. Another example is with VMSR systems where a caller may be prompted by an announcement to enter in a callback number, but enters in an incorrect number of digits.

 

Problem Data

		The problem data cites the specific reason for the error. This field is implementation dependent and coded as contextual, primitive. The format is the same as for other parameters: a one-octet parameter identifier, the length of the parameter contents, and the parameter contents (variable-length field).

		This is provided in the protocol as an optional source of information when a problem occurs. Systems can elect to send additional information and codes regarding a specific set of problems encountered.

		SCCP Calling Party Address

		This is the address field used by the receiver of a handover procedure to determine the calling party address. The address structure is the same as discussed in Chapter 7. The address can consist of global title digits, a point code, or a subsystem number. This information is part of the temporary handover parameter.

		Transaction ID

		This is the same format used in the transaction portion. The difference is that this is used during the temporary handover procedure by the receiver of a temporary handover message. This information is part of the temporary handover parameter.

		Package Type

		The package type is used here to notify the receiver of the temporary handover parameter what package type to respond with. The package type indicated here will be used to return some sort of response to the calling party address (if included in the transaction).

		Service Key

		The service key is used to specify which parameters should be used to access a record. This is used in database queries, which are used to access customer database records and service records. The service key is coded as contextual, constructor.

Busy/Idle Status	H	G	F	E	D	C	B	A
Not used	0	0	0	0	0	0	0	0
Busy	0	0	0	0	0	0	0	1
Idle	0	0	0	0	0	0	1	0

		Busy and idle statuses are used to provide information regarding the status of a subscriber line when particular CLASS features and custom calling features are deployed.

Call Forwarding Status

H

G

F

E

D

C

B

A

Call Forwarding Variable

		Service not supported

0

0

Call Forwarding Status

H

G

F

E

D

C

B

A

		Active

0

1

		Not active

1

0

		Spare

1

1

		Call Forwarding on Busy

		H

		G

		F

		E

		D

		C

		B

		A

		Service not supported

0

0

		Active

0

1

		Not active

1

0

		Spare

1

1

		Call Forwarding Don't Answer

		H

		G

		F

		E

		D

		C

		B

		A

		Service not supported

0

0

		Active

0

1

		Not active

1

0

		Spare

1

1

		Selective Forwarding

		H

		G

		F

		E

		D

		C

		B

		A

		Service not supported

0

0

		Active

0

1

		Not active

1

0

		Spare

1

1

		These call forwarding parameters present the status of a line using call forwarding features. These are used when custom calling or CLASS is being offered in a calling area. Call forwarding variable is used to forward a call immediately, before ringing the called party.

		Call forwarding on busy will forward a call only if the called party is off-hook. Call forwarding don't answer forwards a call when the called party does not answer within the predetermined number of rings (defined by the subscriber). Selective forwarding allows only select calls to be forwarded, based upon criteria defined by the user (such as calling party number).

Originating Restrictions	H	G	F	E	D	C	B	A
Denied origination	0	0	0	0	0	0	0	0
Fully restricted origination	0	0	0	0	0	0	0	1
Semirestricted origination	0	0	0	0	0	0	1	0
Unrestricted origination	0	0	0	0	0	0	1	1

		Restrictions are assigned to business groups (such as Centrex service) to define the type of outside calling a station is permitted to make. Denied origination indicates that calls are not allowed to be originated from the specified line. Business groups are used to define Centrex lines and other similar services.

		Fully restricted origination allows a line to originate calls to lines within the business group, but not to the attendant (local business group operator, usually at the reception desk of a business) and not to lines outside of the business group.

 

Semirestricted origination allows a line to call outside the business group, but not by direct dial. The line can be forwarded, conferenced, or transferred via an attendant but cannot direct dial an outside line.

		Unrestricted origination allows a line to call any number within the business group or outside the business group. This allows full unrestricted access to any outside line.

Terminating Restrictions	H	G	F	E	D	C	B	A
Denied termination	0	0	0	0	0	0	0	0
Fully restricted termination	0	0	0	0	0	0	0	1
Semirestricted termination	0	0	0	0	0	0	1	0
Unrestricted termination	0	0	0	0	0	0	1	1
Call rejection applies	0	0	0	0	0	1	0	0

		Terminating restrictions are like the originating restrictions, but apply only to incoming calls. Denied termination prevents any calls from being terminated to the line. The line may be allowed to dial within the group, or may even be allowed to dial outside the group (depending on the originating restriction applied).

		Fully restricted termination prevents all calls from outside the business group being terminated to this line. Calls cannot be transferred from any other line or the attendant or forwarded.

		Semirestricted lines are allowed to receive calls from within the business group. Outside calls must be transferred or forwarded to the line. Lines outside the business group cannot direct dial this line.

		Unrestricted termination allows full access to the line from within the business group and outside the business group. Call rejection allows a line to request rejection of an incoming call. This is communicated using electronic Centrex phones with displays. The display shows the calling party number (ANI), allowing the called party to determine whether to accept the call or reject the call.

Directory Number to Line Service Type Mapping

		Match Status

H

G

F

E

D

C

B

A

		Spare

0

0

		No match

0

1

		Match

1

0

		Spare

1

1

		Line Service Type

		H

		G

		F

		E

		D

		C

		B

		A

		Individual

0

0

0

0

0

0

		Coin

0

0

0

0

0

1

		Multiline hunt

0

0

0

0

1

0

		PBX

0

0

0

0

1

1

		Choke

0

0

0

1

0

0

Line Service Type

H

G

F

E

D

C

B

A

		Series completion

0

0

0

1

0

1

		Unassigned DN

0

0

0

1

1

0

		Multiparty

0

0

0

1

1

1

		Nonspecific

0

0

1

0

0

0

		Temporarily out of service

0

0

1

0

0

1

		This identifies the type of line service for a given subscriber line. This information must be retrieved from a database line record for a given subscriber line. Numbers which are not in service or have been disconnected are also indicated with these codes.

Duration	H G F E	D C B A
	Hours	Hours
	Minutes	Minutes
	Seconds	Seconds

		Duration is used for features such as automatic callback, where the called party must be monitored until it is free. The duration parameter allows a duration to be set for monitoring the called party. After the duration period, if the called party is still busy, the feature is restarted for another duration.

		Bearer Capability Requested

		This information is related to the type of bearer capability a subscriber is allowed. The information is stored in the line information database, and retrieved via TCAP when queried by an end office.

Octet 1

		Extension indicator

H

G

F

E

D

C

B

A

		Octet extended to next octet

1

		Octet not extended to next octet

0

		Coding standard

		H

		G

		F

		E

		D

		C

		B

		A

		ITU-TS standardized

0

0

		Reserved for other international standards

0

1

		National standard

1

0

		Reserved

1

1

		Information transfer capability

		H

		G

		F

		E

		D

		C

		B

		A

		Speech

0

0

0

0

0

		Unrestricted digital information

0

1

0

0

0

		Restricted digital information

0

1

0

0

1

		3.1-kHz audio

1

0

0

0

0

		7-kHz audio

1

1

0

0

1

		15-kHz audio

1

0

0

1

0

		Video

1

1

0

0

0

Octet 2

		Extension indicator

		H

		G

		F

		E

		D

		C

		B

		A

		Octet extended to next octet

1

		Octet not extended to next octet

0

		Transfer mode

		H

		G

		F

		E

		D

		C

		B

		A

		Circuit mode

0

0

		Packet mode

1

0

		Information transfer rate

		H

		G

		F

		E

		D

		C

		B

		A

		Channel size

0

0

0

0

0

		64 kbps

1

0

0

0

0

		384 kbps

1

0

0

1

1

		1536 kbps

1

0

1

0

1

		1920 kbps

1

0

1

1

1

		The information transfer rate can be used to indicate the transfer rate in both directions, through the use of octet 2b. When octet 2b is not included, the bidirectional transfer rate is symmetrical with the rate indicated in octet 2. When octet 2b is included, then the transfer rate in the direction origination to destination is that of the rate indicated in octet 2b. This allows for setting different transfer rates in each direction or the same transfer rate in both directions.

Octet 2a

		Extension indicator

		H

		G

		F

		E

		D

		C

		B

		A

		Octet extended to next octet

1

		Octet not extended to next octet

0

		Structure

		H

		G

		F

		E

		D

		C

		B

		A

		Default (see note for default values)

0

0

0

		8-kHz integrity

0

0

1

		Service data unit integrity

1

0

0

		Unstructured

1

1

1

		Note: The default values assigned (if field = 000, or octet 2a is omitted) are as follows:

Transfer mode	Transfer capability	Structure
Circuit	Speech	8-kHz integrity
Circuit	Unrestricted digital	8-kHz integrity
Circuit	Restricted digital	8-kHz integrity
Circuit	Audio	8-kHz integrity
Circuit	Video	8-kHz integrity
Packet	Unrestricted digital	Service data unit integrity

Configuration

H

G

F

E

D

C

B

A

Point-to-point

0

0

Multipoint

1

0

		Establishment

		H

		G

		F

		E

		D

		C

		B

		A

Demand

0

0

Octet 2b

This octet can be omitted, unless it is desirable to indicate a different transfer rate in one direction other than what is specified in octet 2. When this octet is used, the transfer rate indicated is applicable to the direction origination to destination.

		Extension indicator

		H

		G

		F

		E

		D

		C

		B

		A

Octet extended to next octet

1

Octet not extended to next octet

0

Symmetry

H

G

F

E

D

C

B

A

Bidirectional symmetric

0

0

Bidirectional asymmetric

0

1

Unidirectional (origination to destination)

1

0

Unidirectional (destination to origination)

1

1

		Information transfer rate

		H

		G

		F

		E

		D

		C

		B

		A

Channel size

0

0

0

0

0

64 kbps

1

0

0

0

0

384 kbps

1

0

0

1

1

1536 kbps

1

0

1

0

1

1920 kbps

1

0

1

1

1

Octet 3

This is an optional octet which can be omitted or repeated. When there is a need to identify more than one protocol at higher layers, this field can be repeated to reflect each of the other protocols.

		Extension indicator

		H

		G

		F

		E

		D

		C

		B

		A

Octet extended to next octet

1

Octet not extended to next octet

0

		Multiplier or layer identification

		H

		G

		F

		E

		D

		C

		B

		A

Bearer capability multiplier

0

0

User information layer 1 protocol

0

1

User information layer 2 protocol

1

0

User information layer 3 protocol

1

1

		User information layer 1 protocol identification

		H

		G

		F

		E

		D

		C

		B

		A

ITU-TS (CCITT) Rec. I.412

0

0

0

0

0

Rate Adaptation (see note)

0

0

0

0

1

ITU-TS (CCITT) Rec. G.711 u-law

0

0

0

1

0

ITU-TS (CCITT) Rec. G.711 A-law

0

0

0

1

1

ITU-TS (CCITT) Rec. G.721 32 kbps ADPCM

0

0

1

0

0

User information layer 1 protocol identification

H

G

F

E

D

C

B

A

ITU-TS (CCITT) Rec. G.722, G.725, 7-kHz audio

0

0

1

0

1

		User information layer 2 protocol identification

		H

		G

		F

		E

		D

		C

		B

		A

Undefined

0

0

0

0

0

0

ITU-TS (CCITT) Rec. Q.921 (I.441)

0

0

0

1

0

ITU-TS (CCITT) Rec. Q.710

0

0

0

1

1

ITU-TS (CCITT) Rec. X.25 link level

0

0

1

1

0

		User information layer 3 protocol identification

		H

		G

		F

		E

		D

		C

		B

		A

Undefined

0

0

0

0

0

ITU-TS (CCITT) Rec. Q.931 (I.451)

0

0

0

1

0

ITU-TS (CCITT) Rec. X.25 packet level

0

0

1

1

0

		Note: When the multiplier or layer identification field indicates the user information layer 1-3, the user information protocol identification fields are indicated in the same octet. Each of these protocol identifiers is directly related to the layer specification in bits GF. For example, if bits GF indicate layer-1 protocol, then the bits EDCBA equal that of the appropriate layer-1 protocol as shown in the preceding table under User information layer 1 protocol identification.

Bearer Capability Supported	H	G	F	E	D	C	B	A
Not used	0	0	0	0	0	0	0	0
Bearer capability is supported	0	0	0	0	0	0	0	1
Bearer capability is not supported	0	0	0	0	0	0	1	0
Bearer capability not authorized	0	0	0	0	0	0	1	1
Bearer capability not presently available	0	0	0	0	0	1	0	0
Bearer capability not implemented	0	0	0	0	0	1	0	1

		Reference ID

		This field is used to identify the transaction between the database and the exchange during the assist service. The format consists of an identifier, a length indicator, and the variable contents field. The contents field carriers the identification number (four octets) used by this service to correlate the transaction with the database access. The identification number is assigned by the database.

		Business Group Identifier

Octet 2

		Length of parameter

		The length indicates the entire length of the parameter, not counting this field.

		Octet 3

		Attendant status

		H

		G

		F

		E

		D

		C

		B

		A

		No indication

0

		Attendant line

1

Business group identifier

H

G

F

E

D

C

B

A

		Multilocation business group

0

		Interworking private number

1

		Line privileges information indicator

		H

		G

		F

		E

		D

		C

		B

		A

		Fixed line privileges

0

		Customer-defined line privileges

1

		Party selection

		H

		G

		F

		E

		D

		C

		B

		A

		No indication

0

0

0

0

		Calling party number

0

0

0

1

		Called party number

0

0

1

0

		Connected party number

0

0

1

1

		Redirecting number

0

1

0

0

		Original called number

0

1

0

1

		Octet 4 and 5

		Subgroup ID

		H

		G

		F

		E

		D

		C

		B

		A

		No indication

0

0

0

0

0

0

0

0

		Customer assigned subgroup codes

0

0

0

0

0

0

0

1

to

1

1

1

1

1

1

1

1

Octet 6

This field is associated with the line privileges field in the preceding table. If the line privileges field indicates customer-defined line privileges, then this one-octet field is used to indicate those customer-defined line privilege codes. If the line privileges field indicates fixed line privileges, this field is divided into two subfields. The bits HGFE indicate the terminating restrictions, while the bits DCBA indicate the originating restrictions.

		Line privileges

		H/D

		G/C

		F/B

		E/A

Unrestricted

0

		0

		0

0

Semirestricted

0

		0

		0

1

Fully restricted

0

		0

		1

0

Fully restricted intraswitch

0

		0

		1

1

Denied

0

		1

		0

0

		Business groups are used to offer PBX-type services to business customers who do not wish to purchase a PBX. Probably the most common type of service offered under this category is Centrex. These parameters are used to identify what class of Centrex is being used with the specified line.

		In addition to defining the business group, these parameters also allow the definition of the various members within a business group, and allow lines to be placed into subgroups. Subgroups may be located within the same area or may be in another calling area. When this is the case, this information must be shared with the remote offices.

 

Signaling Networks Identifier

		The signaling network identifier is used to indicate to the receiver which networks the sender anticipates going through to reach the destination. Each network ID requires two octets. The signaling networks identifier is a variable parameter.

Generic Name

		Type of Name

		H

		G

		F

		E

		D

		C

		B

		A

		Spare

0

0

0

		Calling name

0

0

1

		Original called name

0

1

0

		Redirecting name

0

1

1

		Connected name

1

0

0

		Spare

1

0

1

to

1

1

1

		Availability

		H

		G

		F

		E

		D

		C

		B

		A

		Name available/unknown

0

		Name not available

1

		Presentation

		H

		G

		F

		E

		D

		C

		B

		A

		Presentation allowed

0

0

		Presentation restricted

0

1

		Blocking toggle

1

0

		No indication

1

1

		Message Waiting Indicator Type

		H

		G

		F

		E

		D

		C

		B

		A

		2nd digit

		1st digit

		The message waiting indicator is a two-octet parameter predefined by the customer. This parameter and its contents notify the customer about the type of message waiting in a telephone-company-provided voice-mail system. The message waiting type must be defined at service deployment.

Look Ahead For Busy Response

		Acknowledgment type

		H

		G

		F

		E

		D

		C

		B

		A

		Path reservation denied

0

0

		Negative acknowledgment

0

1

		Positive acknowledgment

1

0

		Spare

1

1

		Location

		H

		G

		F

		E

		D

		C

		B

		A

		User

0

0

0

0

		Private network serving the local user

0

0

0

1

		Public network serving the local user

0

0

1

0

Location

H

G

F

E

D

C

B

A

		Transit network

0

0

1

1

		Public network serving the remote user

0

1

0

0

		Private network serving the remote user

0

1

0

1

		Local interface controlled by this signaling link

0

1

1

0

		International network

0

1

1

1

		Network beyond interworking point

1

0

0

0

		Acknowledgment type

		H

		G

		F

		E

		D

		C

		B

		A

		Path reservation denied

0

0

		Negative acknowledgment

0

1

		Positive acknowledgment

1

0

		Spare

1

1

		Circuit Identification Code

		The circuit identification code (CIC) identifies the trunk circuit used to send the voice or data to the called party. The CIC is also indicated in any ISUP messages, which are used to set up the connection between end offices. The CIC is a two-octet field.

		Precedence

		Used in military systems to determine the type of call precedence used. Call precedence allows calls in progress to be terminated and the trunk to be released so that those of a higher military rank may use the trunk for an outgoing call. This feature allows the military to maintain a low number of trunks at all military installations, while still allowing high-ranking officials access to lines when they need them. All lines within the military installation are coded, and all users are prompted to input an identification number, which identifies their rank and precedence level.

Octet 1

		Precedence level

		H

		G

		F

		E

		D

		C

		B

		A

		Flash override

0

0

0

0

		Flash

0

0

0

1

		Immediate

0

0

1

0

		Priority

0

0

1

1

		Routine

0

1

0

0

		Service

		These fields are used to indicate the service code as assigned by the code administrator that applies to this call. The service codes are used to identify the type of service subscribed to in this particular network.

		Call Reference

		Call references are only used with military installation calls. These codes allow tracking of calls independent of the circuit number. The call reference pertains to the identification input when callers dial their IDs and telephone numbers (called party). This allows tracking of both the line number and the individual code used to place the call.

		This is a six-octet field, divided into three-octet sections. The first three octets identify the identification number assigned to this call. This identification number is used to identify a particular call, and is separate from the circuit identification code.

		The next three octets are used to indicate the point code in which the identification code has been assigned. The identification code is only significant to the signaling point indicated in the last three octets.

		Summary

		As new services are defined, these parameters and operation codes will grow. The TCAP protocol itself is becoming an important aspect of the SS7 network and will become more important as the Intelligent Network (IN) grows.

		New switches become more and more sophisticated, and offer new and improved services and features. These features will require the support of TCAP for remote activation. There is no doubt that TCAP will be an important part of the communications network well into the next decade.

		The current traffic mix in SS7 networks today tends to be primarily ISUP messages with some TCAP traffic. This is quickly changing as TCAP becomes the predominant traffic generator and as the SS7 network expands and becomes more sophisticated.

		Local Number Portability (LNP) has increased the amount of TCAP traffic across the SS7 network in giant proportions. As subscribers begin switching to competitive local access providers, the amount of TCAP traffic will grow exponentially.

		As cellular services and Personal Communications Services (PCS) become more and more popular, they will demand more and more of the network's resources. TCAP will prove to be the most valuable of all the SS7 protocols.