Chapter 9 - Overview of ISUP

Chapter 9 Overview of ISUP

		The ISDN User Part (ISUP) has been used in U.S. networks for many years now, as an alternative to the European equivalent, the Telephone User Part (TUP). In early implementations of SS7, TUP was found to be far too limited for the scope of North American networks and was modified to align with the future services of ISDN and many other network features still under development. Today, many of those features are under implementation, and the SS7 network is being utilized more and more. However, much of its potential is still untapped.

		ISUP has been a good protocol for circuit-related messages, but is already under modification to support new broadband services soon to be offered by major telephone companies. The new broadband services being offered for tomorrow's networks will require a new version of ISUP called B-ISUP.

		The ISUP is used to set up and tear down all circuits used for data or voice calls in the Public Switched Telephone Network (PSTN). In addition to its usage in the PSTN, ISUP can also be found in wireless networks for establishing trunk connections between switching centers.

		ISUP is not widely used throughout the world, in fact, the U.S. was the first to adopt ISUP for usage in its networks. The ITU is currently developing an international version of ISUP, which will be used in the international plane. Otherwise, other countries use ISUP's predecessor, the TUP.

		The TUP does not offer the same services and capabilities as ISUP, which was designed with the Integrated Services Digital Network (ISDN) in mind, and is fully compatible with the signaling in ISDN. It was for this reason that ISUP quickly replaced TUP in U.S. networks.

 

In fact, the TUP is considered as almost obsolete for those wishing to offer more control over their circuits. TUP is good for physical circuit connections, but is not capable of handling virtual circuits, permanent in digital networks.

		Another shortcoming of the TUP is its inability to support ''bearer" circuits. In a digital network, there is both a physical circuit and logical circuits which are dependent on the amount of data being sent by the "user." This bearer traffic determines how many virtual circuits will be needed to accommodate the data. The ISUP provides the mechanisms for supporting bearer traffic, but does not fully support broadband signaling, which uses a different scheme altogether.

		Additional work is currently under way to accommodate the new broadband services to be offered by the telephone companies. Asynchronous Transfer Mode (ATM) and broadband ISDN (BISDN) are making their way into the PSTN, replacing the existing DS3 and DS1 facilities used for so many years between exchanges. With these new facilities will come new configuration parameters and choices to be made by the protocol.

		The support of BISDN (which will become the subscriber interface to the broadband network) through the SS7 network is accommodated by a new signaling protocol, B-ISUP. There are many similarities between ISUP and B-ISUP; in fact, the same procedures and message types are used in both. The exception in B-ISUP lies in additional message types and changes in how circuits will be assigned to a call connection.

		Another fundamental difference being introduced with broadband signaling is the advent of fully associated signaling, rather than quasi-associated signaling. Fully associated signaling is accomplished by using the same path as the voice circuit, as would be the case when a channel from a DS3 circuit is used for signaling, and the other channels are used for voice and data. Once ATM has been deployed in the telephone networks, SS7 will be sent through the ATM network along with the voice and data.

		This will work just fine, and accomplishes the same task as quasi-associated signaling, which relies on signal transfer points (STPs) to relay the messages from the originating exchange to the destination exchange. ATM will not eliminate the need for SS7 networks, but it will change the protocols and add additional functions. Signaling ATM adaptation layer (SAAL) will eliminate MTP L2, for example, on ATM links.

		The STP will not disappear, but its role may change somewhat. The STP is still needed as a gateway into networks, or even a gateway into certain regions within a network. The STP will continue to provide global title translation services, as well as database access.

 

Additional features and functions will likely be placed on STPs to justify their existence.

		There is no problem with sending all of the B-ISUP traffic through the ATM network, and leaving the SS7 network for database access and other control functions. In fact, as the Advanced Intelligent Network (AIN) is deployed and implemented in existing networks, the traffic mix within the SS7 network will become predominantly TCAP and SCCP anyway.

		Broadband ISUP has been included in this chapter because of the similarities to normal ISUP. The new protocol is explained in less detail than normal ISUP, as the standards are still being defined.

		ISUP Services

		There are two types of ISUP services, basic and supplementary. Basic service provides the support for establishing connections for circuits within the network. These circuits can be audio circuits for voice transmission or data circuits for any digital information, voice or data. Supplementary services are all other circuit-related services, which typically encompass message transport after a call path is established.

		In addition to the two types of services, ISUP uses two methods for end-to-end signaling. End-to-end signaling is the process of sending circuit-related information from one exchange to a distant exchange. These two exchanges may be adjacent to each other or across Local Access Transport Areas (LATAs).

		The method currently used for passing signaling information to the distant exchange is called the "pass-along" method. With the pass-along method, the signaling information moves from one exchange to the next. All subsequent information related to the same circuit is then passed using the same path that was used to send the initial call setup information. This of course means that information must follow the same ISUP hops as the setup messages, which is not the most efficient method of routing.

		The alternative method is called the "SCCP" method, and uses the services of the SCCP protocol to route the message through the network. When using the SCCP protocol, the information does not have to follow the same path as the call setup information. In fact, it can follow any path, provided the final destination is the same.

		The SCCP method uses true network routing, and is probably more favorable for services that require information to be shared between exchanges when a call is in progress. However, today this method is not used.

		The ISUP message provides important data regarding the service being requested of the remote exchange. These services are related to the circuit specified in the Initial Address Message (IAM), which is the initial setup message used in this protocol. The receiver of an IAM then must determine if it has the resources necessary to provide the type of service being requested.

		The IAM provides the distant exchange with the calling and called party numbers, as well as information regarding the availability of SS7 signaling, whether or not the ISUP protocol is required end-to-end, and the type of network signaling available (if SS7 is not used throughout the network). The IAM also indicates whether or not further information will be available using subsequent messages.

		The ISUP protocol uses the services of the Message Transfer Part (MTP) to send signaling messages from one signaling point to another. The ANSI standard and the ITU standards do allow for usage of SCCP services as well, although there are currently no applications in U.S. networks available. The concept of using SCCP with ISUP is to allow end-to-end signaling without having to send messages to each intermediate exchange.

		An example of how ISUP messages travel from one exchange to another is found in the diagram in Figure 9.1. This diagram shows that an ISUP setup message or IAM is used to connect both ends of the voice trunk between the originating exchange and the next exchange, or tandem exchange. Once the connection is established, another connection must be set up between exchange B and exchange C by sending another ISUP setup message (IAM) from exchange B to exchange C.

		This continues through the network until there are voice circuits connected from end to end. End-to-end signaling using ISUP therefore requires many ISUP hops. If any message needs to be sent from one exchange to another exchange during the duration of the call, the same path is used.

		Figure 9.1 This figure depicts the path of ISUP setup messages for a typical telephone call. The first setup takes place from A to B. Exchange B must then initiate a circuit connection toward exchange C.

 

The reason for this is due to the limited routing capabilities of the MTP. The MTP routing function only has knowledge of the adjacent signaling points, and only provides node-to-node routing. The SCCP routing function knows the final destination of the message, and is capable of providing routing based on the final destination, or end-point, without having to know all the intermediate signaling points.

		This would allow ISUP messages to travel through the network with a minimal number of hops and still be able to maintain association with a call in progress, without using the same path of the call setup messages. At this time it is unknown if this feature will ever be implemented, although it is very likely that the Intelligent Network (IN) will find this a useful feature.

		Another fundamental change in signaling with ISUP is the handling of the service tones used by the local exchange. Before ISUP and SS7, when a local call was placed to another exchange the service tones (busy, ringback, etc.) were set by the distant exchange through the voice circuit to the calling party. With SS7, this is no longer necessary. In fact, the voice circuit does not need to get connected until the called party answers.

		The service tones can be sent by the originating exchange. This is accomplished by the distant exchange sending ISUP messages indicating the status of the call (status information is implied within many ISUP messages, such as Address Complete). For example, when the distant exchange receives an IAM, it will send an Address Complete Message (ACM) in return. The ACM is used as an acknowledgment, and it also implies that ringing is being sent to the called party.

		In most networks the service tones are sent by the destination exchange. The trunk circuits that have been reserved along the call path are not yet cut-through in both directions, but they are cut-through in one direction; from the destination exchange back to the originating exchange. This allows service tones to be sent in the backward direction to the originating exchange. If there is no answer, or the call is disconnected for any other reason, the trunks can be quickly released in the one direction (see Figure 9.2).

		If the calling party or the called party is using an ISDN interface, then the call setup information and call status information can be much more complex than with service tones. In an ISDN call, the ISUP protocol is used to carry setup information as well as call status information through the PSTN and to the exchange. This is especially advantageous when the called or calling party is terminated at a Public Branch Exchange (PBX).

		When a PBX is used, the PBX can share status and setup information with the distant PBX. This is a feature never before possible with conventional signaling, because conventional signaling was all analog and unable to support such a broad base of information.

 

		Figure 9.2 In this figure, the voice circuit is reserved but not cut-through. Service tones are sent by the local office instead of by the remote exchange.

		Even information about the station users within a PBX, such as class of service information and dialing privileges, can be shared through the PSTN to the distant PBX through the use of the ISUP protocol. Large corporations with multiple PBXs can enjoy the benefits of a large network without leasing private lines between PBXs (see Figure 9.3).

		The voice circuit in an ISUP call setup is not actually cut-through (connected) in both directions until the called party goes off-hook and answers the call. The voice circuit does get reserved for the call, and can even be tested before the setup begins. But the connection is not made in both directions until the called party answers the call.

		The most commonly asked question, then, is how does SS7 save time in call setup. The answer lies in the speed of digital call setup and teardown, versus analog signaling.

		Digital messages travel at high speeds, and allow calls to be setup much quicker than analog signaling. If you don't believe this concept, pick up a phone, and dial a number, then time how long it takes for the call to connect. Now compare the setup time with a call five years ago, before SS7 was deployed throughout the network. Many times, ringback is heard as soon as the final digit is dialed.

		When a called party is not available because of a busy condition, the reserved voice circuit is released and is immediately available for another call. In the meantime, a digital message is sent back to the originating exchange notifying the originating exchange of the busy condition. The originating exchange then sends a busy tone to the calling party.

 

		Figure 9.3 The ANM message is used to trigger cut-through on the voice trunk when the called party is within the U.S. If an international call, the trunk is cut- through upon receipt of the ACM message.

		While the originating exchange is sending a busy tone to the calling party, the voice circuit has been released (between the exchanges), and only the circuit between the calling party and the local exchange is maintained.

		There are many other advantages of using ISUP and TUP for call setup and teardown. If one understands the basic concepts of how a call is set up and then released, the advantages become much clearer. In the next section, we will talk about how a call is set up in greater detail, providing examples of different call setup situations.

		Call Setup and Teardown

		To understand how ISUP works and its advantages, we need to first understand the basics of how a call is set up and released in the SS7 network. The ISUP protocol is used to accomplish this. These examples will assume there are analog lines being used between both parties and the telephone company. We will later examine the procedures used with ISDN circuits.

		When a caller lifts the receiver, the local exchange (exchange A) determines that the caller is off-hook by the presence of current on the subscriber line interface (DC signaling). The local exchange acknowledges the presence of loop current by sending a service tone (dial tone) to the calling party.

		The calling party then dials digits, which signals to the local exchange the address (telephone number) of the distant called party. The local exchange must wait until all digits have been dialed, then examine the first three digits dialed to determine if the calling party dialed an area code or a prefix (determined by the North American Numbering Plan) as shown in Figure 9.4.

		If the exchange determines that the number dialed was a long-distance number, the call is routed to a long-distance carrier through a Point-of-Presence (POP) in the Local Access Transport Area (LATA) of the calling party. The prefix and the subscriber number (last four digits of the telephone number) are then routed to the distant exchange.

		The local exchange determines how it will connect this call based on information in its trunk routing tables. These routing tables identify which voice circuits to use to establish an end-to-end circuit with the least number of hops. When it determines which voice circuits to use, a call setup message is created and sent to the exchange which will provide the first voice connection (exchange B).

		This exchange may not be the final destination for this call. In fact, it may be a tandem, used as an intermediate switch to reach the final destination. Intermediate tandem switches are used to prevent all exchanges having to have voice circuits to all other exchanges within any given LATA.

		Figure 9.4 When the calling party completes dialing digits, the local exchange determines which trunk needs to be reserved for the call. An Initial Address Message (IAM) is then generated toward the first exchange. When the ACM has been received, the local exchange begins delivering ring-back tone, even before the called party's telephone begins ringing, in some cases.

 

		The call setup is sent using the ISUP protocol through the SS7 network. The Signal Transfer Point (STP) serves as a network router for these messages, simply routing SS7 messages to their proper destination, and does not play any real significant role in setting up the voice circuits. In general, the STP has no real knowledge of the ISUP message; it only delivers it to the proper exchange.

		The IAM is created by the local exchange (ex-change A) and sent to the intermediate tandem exchange (exchange B). In this IAM can be found all the information necessary for the tandem exchange to establish a connection. The IAM message does not contain information for the final destination, as it is not establishing a connection from originating exchange A to destination exchange C.

		The tandem exchange will acknowledge receipt of the IAM by sending an ACM to the originating exchange A when it has received an ACM from the destination exchange. This indicates that the circuit designated as reserved in the IAM has been reserved at exchange B, and a connection can be made when ready.

		The tandem exchange can begin setting up the next circuit between itself and the destination exchange C. This is accomplished by generating another IAM, including the called and calling party address information provided by the originating exchange A, and sending the IAM to the destination exchange C.

		The IAM will also specify the signaling method to be used for this call. If the IAM specifies that the ISUP protocol is to be used end-to-end (required), then the call must be set up using the ISUP protocol. If the tandem exchange (B) cannot set up the call using ISUP (in the event the exchange does not support ISUP to the destination, or there are no facilities available which use ISUP), the call is rejected, and a message indicating the reason for rejection is sent back to the originator.

		If the IAM indicates that ISUP is preferred, the receiving exchange will check for available resources to determine if the call can be set up using ISUP. If not, the call is still set up, but using a different method, such as MF signaling or Telephone User Part (TUP) protocol.

		The IAM can also indicate that ISUP is not required "all the way," in which case the call is set up using whatever method is available. These methods could be ISUP, TUP, or a non-SS7 signaling method such as MF (discussed in Chapter 1).

		An intermediate exchange (such as the tandem in our example) can change some of the information in the IAM. The first six digits of the called party number, information regarding the connection (nature of connection), and the end-to-end method indicator can be modified. All other fields are passed transparently to the distant exchange.

		As is sometimes the case, exchange C does not have to be the final destination. There can be more exchanges or tandem exchanges required establishing this end-to-end voice circuit, but for simplicity we will only discuss three connection points.

		Upon receipt of the IAM, the distant exchange must examine the message to determine if there will be any further information in subsequent messages. If not, the called party number is examined and the exchange determines if the called party is available or busy. If the called party is busy, a release message (REL) is sent to the originator and the circuit is immediately released for another call.

		The distant exchange may find that the called party number is not included in the IAM. When this occurs, the distant exchange (exchange C) must request the called party number using the protocol services specified in the IAM. Two methods can be used, end-to-end (SCCP services) or link-to-link (pass-through using MTP). Currently, only the pass-through method is used in ANSI networks.

		If the called party is not busy and the call can be accepted, an ACM is sent to exchange B. Exchange B then sends an ACM to the originating exchange. The distant exchange (exchange C) then signals the called party that there is a call by sending ringing to the called party on its subscriber line (DC signaling).

		No message is returned until the called party answers the phone. When exchange C determines the called party has lifted their receiver by detecting loop current (DC signaling) on the subscriber interface, an Answer Message (ANM) is generated and returned to the tandem exchange (exchange B). The same path used to send the IAM from exchange B to exchange C is used for the ANM. This means the same links and the same STPs are used for all associated ISUP messages. The voice circuit between exchange C and exchange B is immediately cut-through when exchange B receives the ANM.

		When the tandem exchange receives the ANM, it sends an ANM to the originating exchange A using the same path the IAM was received on. The originating exchange can then begin cut-through on the voice circuit between itself (exchange A) and the tandem exchange (exchange C).

		Once the voice circuit is connected, conversation can begin, and no messages are necessary through the SS7 network until either party goes on-hook. There are some features associated with CLASS and some other calling features that may require exchanges to share information with each other during the duration of the call. Presently, the communications is handled using the same path as the setup messages. However, the standards do allow the use of SCCP to carry such information from one end to the distant end without following the call setup path (see Figure 9.5).

 

		Figure 9.5 If SCCP services are used for ISUP, the intermediate exchange can be bypassed and ISUP messages sent directly to the remote exchange. This applies only to messages between two exchanges after a connection is established and allows the switches at both ends of a call to exchange status information.

		The above discussion applies to normal routing procedures. Local Number Portability (LNP) has changed the way calls are routed. The ISUP protocol has been modified to provide additional information needed to route calls to numbers that have been "ported." Numbers are considered ported when the subscriber changes from one local service provider to another, keeping their telephone number. In the past, you had to give up your telephone number and obtain a new telephone number from the new service provider.

		With LNP, calls are no longer routed based on the digits dialed. Each call made to an NPA-NXX that has a number ported in it requires a database transaction to obtain additional routing information. The database will identify whether or not the dialed number has been ported, and if so where to route the call.

		For routing purposes, each end office (and tandem) is assigned a 10-digit location routing number (LRN). The LRN is usually the same NPA-NXX currently assigned to the end office switch, with all zeroes for the last four digits. For example, the end office serving (919) 460-xxxx will be assigned the LRN of [phone].

		The called party number field in the ISUP IAM will now contain the LRN if the dialed number has been ported to another carrier's network. The dialed digits will be placed in the generic access parameter (GAP). Before a call can be routed, the end office must first access the LNP database within its region, and obtain the LRN for the dialed number. For more information about LNP, see Chapter 10.

 

If the digits dialed are for an international number, the call setup sequence is the same. The only difference is the usage of the international network to route the call. In the international plane, there is no knowledge of the dialed digits other than the country code and the city code. The STPs at the international plane route messages based on their international country code and the city code is used by the gateway STP to determine how to route the call within its own network (see Figure 9.6).

		The addressing of SS7 entities is virtually the same format. The primary differences between national and international addressing are the point code structure of each SS7 signaling point. The ITU-TS standard calls for a 14-bit point code structure; divided as 3-bit zone identification, 8-bit area/network identification, and 3-bit signaling point identification.

		National point codes follow a simple 14-bit point code, and are usually found to have no divisions. The exception to this rule is in the case of the ANSI point code structure, which uses a 24-bit point code, with a network identification, cluster identification, and member identification (refer to the chapter on level three MTP).

		The call setup messages must be routed according to the dialed digits (or the LRN as in the case of LNP), which must then be translated at some point to a point code. The point code translation within the national plane is usually that of a gateway STP, which then translates the point code into an international point code (14 bit) and routes the message to the proper gateway STP according to the country code dialed.

		Figure 9.6 International calls rely on the international SS7 network. This network uses ITU-TSS SS7 standards, which are somewhat different from the national standards. The national standard used in the U.S. is ANSI, with Bellcore standards used within the Bell Operating Company (BOC) networks.

 

		When a gateway is used to route a call setup message into another network, the exit message is used to indicate that a call connection has been completed in the other network. The exit message may include the outgoing trunk group number used to connect the voice circuit to the other exchange, although this information is optional.

		The voice circuit in the case of an international connection can be connected as soon as the ACM is received. This depends on the network and may or may not be true. In theory, the trunk does not have to be cut-through until after the called party answers the call, but this does not imply actual practice.

		When taking a call down and releasing all circuits associated with that call, several steps must take place. When either caller goes on-hook, the subscriber line is released immediately (DC signaling). The exchange then sends a suspend message (SUS) to its tandem, or whichever exchange it is directly adjacent to (exchange B in Figure 9.7).

		When the adjacent exchange (exchange B) receives the SUS, it sends a SUS to its adjacent exchange. This continues through the network until the SUS has reached the originating exchange. As soon as the calling party returns to an on-hook condition, the release message (REL) is sent toward the distant exchange.

		Figure 9.7 Normal call release procedure

 

When an exchange receives a REL, it returns a release complete message (RLC) as an acknowledgment. The RLC indicates that the circuit has been returned to an idle condition. The tandem exchange in the diagram must then generate a REL to its adjacent exchange (exchange A in Figure 9.7), and follow the same procedure to release its circuit. Exchange A in this example would then generate an RLC. Upon receipt of the RLC, exchange B would then release its circuit.

		While all this is going on, the circuit between exchange B and exchange C has been released and could be set up for another connection associated with a different call. With conventional analog signaling, this would not be possible; the circuit would remain seized until the distant exchange was ready to release. This often would result in ''hung" circuits, especially when the calling party did not hang up their phone.

		Call Setup and Teardown of ISDN Circuits

		The ISUP protocol was intended for use with digital subscriber interfaces such as ISDN. The intent was to provide a protocol with more versatility, allowing the exchange of status information and other forms of circuit data to be exchanged from local ISDN network to distant ISDN network.

		Where distance and other factors prevent ISDN networks from being connected to one another, SS7 can be used to bridge the gap. The ISDN protocol is transparent to SS7, because there is direct mapping from the ISDN parameters to the ISUP protocol. This makes interworking very easy, while still maintaining the security of the network.

		The procedures for setting up and tearing down an ISDN connection are somewhat simpler than those for conventional signaling or analog subscriber circuits. The ISDN messages are compatible, but somewhat different than those used in ISUP. Figure 9.8 illustrates how ISDN and ISUP protocol messages map to one another, showing a typical call setup and teardown.

		In the ISDN circuit, a SETUP message is sent from the originating (calling) party to the local exchange. The local exchange telephone switch is capable of interpreting ISDN messages at the line circuit level, and converts this into an SS7 IAM message.

		The Initial Address Message (IAM) contains the same information as the SETUP message. In fact, there is direct mapping from the ISDN protocol to the SS7 protocol, making them compatible interworking protocols.

		The IAM is then sent in the forward direction to the next exchange. As seen in the drawing, there may be several exchanges involved in order for the voice circuit to be connected end-to-end. The IAM must be sent between each exchange and acknowledged between each exchange. Additional information may be sent between exchanges before the circuit has been completed using end-to-end signaling.

		Figure 9.8 This figure illustrates how ISDN signaling maps to SS7 signaling. Backward and forward setup messages are used to exchange additional information regarding a call between two exchanges.

		When the distant exchange has been reached, the IAM message is converted back into an ISDN SETUP message. The SETUP message is then sent to the called party device (either an ISDN Network Terminal or an ISDN PBX).

 

When the called party has accepted the SETUP message, the called party returns an ISDN ALERTING message. This message indicates that all the addressing signals have been received, and the ISDN terminal (telephone) is now ringing. No ringing generator is sent from the local exchange, because ISDN is digital. The ringing is generated at the telephone device itself, based on the receipt of the SETUP message.

		When the exchange receives the ALERTING message, it is converted into the SS7 Address Complete Message (ACM), which indicates that the SS7 exchange has received all of the addressing signals and the called party is being signaled. The ACM at the originating exchange is converted into an ALERTING message.

		When an ISDN terminal receives an ALERTING message, it indicates that the called party is being signaled. No further action is necessary, although charging may begin after receipt of the ACM. This is optional, and not widely acceptable in most cases.

		When the called party answers, a CONNECT message is sent in the backward direction. The SS7 equivalent to the CONNECT message is the Answer Message (ANM). The ANM is passed through each of the exchanges until the originating exchange is reached, where the ANM is converted back into a CONNECT message.

		The CONNECT message indicates that the called party has answered, and it usually triggers cut-through on the voice circuit (this is network dependent). The ANM is usually used in the SS7 network to trigger billing.

		When the call has been completed, either party may terminate the call by hanging up. When either party hangs up, the ISDN network creates a DISCONNECT message. The local exchange receives this DISC message and converts it to a REL. The REL is sent to the next exchange, which acknowledges the REL with a RLC. The RLC triggers the actual release of the voice circuit.

		Note that this continues on through the network between each of the exchanges until all of the circuits have been released. As soon as a circuit has been released, it is immediately available for another call. It is quite possible that the local loop can be released and already connected to another call before all the circuits from a previous call have been released end to end, although timers are usually used to prevent this from occurring and creating troubles.

		Call Setup and Teardown of Broadband ISDN Circuits

		Broadband ISDN (BISDN) brings on many challenges for the ISUP protocol. There are different addressing schemes used in BISDN, with support of virtual paths as well as virtual connections within a virtual path. The ISUP protocol does not support this addressing, and has been modified as broadband ISUP (B-ISUP).

		The standards for B-ISUP are still evolving, although the first Bellcore publications have been released and included in the GR-246-CORE. In this publication, several new sections have been added describing the services and procedures for B-ISUP.

		The ANSI standards for BISDN signaling are the same as those formulated by the ITU-TS, which is good news for all those in international networks. This means simpler provisioning and implementation. This section will define the message types and procedures used to set up and tear down broadband circuits.

		Before a circuit may be assigned for a call, it must be determined which signaling point will be responsible for the assignment of bandwidth and virtual path/virtual channels for a given circuit. One of the inherent problems in broadband is the possibility for "glare," or dual seizure. This occurs when two signaling points assign calls to the same virtual path/virtual connection combination. For this reason, end nodes will share the responsibility of assigning these characteristics 50/50.

		All odd-numbered Virtual Path Connection Identifiers (VPCIs) are the responsibility of one signaling point, while even-numbered VPCIs are the responsibility of the other signaling point. This prevents the possibility of dual seizure, or glare. The exchange with the highest point code will be responsible for even-numbered VPCIs.

		In the event there are no available VPCIs controlled by an exchange, a setup may be issued for a VPCI not controlled by the exchange. In this event, the virtual path and virtual connection ID are not provided (these parameters are found in the connection element identifier parameter, which is normally included in the setup message).

		If there is an incoming call on a circuit controlled by the receiving exchange, the connection element identifier is not included. It is a request for service, and the controlling exchange must assign the virtual path and virtual connection. If this information has not been provided, then it must be assumed that the originating exchange does not have any available virtual paths/virtual connections within its control, and needs assignment from the other half.

		When assigning a circuit, the exchange must determine what bandwidth is necessary for the call. This is determined by reading the parameters in the setup message. Once it is determined, the exchange assigns the appropriate virtual path connection within its control.

		As previously mentioned, each exchange is responsible for the assignment of virtual path connections and bandwidth for one-half of the available virtual path connections. If there is not enough bandwidth available at an originating exchange, it sends a request to the remote exchange (for which it wishes to establish a connection) without any virtual path connection information.

		The receiving exchange then determines if there is ample bandwidth available for the connection and if so, provides the virtual path connection information to the requester. If there is not enough bandwidth available, then the request is denied using the REL, with the cause "cell rate not available."

		Once an exchange has received all of the information necessary to establish a connection, the receiving exchange must determine if the call is to be routed to another exchange (intermediate exchange) or if the call is to be terminated within itself. If the call is to be routed through another exchange, then normal ISUP routing is duplicated.

		Normal ISUP procedures call for the same setup procedures used to establish a connection to the first exchange which must be repeated for all subsequent exchanges and used to reach the final destination. This is also true in the case of BISDN.

		Routing information may be stored within the exchange itself or in a central database accessible by all exchanges. The latter is becoming true in cellular networks, where the Home Location Register (HLR) used to store location information as well as subscriber information is moving to a central location, accessible by all other cellular providers.

		The TCAP is then used to access the centralized database for additional routing instructions, before call set-up procedures can begin. This allows for fewer resources within the exchange, and optimizes the individual service providers' network.

		There are several parameters used to determine the best route for a connection. The called party address is the most useful, but the broadband bearer capability and the Asynchronous Transfer Mode (ATM) cell rate must also be considered. The ATM cell rate determines which interoffice facility will need to be used to get the connection through the Public Switched Telephone Network (PSTN).

		So far, we have only discussed procedures for assigning virtual path connections between two exchanges. The message structures for these procedures are virtually the same as for normal ISDN signaling. The exception is the addition of new parameters that specifically support BISDN and some new message types that augment existing message types.

		When service is requested, the Initial Address Message (IAM) is sent to the remote exchange. This IAM is almost identical to the one we talked about in the previous sections, but has additional parameters supporting broadband ISDN and ATM (see the section on message structure for broadband ISUP parameters).

		Preceding the B-ISUP IAM parameter is the routing label, which may or may not specify the actual ATM circuit information. According to the rules discussed previously about controlling exchanges, the IAM may act as a request. The receiving exchange may have to provide the circuit identification.

		If this is the case, then an IAM acknowledgment will be sent to the originating exchange providing the circuit identification. This is a new message type for ISUP, and is used only in B-ISUP protocol.

		Once the circuit identification has been provided, an address complete can be returned by the originating exchange, which serves as an acknowledgment that the addressing information has been received.

		Other than additional or different parameters in the various message types, the sequence of messages is almost identical to normal ISUP. The major changes have to do with the assignment of the actual circuit, which is split between the two exchanges. Also keep in mind that these are logical connections, not physical connections as in Plain Old Telephone Service (POTS). This complicates the procedures somewhat, and expands the message sizes exponentially.

		Message types and parameters for BISDN support are found at the end of this chapter, and are labeled as such to differentiate them from normal ISUP messages and parameters. These are still evolving, and what is published in this book represents the first version as published by ANSI and Bellcore.

		Interworking with Non-SS7 Networks

		While most all of the PSTN now use SS7 throughout the network, there are still some segments that are using conventional signaling. Conventional signaling in most of these cases consists of MF signaling.

		SS7 must be able to function and internetwork with networks using conventional signaling. One of the primary issues is the reserving of a voice circuit. Unlike conventional signaling, the voice circuit does not get connected until the distant party answers, or at least until both exchanges have sent and received all the addressing information required to connect the call.

		In MF signaling, the circuit is connected when the calling party completes dialing the digits, and is used to signal the distant exchange. Therefore, some method must be established for allowing voice circuits to be "reserved" and tested in conjunction with the SS7 protocol.

		To accomplish this, a circuit reservation procedure is used. Prior to the sending of an IAM, which is used to send addressing information necessary to establish the circuit connection, a Circuit Reservation Message (CRM) is sent to the non-SS7 exchange. This is then converted to MF signaling by that exchange, and from that point on MF signaling may be used. The exchange acknowledges receipt of the circuit reservation message by sending in the backward direction (back to the originating exchange) a Circuit Reservation Acknowledgment (CRA).

		The originating exchange can then specify a continuity test to be invoked by the exchange using MF signaling by sending a Continuity Check Request (CCR) message in the forward direction. This message invokes a loopback test at the remote exchange on the voice circuit. The results of the continuity test are then returned to the originating exchange using the Continuity Test (COT) message.

		After receipt of the COT message, if the continuity test proved successful, an IAM is sent by the originating exchange to begin the normal call setup procedure. The voice circuit is reserved even though MF signaling is used, and is ready for cut-through end-to-end when the calling party answers or the address information has been successfully passed from the originating exchange to the destination exchange, depending upon network deployment.

		Interworking with MF networks is no longer efficient with Local Number Portability (LNP) becoming commonplace nationwide (and in the future, worldwide). When the MF network is reached, any contents of the ISUP IAM message are lost, with the exception of the dialed digits. The location routing number (LRN) which is found in the called party address is lost, and the dialed digits found in the GAP parameter are sent via MF to the distant or adjacent network.

		If the adjacent network is equipped with SS7, it must then perform a database query to regain the lost routing information. This of course is redundant, and adds unnecessary delay to the call setup. It also places additional burden on the network resources. This can be of major concern when you consider the number of database queries the adjacent SS7 network will be responsible for making.

		Consider this scenario; the adjacent SS7 network will be receiving scores of calls from the MF network. The SS7 network will have to perform database queries for each of those calls, even though other networks have already done this. The burden lies on the SS7 network to provide this service, when the originating network should have been the responsible network.

 

Circuit Testing

		The SS7 network provides several mechanisms for testing circuits and switches remotely. This testing is usually performed from the Operations Support Systems (OSSs) located regionally within the network. The tests can also be performed locally by testboard technicians or a maintenance center technician.

		The OSS is an operations and maintenance center that allows complete network monitoring and testing. These are fairly new (within the last 10 years) and have been deployed within regional areas of the network.

		Before SS7 and automation in the network, testing was conducted at every exchange, using testboard positions. These test positions were capable of connecting to every circuit entering and leaving the central office, and allowed technicians to test the continuity, capacitance, and other properties of the circuit.

		Today, these testboard positions have disappeared, and all the testing has been moved to remote locations where many exchanges can be tested by one maintenance center. The SS7 network is used for passing those maintenance messages and test messages through the network to the remote switches.

		The ISUP protocol also provides a means for testing circuits as well as translations in various nodes. A translation is a routing instruction, which translates dialed digits into a routable address, such as a signaling point code. This section describes two of those tests, the continuity test, and the circuit validation test.

		Continuity Testing

		Because SS7 uses a separate facility than the voice circuit for sending information to another exchange, there is no knowledge of the operational status of the voice circuit. Most voice switching systems today provide some level of circuit testing and fault isolation, providing alarms when a circuit fails. This alarm information allows diagnostics software to "busy out" the trunk, preventing calls from being routed to the failed circuit.

		In many networks, however, digital circuits are used to carry the voice and data. These digital facilities are usually DS1 or DS3 facilities, which require a series of multiplexers. For example, connecting to the voice switch is a DS0 circuit (64 kbps). This DS0 is sent through a multiplexer, which aggregates 24 DS0s and groups them into one DS1. The DS1 signal is then sent with other DS1s to another multiplexer, which aggregates 28 DS1s into one DS3. The DS3 is then used to reach another exchange, where these signals must be demultiplexed back down to their original DS0s.

 

In order for these circuits to reach the proper switch, they are cross-connected through digital cross-connect systems which allow incoming circuits to be electronically routed to the appropriate switch in the central exchange. This only adds to the problem of circuit testing and diagnostics, because the alarms and circuit status information gets lost in the multiplexing and cross-connecting and never makes its way through to the rest of the network.

		To counter this issue, SS7 provides the ability to test the voice circuit before connecting a call to it. This takes place even before the IAM message is sent. The test is known as the continuity test, and uses the COT message. There are two instances when the continuity test procedure may be used. The continuity test may be used within the same network or it may be used when connecting to networks which use Exchange Access Signaling (EAS).

		EAS uses a series of tones to indicate signaling. This method has been replaced in most instances in the U.S. by the SS7 standard of signaling, but may still exist in some rural areas. Because EAS does not support the digital messages of SS7, a conversion must be made converting the SS7 message into the analog format of EAS signaling.

		The exchange that will perform this conversion will use both EAS and DC signaling (a method called the "wink," where the polarity of the trunk is temporarily reversed and then returned to its original polarity as an acknowledgment).

		When it is determined that a continuity test is needed before a call can be set up, and the call is to another exchange using EAS or some other method of signaling other than SS7, a reservation message is sent to the adjacent exchange (exchange B). The CRM allows the voice circuit to be reserved without actually connecting the circuit. A request for a continuity test is sent in the CRM. The acknowledgment expected is the CRA.

		The CRM also contains information regarding the nature of the connection to be established. This information includes satellite requirements (if any) as well as information regarding the usage of echo cancelers and end-to-end ISUP. The natures of connection parameters are also used in the IAM message, which follows the continuity test.

		After the circuit has been reserved, the COT message is sent via SS7. The COT message indicates to the adjacent switch that the voice circuit should be tested for continuity using conventional testing methods (usually a loop-back test). The results of the COT test (if successful) are carried in the IAM.

		In the event the circuit should fail the continuity test, the circuit is released, and a COT message with "test failed" is returned to the originating exchange (originating being the exchange which requested the continuity test to be performed). Another circuit is selected and the procedure begins again on the new circuit.

 

		Figure 9.9 MF signaling is not as prominent in the U.S. networks as it was five years ago. This figure shows the interworking of CCS7 to an MF signaling network. Prior to the IAM is the COT procedure.

		As can be seen in Figure 9.9, the COT is sent in the same direction as the IAM. When the voice circuit is tested, the requester of the message will determine if the test was successful or not. This is done by sending a signal or current on the indicated circuit, and when the adjacent switch performs a "loop back," receiving the same signal back at the originating switch. If the signal is the same as what was sent, the continuity test is said to be successful.

		The continuity test is not required on every call. Its usage is network dependent. Some networks will perform a continuity test on every circuit selected before every call, even when SS7 is used throughout the network. Other networks will perform a continuity test on any one circuit every 100 calls. The network operator must configure the voice switch to perform the continuity test at whatever intervals used in their network. An STP has no knowledge of these tests, as its function is to pass the information along to another SSP. This is an SSP function only.

		Circuit Validation Test

		The circuit validation test is typically used when a new facility or a new translation is added to the network. The purpose of this test is to validate the translation data and ensure that circuits between two exchanges can be selected by the routing function properly.

		The translation is tested locally first, to validate the local routing entry. Once maintenance personnel have verified the circuit can be accessed locally by CLLI code, the technician generates a Circuit Validation Test Message (CVM) to verify whether the distant end can route to the new entry using the new translations.

		The distant end will perform various tests upon receipt of this test message to verify that the physical port of a signaling link can be accessed for the new translation, and a CLLI code can be derived from the port. A response is sent to the originating exchange providing the results of the test by the Circuit Validation Response (CVR) message.

		This test should be part of the routine maintenance check anytime translations are added to a signaling point. It can also be helpful in troubleshooting routing problems that can occur between two exchanges.

		Functionality of the ISUP Protocol

		The ISDN User Part (ISUP) protocol is a circuit-related protocol, used primarily for the establishment of connections between exchanges for the transmission of bearer traffic. The bearer traffic, which is usually generated by subscribers, can consist of voice, data, video, multimedia, or audio.

		In today's network, only voice and data are achievable. Through the development of technologies such as ATM and broadband ISDN, video and multimedia will also be available through the PSTN.

		Regardless of the technology, ISUP protocol provides the mechanism for establishing the connections from the originating exchange to the destination exchange, without using the bearer circuit itself.

		In addition to connection establishment, ISUP also provides a means for passing information between exchanges associated with a call that is already in progress. However, the connection must already be established and the information must be related to that call's circuit or services.

		Any information about the subscriber or network features, or anything that is not directly related to the circuit itself uses the TCAP. This protocol was established (as described in the previous chapter) for non-circuit-related messages.

		The type of information provided by the ISUP protocol includes resource requirements for completion of the connection (resources such as ISUP all the way through the network and echo cancelers on the voice circuit). Bandwidth information and service information (call waiting and call forwarding, for example) are service related, and require that information be sent between both end-to-end exchanges.

		Intermediate exchanges do not need to see this information, as it does not involve their interaction. The objective of the intermediate exchange is to provide the connection through their facilities to the next exchange, until an end-to-end path is established for the bearer traffic.

		ISUP Services

		The ISUP protocol provides two methods for reaching the end destination. As mentioned in the previous discussion about ISUP functions and call setups, there are two types of services provided by ISUP: Basic Service, and Supplementary Service.

		In addition to these two types of services, there are two ways to reach the end destination. End-to-end signaling can use either the SCCP Method or the Pass Along Method. Even though these have been defined already, we will repeat them here as a reference.

		Basic Service

		Basic service is defined as the setup and teardown of circuits in the telephone network. These circuits are used for voice, data, and video transmission. Currently, most networks are using some form of digital transmission for all transmission, regardless of the source.

		This digital transmission is now being further enhanced by the addition of fiber optics into the network. Basic services will still be used for setting up and tearing down these connections as well.

		As broadband technologies such as ATM and broadband ISDN are deployed, it will be basic services that will be used to control these circuits. The protocol does not care what is being transmitted, although it will carry some indication of the source and the type of transmission being carried.

		Supplementary Service

		Supplementary service is defined, as all other services needed to support these circuits. Other services may include the sending of caller information from one end point to another while a call is in progress. This information may be feature related or caller related.

 

The Intelligent Network (IN) will rely on supplementary service to send information about established calls. This is different than the usage of TCAP, as TCAP is not circuit related.

		End-to-end Signaling

		End-to-end signaling is defined as signaling information that must be sent from the originating exchange to the final destination exchange. This information may be part of basic services or supplementary services.

		End-to-end signaling will almost always involve intermediate signaling points, even though they are not concerned with the call itself. There are two ways to reach the final destination exchange for end-to-end signaling. These are explained in the following text.

		SCCP Method

		SCCP can be used to provide network (Layer 3) routing for messages, but it is not used in today's U.S. networks. The usage of SCCP for end-to-end signaling would be an enhancement over the current method, however. The SCCP protocol allows ISUP messages to be routed to the distant exchange using any route, but only for messages related to a circuit already connected end to end.

		The method currently used requires the ISUP message to use intermediate switches, using the same path as the messages used to set-up the circuit associated with the information being sent.

		Pass Along Method

		The pass along method is widely used in today's network. This method uses the same path as the setup messages. This method works, but requires messages to make unnecessary stops at intermediate switches.

		This is not necessary, since the information does not concern the intermediate switch. It would be much more efficient if the message could be sent directly to the exchange through STPs, using any available route.

		Message Format

		The ISUP protocol uses message types to indicate the type of message being carried as well as the format of the message (see Figure 9.10). Each message type has a distinct format, with mandatory and optional parameters. The parameters depend on the message type.

 

		Figure 9.10 This figure shows the components used in an ISUP message.

		As found in the TCAP protocol, the ISUP also uses mandatory fixed parts and mandatory variables. These are parameters that must always exist, depending on the type of ISUP message. Again, the parameters used will depend on the message type.

		Circuit Identification Code (CIC)

		The Circuit Identification Code (CIC) identifies the circuit being setup or released (see Figure 9.11). The CIC may be a voice trunk or any other transmission medium in the PSTN.

		Currently, there are no defined standards for allocating circuit identifiers. These are determined by agreement between the telephone companies. The CIC is provided to the originator of the ISUP message (SSP) by the end switch.

		The end switch may be incorporated into the SSP, as many of these systems are fully integrated. This means that a voice subsystem provides the switching functionality for the voice circuits while the SS7 subsystem provides all the circuit control.

 

		Figure 9.11 The CIC is used to identify the trunk circuit to be connected and associated with this message. The CIC is not used in broadband services. Instead, virtual paths and virtual connections are identified in the B-ISUP message content.

		Message Type Codes for Normal ISUP

		This is a one-octet field that is used to define the action to be taken by the exchange. In addition, the message type also implicitly defines the message structure. The parameters used will depend on the message type (Figure 9.12).

		The message type is found in the mandatory fixed part of the message. The coding of the message type follows the same general rule used in other SS7 protocols. Any message type intended for national usage (internetworking) is to be coded using the upper range of the code. The upper range begins at 1111 1111, and works backward.

		Following are the message types currently used in U.S. networks and defined in ANSI T1.113-1992 as well as BELLCORE GR-246-CORE, T1.113.3.

		Figure 9.12 As found in TCAP and SCCP, the message type field identifies the nature of the message. Each message type consists of specific parameters (both mandatory and optional).

 

Message Types	H	G	F	E	D	C	B	A
Initial Address (IAM)	0	0	0	0	0	0	0	1
*Subsequent Address (SAM)	0	0	0	0	0	0	1	0
Information Request (INR)	0	0	0	0	0	0	1	1
Information (INF)	0	0	0	0	0	1	0	0
Continuity (COT)	0	0	0	0	0	1	0	1
Address Complete (ACM)	0	0	0	0	0	1	1	0
*Connect (CON)	0	0	0	0	0	1	1	1
Forward Transfer (FOT)	0	0	0	0	1	0	0	0
Answer (ANM)	0	0	0	0	1	0	0	1
Release (REL)	0	0	0	0	1	1	0	0
Suspend (SUS)	0	0	0	0	1	1	0	1
Resume (RES)	0	0	0	0	1	1	1	0
Release Complete (RLC)	0	0	0	1	0	0	0	0
Continuity Check Request (CCR)	0	0	0	1	0	0	0	1
Reset Circuit (RSC)	0	0	0	1	0	0	1	0
Blocking (BLO)	0	0	0	1	0	0	1	1
Unblocking (UBL)	0	0	0	1	0	1	0	0
Blocking Acknowledgment (BLA)	0	0	0	1	0	1	0	1
Unblocking Acknowledgment (UBA)	0	0	0	1	0	1	1	0
Circuit Group Reset (GRS)	0	0	0	1	0	1	1	1
Circuit Group Blocking (CGB)	0	0	0	1	1	0	0	0
Circuit Group Unblocking (CGU)	0	0	0	1	1	0	0	1
Circuit Group Blocking Acknowledgment (CGBA)	0	0	0	1	1	0	1	0
Circuit Group Unblocking Acknowledgment (CGUA)	0	0	0	1	1	0	1	1
*Call Modification Request (CMR)	0	0	0	1	1	1	0	0
*Call Modification Completed (CMC)	0	0	0	1	1	1	0	1
*Call Modification Reject (CMRJ)	0	0	0	1	1	1	1	0
*Facility Request (FAR)	0	0	0	1	1	1	1	1
*Facility Accepted (FAA)	0	0	1	0	0	0	0	0
*Facility Reject (FRJ)	0	0	1	0	0	0	0	1
Facility Deactivated (FAD)	0	0	1	0	0	0	1	0
Facility Information (FAI)	0	0	1	0	0	0	1	1
Loop-back Acknowledgment (LPA)	0	0	1	0	0	1	0	0
CUG Selection & Validation Request (CSVR)	0	0	1	0	0	1	0	1
CUG Selection & Validation Response (CSVS)	0	0	1	0	0	1	1	0
*Delayed Release (DRS)	0	0	1	0	0	1	1	1
Pass Along (PAM)	0	0	1	0	1	0	0	0
Circuit Group Reset Acknowledgment (GRA)	0	0	1	0	1	0	0	1

 

Message Types	H	G	F	E	D	C	B	A
Circuit Query (CQM)	0	0	1	0	1	0	1	0
Circuit Query Response (CQR)	0	0	1	0	1	0	1	1
Call Progress (CPG)	0	0	1	0	1	1	0	0
*User-to-User Information (USR)	0	0	1	0	1	1	0	1
Unequipped Circuit Identification Code (UCIC)	0	0	1	0	1	1	1	0
Confusion (CFN)	0	0	1	0	1	1	1	1
*Overload (OLM)	0	0	1	1	0	0	0	0
*Charge Information (CRG)	0	0	1	1	0	0	0	1
Facility (FAC)	0	0	1	1	0	0	1	1
Circuit Reservation Acknowledgment (CRA)	1	1	1	0	1	0	0	1
**Circuit Reservation (CRM)	1	1	1	0	1	0	1	0
**Circuit Validation Response (CVR)	1	1	1	0	1	0	1	1
**Circuit Validation Test (CVT)	1	1	1	0	1	1	0	0
**Exit (EXM)	1	1	1	0	1	1	0	1

		The previous message types have been defined in the ANSI and Bellcore standards as well as ITU-TS. Each of these message types has a distinct structure, with parameters. Following are descriptions of each of the message types and the message structure that accompanies it.

		The section that follows provides the one octet value which indicates the message type (in bold), followed by the parameter names and the one octet values for the parameter names. Each parameter may have several additional bits defining the actual parameter. This section only provides the values for the parameter names.

		The parameters shown as optical are supported within each message type, but their usage is dependent on the network, and may or may not be used. Many of these parameters may be used in multiple message types, which is why they are discussed in the last section of this chapter.

		The following section illustrates the message format and provides the basic structure for each message type. The next section following this will provide the detailed structure for each parameter type along with a description of the parameter. Refer to the last section for detailed information on parameters. All parameters with an asterisk are used in ITU ISUP only.

		* ITU-TS only, not currently specified in ANSI or Bellcore networks.

		** ANSI only, not currently specified in ITU-TS networks.

 

Message Type Structure

		Figure 9.13

 

Initial Address Message	0	0	0	0	0	0	0	1
Fixed Mandatory Parameters
Nature of connection indicators	0	0	0	0	0	1	1	0
Forward call indicators	0	0	0	0	0	1	1	1
Calling party's category	0	0	0	0	1	0	0	1
Variable Mandatory Parameters
User service information	0	0	0	1	1	1	0	1
Called party number	0	0	0	0	0	1	0	0
Optional Parameters
Access transport	0	0	0	0	0	0	1	1
Business group	1	1	0	0	0	1	1	0
Call reference	0	0	0	0	0	0	0	1
Calling party number	0	0	0	0	1	0	1	0
Carrier identification	1	1	0	0	0	1	0	1
Carrier selection information	1	1	1	0	1	1	1	0
Charge number	1	1	1	0	1	0	1	1
Circuit assignment map	0	0	1	0	0	1	0	1
Connection request	0	0	0	0	1	1	0	1
*CUG interlock code	0	0	0	1	1	0	1	0
Egress service	1	1	0	0	0	0	1	1
Generic address	1	1	0	0	0	0	0	0
Generic digits	1	1	0	0	0	0	0	1
Generic name	1	1	0	0	0	1	1	1
*Generic notification indicator	0	0	1	0	1	1	0	0
*Generic number	1	1	0	0	0	0	0	0
*Generic reference	0	1	0	0	0	0	1	0
Hop counter	0	0	1	1	1	1	0	1
Information request indicators	0	0	0	0	1	1	1	0
Jurisdiction information	1	1	0	0	0	1	0	0
*Location number	0	0	1	1	1	1	1	1
*MLPP precedence	0	0	1	1	1	0	1	0
*Network specific facility	0	0	1	0	1	1	1	1
Network transport	1	1	1	0	1	1	1	1
Operator services information	1	1	0	0	0	0	1	0
*Optional forward call indicators	0	0	0	0	1	0	0	0
Original called number	0	0	1	0	1	0	0	0
*Originating ISC point code	0	0	1	0	1	0	1	1
Originating line information	1	1	1	0	1	0	1	0
*Parameter compatibility information	0	0	1	1	1	0	0	1
Precedence	0	0	1	1	1	0	1	0
*Propagation delay counter	0	0	1	1	0	0	0	1
Redirecting number	0	0	0	0	1	0	1	1
Redirection information	0	0	0	1	0	0	1	1

 

Initial Address Message	0	0	0	0	0	0	0	1
Remote operations	0	0	1	1	0	0	1	0
Service activation parameter	1	1	1	0	0	0	1	0
Service code indicator	1	1	1	0	1	1	0	0
Special processing request	1	1	1	0	1	1	0	1
Transaction request	1	1	1	0	0	0	1	1
Transit network selection	0	0	1	0	0	0	1	1
*Transmission medium requirement	0	0	0	0	0	0	1	0
*Transmission medium requirement prime	0	0	1	1	1	1	1	0
User service information	0	0	0	1	1	1	0	1
User service information prime	0	0	1	1	0	0	0	0
User-to-user indicators	0	0	1	0	1	0	1	0
User-to-user information	0	0	1	0	0	0	0	0

		This is the message used to establish a connection on a specified circuit. The IAM provides the circuit information which includes the carrier identification (long-distance carrier to be used for this call) and any special requirements to be considered in the handling of this call. The IAM message is by far the most comprehensive of the ISUP messages, with many parameters. Refer to the end of this chapter for the parameter values and definitions.

		Figure 9.14

Subsequent Address (SAM)

0

0

0

0

0

0

1

0

		No procedure is presently defined for ANSI networks. This message is used in ITU-TS networks only. The structure of this message has been omitted from this section, as the scope of this book is ANSI and Bellcore networks. Refer to the ITU specifications for information regarding this and other messages.

 

		Figure 9.15

Information Request (INR)	0	0	0	0	0	0	1	1
Fixed Mandatory Parameters
Information request indicators	0	0	0	0	1	1	1	0
Optional Parameters
Call reference	0	0	0	0	0	0	0	1
Connection request	0	0	0	0	1	1	0	1
*Network specific facility	0	0	1	0	1	1	1	1
Network transport parameter	1	1	1	0	1	1	1	1
*Parameter compatibility information	0	0	1	1	1	0	0	1

		The Information Request (INR) can be sent by an exchange while a call is in progress to request additional information from another exchange. The additional information is carried in an Information message (INF), and may provide redirection instructions (forwarding) or other call-handling information.

 

		Figure 9.16

Information (INF)	0	0	0	0	0	1	0	0
Fixed Mandatory Parameters
Information indicators	0	0	0	0	1	1	1	1
Optional Parameters
Access transport	0	0	0	0	0	0	1	1
Business group	1	1	0	0	0	1	1	0
Call reference	0	0	0	0	0	0	0	1
Calling party number	0	0	0	0	1	0	1	0
Calling party's category	0	0	0	0	1	0	0	1
Charge number	1	1	1	0	1	0	1	1
Connection request	0	0	0	0	1	1	0	1
Originating line information	1	1	1	0	1	0	1	0
Redirection information	0	0	0	1	0	0	1	1
User-to-user information	0	0	1	0	0	0	0	0

		The INF is used to pass additional information about a call upon request from the distant exchange. The information is requested from an exchange using the INR, and the reply is carried in this INF message. The type of information is usually call-handling information, such as the number to forward a call to or a billing number.

 

		Figure 9.17

Continuity (COT)	0	0	0	0	0	1	0	1
Fixed Mandatory Parameters
Continuity indicators	0	0	0	1	0	0	0	0

		The Continuity (COT) message is used for indicating the success of a continuity test (or failure). The continuity test is performed on the voice circuit depending on criteria set by the network operator at time of deployment. The COT is used to indicate the status of the preceding circuit and the circuit selected in the forward direction to the next exchange.

		Figure 9.18

 

Address Complete (ACM)	0	0	0	0	0	1	1	0
Mandatory Fixed Parameters
Backward call indicators	0	0	0	1	0	0	0	1
Optional Parameters
*Access delivery information	0	0	1	0	1	1	1	0
Access transport	0	0	0	0	0	0	1	1
Business group	1	1	0	0	0	1	1	0
*Call diversion information	0	0	1	1	0	1	1	0
Call reference	0	0	0	0	0	0	0	1
Cause indicators	0	0	0	1	0	0	1	0
Connection request	0	0	0	0	1	1	0	1
*Echo control information	0	0	1	1	0	1	1	1
*Generic notification indicators	0	0	1	0	1	1	0	0
Information indicators	0	0	0	0	1	1	1	1
*Network specific facility	0	0	1	0	1	1	1	1
Network transport parameter	1	1	1	0	1	1	1	1
Notification indicator	1	1	1	0	0	0	0	1
Optional backward call indicators	0	0	1	0	1	0	0	1
*Parameter compatibility information	0	0	1	1	1	0	0	1
Redirection information	0	0	0	1	0	0	1	1
*Redirection number	0	0	0	0	1	1	0	0
*Redirection number restriction	0	1	0	0	0	0	0	0
Remote operations	0	0	1	1	0	0	1	0
Service activation	0	0	1	1	0	0	1	1
Transmission medium used	0	0	1	1	0	1	0	1
User-to-user indicators	0	0	1	0	1	0	1	0
User-to-user information	0	0	1	0	0	0	0	0

		The ACM is sent by a distant exchange upon receipt of all address signals (IAM and any subsequent information sent) needed to establish a connection on a circuit between the two exchanges. The ACM indicates that the call is being processed, and the distant exchange is checking the availability of the called party. This could mean the called party's telephone is being signaled (ringing if analog or ''alerting message" if ISDN). In some networks, cut-through on the voice circuit can take place after receipt of the ACM.

 

		Figure 9.19

Connect (CON)

0

0

0

0

0

1

1

1

		The Connect message (CON) is defined for use in International networks but not ANSI networks.

		Figure 9.20

Forward Transfer (FOT)	0	0	0	0	1	0	0	0
Optional Parameters
Call reference	0	0	0	0	0	0	0	1

		The Forward Transfer (FOT) is used in conjunction with operator services. In exchanges where telephone calls are setup automatically (which is the case in all of North America today), an operator is only needed in certain circumstances. This message is sent in the forward direction to bring an operator into the circuit when operator assistance is required to complete the call. When the call has been completed, the operator can be recalled to terminate the call or initiate another call for the same calling party.

		Figure 9.21

 

Answer (ANM)	0	0	0	0	1	0	0	1
Optional Parameters
Access transport	0	0	0	0	0	0	1	1
Backward call indicators	0	0	0	1	0	0	0	1
Business group	1	1	0	0	0	1	1	0
Call reference	0	0	0	0	0	0	0	1
Connection request	0	0	0	0	1	1	0	1
Information indicators	0	0	0	0	1	1	1	1
Network transport parameter	1	1	1	0	1	1	1	1
Optional backward call indicators	0	0	1	0	1	0	0	1
Remote operations	0	0	1	1	0	0	1	0
Service activation	0	0	1	1	0	0	1	1
Transmission medium used	0	0	1	1	0	1	0	1
User-to-user indicators	0	0	1	0	1	0	1	0
User-to-user information	0	0	1	0	0	0	0	0

 

The ANM is sent in the backward direction to indicate the called party has answered the call. The usage of this parameter is really two-fold. In semi-automatic networks, this parameter is used for call supervision. In automatic networks, the ANM is used to begin metering the call for billing purposes. Metering of domestic calls and international calls can be activated using this parameter.

		Figure 9.22

Release (REL)	0	0	0	0	1	1	0	0
Mandatory Variable Parameters
Cause indicators	0	0	0	1	0	0	1	0
Optional Parameters
Access transport	0	0	0	0	0	0	1	1
Automatic congestion level	0	0	1	0	0	1	1	1
Call reference	0	0	0	0	0	0	0	1
Charge number	1	1	1	0	1	0	1	1
Generic address	1	1	0	0	0	0	0	0
Service activation	0	0	1	1	0	0	1	1
User-to-user information	0	0	1	0	0	0	0	0

		The Release message (REL) is sent in either direction indicating that either one of the parties (called or calling) has gone on-hook and the call is being terminated. The REL does not return the circuit back to its idle state, however. A Release Complete (RLC) must be received before the circuit is returned to idle.

 

		Figure 9.23

Suspend (SUS)	0	0	0	0	1	1	0	1
Mandatory Fixed Parameters
Suspend/resume indicators	0	0	1	0	0	0	0	1
Optional Parameters
Call reference	0	0	0	0	0	0	0	1

		This message is used when a non-ISDN party returned to an on-hook state. When an ISDN party returned on-hook, only the REL is used, but with non-ISDN the SUS is sent first, followed by the REL and the RLC. For complete call setup and teardown information, review the previous sections in this chapter on call setup and teardown.

		Figure 9.24

Resume (RES)	0	0	0	0	1	1	1	0
Mandatory Fixed Parameters
Suspend/resume indicators	0	0	1	0	0	0	1	0
Optional Parameters
Call reference	0	0	0	0	0	0	0	1

 

The RES is used in two circumstances. In a network where interworking is used, RES indicates the interworking node has reanswered. In a network with non-ISDN circuits, the RES indicates a non-ISDN called party went on-hook, but then went back off-hook again within a certain time (quickly) and the call connection should remain established. Had the called party stayed on-hook past the specified time (network dependent) the SUS message would have been sent in the backward direction to begin releasing the circuit.

		Figure 9.25

Release Complete (RLC)

0

0

0

1

0

0

0

0

		No parameters are given in the RLC, only the message type field. The RLC is used to indicate receipt of an REL message, and serves as an acknowledgment of the release. Once the RLC has been received, the indicated circuit can be released and returned to its idle state. The CIC is sent with this message, but is not an integral part of the message itself. The CIC is presented just after the routing label.

		Figure 9.26

 

Continuity Check Request (CCR)

0

0

0

1

0

0

0

1

		No parameters are given in the Continuity Check Request (CCR). The CCR is used to request continuity check equipment to be attached to the circuit indicated in the CIC field of the message. The equipment is attached to the voice circuit for loopback testing. Once loop-back has been detected the status of "successful" is sent through the SS7 network using the IAM message or the Continuity message (COT), depending on the network and the circumstances.

		Figure 9.27

Reset Circuit (RSC)

0

0

0

1

0

0

1

0

		No parameters are given in the Reset Circuit message (RSC). The purpose of this message is to allow an exchange to reset a circuit to the state that exchange thinks the circuit should be in. This occurs when a memory error occurs at an exchange, and it no longer knows the state of the circuit in question. To restart from scratch, the RSC is sent. Any calls in progress or blocked conditions are released and the circuit is returned to an idle state after an alignment procedure (not to be confused with the alignment procedure used on SS7 links).

		Figure 9.28

 

Blocking (BLO)

0

0

0

1

0

0

1

1

		No parameters are given in the Blocking message (BLO). This message allows one exchange to block a voice circuit at a remote exchange, preventing voice calls from being reserved on the voice circuit from the remote end. The circuit is identified in the CIC field.

		Figure 9.29

Blocking Acknowledgment (BLA)

0

0

0

1

0

1

0

1

		No parameters are given in the Blocking Acknowledgment message (BLA). This message acknowledges receipt of the BLO, and indicates that the circuit has been blocked. The voice circuit is identified in the CIC field.

		Figure 9.30

Unblocking (UBL)

0

0

0

1

0

1

0

0

		No parameters are given in the Unblocking message (UBL). This message is sent by an exchange to remove a blocking condition at a remoter exchange. The circuit being unblocked is indicated in the CIC field.

 

		Figure 9.31

Unblocking Acknowledgment (UBA)

0

0

0

1

0

1

1

0

		No parameters are given in the Unblocking Acknowledgment message (UBA). This message is sent to acknowledge receipt of the UBL. The acknowledgment also indicates that the circuit has been unblocked. The circuit is identified in the CIC field.

		Figure 9.32

Circuit Group Reset (GRS)	0	0	0	1	0	1	1	1
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0
Optional Parameters
Circuit assignment map	0	0	1	0	0	1	0	1

		This message is used to reset a group of voice circuits when the exchange no longer knows the status of the voice circuits. This could be the result of memory malfunction or some other error that caused it to lose track of the circuits status. The range parameter is used to identify the range of voice circuits to be reset. Any calls in progress or blocked conditions will be canceled and the voice circuits indicated released. However, they must go through diagnostics and alignment procedures (voice alignment, not SS7 alignment) before becoming available for calls again.

 

		Figure 9.33

Circuit Group Blocking (CGB)	0	0	0	1	1	0	0	0
Fixed Mandatory Parameters
Circuit group supervision message type indicator	0	0	0	1	0	1	0	1
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0

		This message is sent by maintenance personnel from an operations terminal to block voice circuits from being used for voice calls during maintenance routines. The voice circuits are manually busied until maintenance procedures are completed; at which point they must be unblocked manually. The circuit group supervision message type indicator parameter indicates what type of blocking to invoke, while the range and status indicate what range of circuits to block, and status indicates the status (blocked or unblocked) of the specified circuits.

		Figure 9.34

Circuit Group Unblocking (CGU)	0	0	0	1	1	0	0	1
Fixed Mandatory Parameters
Circuit group supervision message type indicator	0	0	0	1	0	1	0	1
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0

 

This message is sent by maintenance personnel from an operations terminal to unblock voice circuits that were previously blocked for maintenance purposes. The circuit group supervision message type indicator parameter indicates what type of unblocking to invoke, while the range and status indicate what range of circuits to unblock, and status indicates the status (blocked or unblocked) of the specified circuits while the range and status parameter shows the range of circuits that were blocked and their present status (blocked).

		Figure 9.35

Circuit Group Unblocking Acknowledgement (CGBA)	0	0	0	1	1	0	1	0
Fixed Mandatory Parameters
Circuit group supervision message type indicator	0	0	0	1	0	1	0	1
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0

		This message is used to acknowledge receipt of a circuit group blocking message, and indicates that the circuits have been blocked. The supervision message type indicator shows the type of blocking invoked while the range and status parameter shows the range of circuits that were blocked and their present status (blocked).

		Figure 9.36

 

Circuit Group Unblocking Ack (CGUA)	0	0	0	1	1	0	1	1
Fixed Mandatory Parameters
Circuit group supervision message type indicator	0	0	0	1	0	1	0	1
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0

		This message is used to acknowledge receipt of a circuit group unblocking message, and indicates that the circuits have been unblocked. The supervision message type parameter indicates the type of unblocking used while the range and status indicates the range of circuits that have been unblocked and the status of those circuits (unblocked).

		Figure 9.37

Call Modification Request (CMR)

0

0

0

1

1

1

0

0

		There are currently no procedures written for this in ANSI networks. This message is only found in ITU-TS networks.

		Figure 9.38

 

Call Modification Completed (CMC)

0

0

0

1

1

1

0

1

		There are currently no procedures written for this in ANSI networks. This message is only found in ITU-TS networks.

		Figure 9.39

Call Modification Reject (CMRJ)

0

0

0

1

1

1

1

0

		There are currently no procedures written for this in ANSI networks. This message is only found in ITU-TS networks.

		Figure 9.40

Facility Request (FAR)

0

0

0

1

1

1

1

1

		There are currently no procedures written for this in ANSI networks. This message is only found in ITU-TS networks.

 

		Figure 9.41

Facility Accepted (FAA)

0

0

1

0

0

0

0

0

		There are currently no procedures written for this in ANSI networks. This message is only found in ITU-TS networks.

		Figure 9.42

Facility Reject (FRJ)

0

0

1

0

0

0

0

1

		There are currently no procedures written for this in ANSI networks. This message is only found in ITU-TS networks.

		Figure 9.43

 

Loop Back Acknowledgment (LPA)

0

0

1

0

0

1

0

0

		No parameters are given in this message. This message is used to indicate that loop-back equipment has been connected in response to a CCR, and loop-back testing is being performed. The voice circuit identification is provided in the CIC field.

		Figure 9.44

Delayed Release (DRS)

0

0

1

0

0

1

1

1

		There are currently no procedures written for this in ANSI networks. This message is only found in ITU-TS networks.

		Figure 9.45

Pass Along (PAM)

0

0

1

0

1

0

0

0

		There are no specific parameters associated with this command, however, when the pass along message type is given, another message type is normally contained within (as if parameters). This allows a message to be routed to the exchange associated with the specified voice circuit connection so that information may be passed along using the same path as that used for the call setup messages.

 

		Figure 9.46

Circuit Group Reset Acknowledgment (GRA)	0	0	1	0	1	0	0	1
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0
Optional Parameters
Circuit assignment map	0	0	1	0	0	1	0	1

		This message is used to indicate receipt of a circuit group reset message. This message also indicates that the reset has been performed on the circuits identified in the range parameter. The status parameter indicates the current status of those circuits.

		Figure 9.47

Circuit Query (CQM)	0	0	1	0	1	0	1	0
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0
Optional Parameters
Circuit assignment map	0	0	1	0	0	1	0	1

		This message is sent to a distant exchange to learn the status of a range of voice circuits (blocked, unblocked). The range of voice circuits is specified in the range parameter, which normally also has a status subfield. However, the status information is not returned with this message, therefore the status field is not used (set to zeros). A circuit query response message (CQR) is used to inform the querying exchange the status information.

		Figure 9.48

Circuit Query Response (CQR)	0	0	1	0	1	0	1	1
Mandatory Variable Parameters
Range and status	0	0	0	1	0	1	1	0
Circuit state indicator	0	0	1	0	0	1	1	0

		The CQR is sent in response to a circuit query message (CQM), and provides the status of the specified voice circuits. The range of voice circuits is specified in the range parameter, while the status of those circuits is provided in the circuit state indicator. The status subfield of the range parameter is not used in this message (set to zeros).

		Figure 9.49

 

Call Progress (CPG)	0	0	1	0	1	1	0	0
Mandatory Fixed Parameters
Event information	0	0	1	0	0	1	0	0
Optional Parameters
Access transport	0	0	0	0	0	0	1	1
Backward call indicators	0	0	0	1	0	0	0	1
Business group	1	1	0	0	0	1	1	0
Call reference	0	0	0	0	0	0	0	1
Cause indicators	0	0	0	1	0	0	1	0
Information indicators	0	0	0	0	1	1	1	1
Network transport parameter	1	1	1	0	1	1	1	1
Notification indicator	1	1	1	0	0	0	0	1
Optional backward call indicators	0	0	1	0	1	0	0	1
Redirecting number	0	0	0	0	1	0	1	1
Remote operations	0	0	1	1	0	0	1	0
Service activation	0	0	1	1	0	0	1	1
Transmission medium used	0	0	1	1	0	1	0	1
User-to-user indicators	0	0	1	0	1	0	1	0
User-to-user information	0	0	1	0	0	0	0	0

		The call progress message is used to notify a distant exchange that some event has occurred during the progress of a call. The event is not a catastrophic event, or an error-related event, but a call-related event. The event information parameter indicates what type of event occurred (alerting message was received, the call was forwarded because of a busy, etc.) while the optional parameters provide additional support information required depending on the event.

		Figure 9.50

User-to-User Information (USR)

0

0

1

0

1

1

0

1

 

This message does not have any definition in ANSI networks, and is used only in international ITU-TS networks.

		Figure 9.51

Unequipped Circuit Identification Code (UCIC)

0

0

1

0

1

1

1

0

		There are no parameters in this message. This message is used to notify a distant exchange that is the originator of an ISUP Initial Address Message (IAM) that the CIC it has requested to be connected is not equipped. Upon receipt of this message, the exchange that originated the IAM must select a different CIC, while marking the first CIC as unavailable.

		Figure 9.52

Confusion (CFN)	0	0	1	0	1	1	1	1
Mandatory Variable Parameters
Cause indicators	0	0	0	1	0	0	1	0

		The confusion message indicates that the exchange has received a message it does not recognize, and it does not know how to handle the message. The confusion message is sent to the originator of the ISUP message. This only applies to ISUP messages, and does not apply to TCAP, SCCP, or any other protocol message other than ISUP. The cause indicators parameter indicates where the confusion message was originated, as well as why the message is being sent.

		Figure 9.53

Overload (OLM)

0

0

1

1

0

0

0

0

		This message is not supported in ANSI networks, and is used only in international ITU-TS networks.

		Figure 9.54

Charge Information (CRG)

0

0

1

1

0

0

0

1

		This message is not supported in ANSI networks, and is used only in international ITU-TS networks.

		Figure 9.55

 

Facility (FAC)	0	0	1	1	0	0	1	1
Optional Parameters
Remote operations	0	0	1	1	0	0	1	0
Service activation	0	0	1	1	0	0	0	0

		This message may be sent by either exchange, the local or the distant, to request an action at that exchange. The same message may also be used as an acknowledgment that the action was performed successfully. The service activation parameter indicates the type of service that is being requested (or has been invoked in the case of an acknowledgment). Call waiting is defined in the Bellcore standard, but all other codes are considered as network specific and are undefined in the standards.

		Figure 9.56

Circuit Reservation Acknowledgment (CRA)

1

1

1

0

1

0

0

1

		There are no parameters in this message. This is sent to an exchange after receipt of a CRM as an acknowledgment that the circuit has been reserved for a call. This message only applies when the circuit reservation procedure is incorporated.

		Figure 9.57

 

Circuit Reservation (CRM)	1	1	1	0	1	0	1	0
Mandatory Fixed Parameters
Nature of connection indicators	0	0	0	0	0	1	1	0

		This is used only interworking with a non-SS7 network, such as an analog network using MF signaling. This is typically the case in rural areas here in the U.S., although rural areas are quickly being converted to SS7 networks. Where SS7 is not available, the exchanges rely on conventional signaling methods (such as MF), which require special handling by the SS7 network. Circuit reservation allows the voice circuit to be reserved for a call. See the section on interworking earlier in this chapter to understand how this works. This procedure is only used in ANSI networks.

		Figure 9.58

Circuit Validation Response (CVR)	1	1	1	0	1	0	1	1
Mandatory Fixed Parameters
Circuit validation response indicator	1	1	1	0	0	1	1	0
Circuit group characteristic indicators	1	1	1	0	0	1	0	1
Optional Parameters
Circuit identification name (sending end)	1	1	1	0	1	0	0	0
COMMON LANGUAGETM Location Identification
Code (for the sending end)	1	1	1	0	1	0	0	1

		The circuit validation response message is sent in response to a circuit validation test message. The response message provides the results of the circuit validation test. The circuit validation test provides a way for maintenance personnel to check the translations at far-end exchanges and verify that when a new translation is entered, a CIC can be obtained by the exchange when establishing a new call, and that the physical port associated with that CIC can be seized. The response message will indicate whether this test passed or failed. This procedure is only used in ANSI networks.

		Figure 9.59

Circuit Validation Test (CVT)

1

1

1

0

1

1

0

0

		There are no parameters for this message. This message is used to initiate a translations test at a distant exchange. The circuit validation response message provides the results of the circuit validation test. The primary purpose of this test is to verify that new translations were entered properly, and a physical port can be connected between two exchanges.

		Figure 9.60

Exit (EXM)	1	1	1	0	1	1	0	1
Optional Parameters
Outgoing trunk group number	1	1	1	0	0	1	1	1

 

The Exit Message (EXM) is used only when interworking with another network. When an IAM is sent to a gateway to establish a connection in another network, the EXM is sent in the backward direction to indicate that the IAM has passed the gateway and is being forwarded to the other network.

		ISUP Parameters

		The previous section defined all the message types and their structures. Each of the parameters possible with any one message type was outlined, and the parameter name value provided. However, parameters contain additional information besides the parameter name.

		Because parameters can be used in multiple message types, it is easier to list them all here in alphabetical order. In this section, all parameters for both ANSI and ITU-TS are listed, along with illustrations showing the message structure of each parameter. To find this information in any of the standards publications you would have to refer to several sections, because of the way the information is segregated. All of the information regarding parameters has been grouped here in one section for easy reference.

		Access Transport

		The access transport parameter provides the parameters per the ANSI T1.607 standard. The method of transport parameter is found in the IAM message as well as the ACM.

Automatic Congestion Level	H	G	F	E	D	C	B	A
Spare	0	0	0	0	0	0	0	0
Automatic Congestion Level 1	0	0	0	0	0	0	0	1
Automatic Congestion Level 2	0	0	0	0	0	0	1	0
Automatic Congestion Level 3	0	0	0	0	0	0	1	1
Spare	0	0	0	0	0	1	0	0
				to
	1	1	1	1	1	1	1	1

		This is an optional parameter that may be sent in a release message (REL) to indicate the level of congestion at the originating exchange. The meanings of the levels indicated are implementation dependent. The action taken by the receiving exchange is also

implementation dependent. This parameter simply provides an alerting mechanism to show some level of congestion exists in another exchange.

Backward Call Indicators

H

G

F

E

D

C

B

A

First Octet

Charge Indicators

		No indication

0

0

		No charge

0

1

		*Charge

1

0

		Spare

1

1

Called party's status indicator

		No indication

0

0

		Subscriber free

0

1

		*Connect when free

1

0

		Excessive delay

1

1

Called party's category indicator

		No indication

0

0

		Ordinary subscriber

0

1

		*Payphone

1

0

		Spare

1

1

End-to-end method indicator

		No end-to-end method available

0

0

		Pass Along method available

0

1

		SCCP method available

1

0

		Pass Along and SCCP methods available

1

1

		Second Octet

		H

		G

		F

		E

		D

		C

		B

		A

Interworking indicator

		No interworking encountered

0

		Interworking encountered

1

IAM Segmentation Indicator

		No indication

0

		Additional info has been received and added to IAM

1

ISDN User Part Indicator

		ISUP not used all the way (end to end)

0

		ISUP used all the way (end to end)

1

Holding Indicator

		Holding not required

0

		*Holding required

1

ISDN Access Indicator

		Terminating access non-ISDN

0

		Terminating access ISDN

1

Second Octet

H

G

F

E

D

C

B

A

Echo Control Device Indicator

		Incoming half echo control device not included

0

		Incoming half echo control device included

1

SCCP Method Indicator

		No indication

0

0

		*Connectionless method available

0

1

		*Connection-oriented method available

1

0

		*Connectionless and connection-oriented available

1

1

		The backward call indicators parameter is sent in the backward direction (back to the originating exchange) to provide information regarding charging, status of the called party, and various other forms of information which may be needed to complete processing of a call.

		The charge indicator indicates whether or not the call is a chargeable call. If the call is chargeable, then the number to which the call is to be charged is also provided. The status parameter indicates whether or not the called party is available. If not, then no indication is given in the charge field and the calling party is returned a busy tone.

		The category indicator indicates which category (pay phone, etc.) the called party fits. This information is used during call processing and may imply special handling of the call (for example, a pay phone may require special handling for billing and operator assistance).

		The end-to-end indicator is used by the protocol to designate the method of ISUP signaling available for this call. The protocol can then use this information to make a decision as to which method will be used. In ANSI networks the pass along method is most widely used. The SCCP method is not supported in ANSI networks.

		Interworking encountered means that another signaling system other than SS7 will be encountered for this call. For example, an exchange may still be using MF signaling, and is needed to complete the path for this call. In this case, the SS7 interworking procedures discussed early in this chapter will have to be used.

		The ISUP indicator will tell whether or not ISUP is used through all segments of the network involved with this call. If this field shows that ISUP is used all the way, then there will be no interworking encountered, and vice versa.

		This parameter also indicates if ISDN is the interface to the subscriber or not. If ISDN is the subscriber interface, then special handling is required at the interface to signal the subscriber being

called. There is direct mapping for SS7 signaling to ISDN, as the ISDN protocol was developed as an extension of SS7.

		Echo cancelers are indicated in the echo control device indicator. This information may be used by the originating switch when encoding voice signals to prevent original signals from being mistaken for noise, and may trigger special digitization of the voice.

		The last field is the SCCP method indicator, which indicates the type of SCCP method available for this call. Since SCCP services are not supported with ISUP in ANSI networks, this should only be found in private and international networks.

Business Group

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Party Selector

		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

		Spare

0

1

1

0

to

Line privilege information indicator

1

1

1

1

		Fixed line privileges

0

		Customer defined line privileges

1

Business group identifier type

		Multilocation business group identifier

0

		Interworking with private networks identifier

1

Attendant status

		No indication

0

		Attendant line

1

		Spare

0

		Octets 2, 3, and 4

		H

		G

		F

		E

		D

		C

		B

		A

Business group identifier

		No indication

0

0

0

0

0

0

0

0

		Public network

0

0

0

0

0

0

0

1

		Network dependent

0

0

0

0

0

0

1

0

to

1

1

1

1

1

1

1

1

		Binary representation of the actual number assigned may be three octets long.

 

Octets 5 and 6

H

G

F

E

D

C

B

A

Subgroup identifier

		No subgroups

0

0

0

0

0

0

0

0

		All other values represent the number assigned to any subgroups and may be two octets long.

Octet 7

H

G

F

E

D

C

B

A

If line privileges information indicator = 0

Terminating line privileges

		Unrestricted

0

0

0

0

		Semirestricted

0

0

0

1

		Fully restricted

0

0

1

0

		Fully restricted, intra-switch

0

0

1

1

		Denied

0

1

0

0

		Spare

0

1

0

1

to

1

1

1

1

Originating restrictions

		Unrestricted

0

0

0

0

		Semirestricted

0

0

0

1

		Fully restricted

0

0

1

0

		Fully restricted, intra switch

0

0

1

1

		Denied

0

1

0

0

		Spare

0

1

0

1

to

1

1

1

1

If line privileges information indicator = 1

Customer defined line privilege codes

0

0

0

0

0

0

0

0

to

1

1

1

1

1

1

1

1

		The business group parameter identifies the properties of a group of subscriber lines that belong to a common subscriber (such as Centrex services). The business group is assigned specific features and restrictions, which must be identified through the protocol during call setup and information sharing between exchanges.

		The party indicator identifies the type of number, called or calling, original called (in the case of forwarded numbers), and connected numbers. The fixed line privileges indicates the type of restrictions to be applied, those already defined (fixed) by the protocol, or those defined by the customer.

		The business group identifier indicates whether the business group is one of multiple locations or if the group requires inter-

working with a private network. The attendant status is also indicated when the business group attendant places calls through the network.

		The business group identifier and subgroup identifiers are the actual numbers assigned to these groups by the network provider. The service provider allocates the business group numbers.

		Call Reference

		The call reference is a number assigned to a call for tracking of messages and for use as a reference for additional information exchanged between two offices during the duration of the call. The first octet is the call identity number, which uniquely identifies each call. The number is of local significance only. The second octet bears the point code that assigned the call identity number. The point code indicated would be the only point code for which the identity number is of any significance.

Called Party Number

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

nature of address indicator

		Spare

0

0

0

0

0

0

0

		Subscriber number

0

0

0

0

0

0

1

		Spare, reserved for national use

0

0

0

0

0

1

0

		National significant number

0

0

0

0

0

1

1

		International number

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

to

1

1

1

0

0

0

0

		Subscriber number, operator requested

1

1

1

0

0

0

1

		National number, operator requested

1

1

1

0

0

1

0

		International number, operator requested

1

1

1

0

0

1

1

		No number present, operator requested

1

1

1

0

1

0

0

		No number present, cut-through call to carrier

1

1

1

0

1

0

1

		950 + call from local exchange carrier public station, hotel/motel, or nonexchange access end-office

1

1

1

0

1

1

0

		Test line code

1

1

1

0

1

1

1

		Reserved for network specific use

1

1

1

1

0

0

0

to

1

1

1

1

1

1

0

		Spare

1

1

1

1

1

1

1

 

Octet 1

H

G

F

E

D

C

B

A

Odd/even bits

		Even number of address signals

0

		Odd number of address signals

1

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Reserved

0

0

0

0

		Numbering Plan

		Unknown numbering plan

0

0

0

		ISDN numbering plan (Rec. E.164, E.163)

0

0

1

		Spare

0

1

0

		Reserved ITU-TS Data Numbering Plan

0

1

1

		Reserved ITU-TS Telex Numbering Plan

1

0

0

		Private numbering plan

1

0

1

		Spare

1

1

0

		Spare

1

1

1

Spare

0

		Octets 3-n

		H

		G

		F

		E

		D

		C

		B

		A

Address Signal 1st address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Address Signal 2nd address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		Digit 4

0

1

0

0

		Digit 5

0

1

0

1

		Digit 6

0

1

1

0

		Digit 7

0

1

1

1

 

Octets 3-n

H

G

F

E

D

C

B

A

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

End of pulse signal

1

1

1

1

		The called party address can be as large as needed to accommodate the dialed digits. The previous list only defines the first three octets, although the actual parameter will be larger. Each of the dialed digits uses 4 bits, as shown. The purpose of this parameter is to provide the distant exchange the number of the called party (dialed digits), or the location routing number (LRN) associated with the called party. This parameter can be used in a number of message types, and is usually used when establishing a connection from one exchange to another. If the dialed digits are to a ported number, the nature of address indicator will indicate a ported number. If this parameter contains the LRN to be used for routing, the dialed digits are placed in the GAP parameter.

Calling Party Number

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Nature of address indicator

		Spare

0

0

0

0

0

0

0

		Unique subscriber number

0

0

0

0

0

0

1

		Spare, reserved for national use

0

0

0

0

0

1

0

		Unique national significant number

0

0

0

0

0

1

1

		Unique international number

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

to

1

1

1

0

0

0

0

		Non-unique subscriber number

1

1

1

0

0

0

1

		Spare, reserved for national use

1

1

1

0

0

1

0

		Non-unique national number

1

1

1

0

0

1

1

		Non-unique international number

1

1

1

0

1

0

0

		Spare

1

1

1

0

1

0

1

		Spare

1

1

1

0

1

1

0

		Test line code

1

1

1

0

1

1

1

		Reserved for network-specific use

1

1

1

1

0

0

0

to

1

1

1

1

1

1

0

Spare

1

1

1

1

1

1

1

 

Octet 1

H

G

F

E

D

C

B

A

Odd/even indicator

		Even number of address signals

0

		Odd number of address signals

1

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Screening

		Reserved (for user provided, not screened)

0

1

		User provided, screening passed

1

0

		Network provided

1

1

Address Presentation

		Presentation allowed

0

0

		Presentation restricted

0

1

		Spare

1

0

		Spare

1

1

Numbering Plan

		Unknown numbering plan

0

0

0

		ISDN numbering plan (Rec. E.164, E.163)

0

0

1

		Spare

0

1

0

		Reserved ITU-TS Data Numbering Plan

0

1

1

		Reserved ITU-TS Telex Numbering Plan

1

0

0

		Private numbering plan

1

0

1

		Spare

1

1

0

		Spare

1

1

1

Spare

0

		Octets 3 n

		H

		G

		F

		E

		D

		C

		B

		A

Address Signal 1st address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Address Signal 2nd address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

 

Octets 3 n

H

G

F

E

D

C

B

A

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

		The calling party's address is much the same as the called party's address, for the exception of the second octet. Some differences also exist in the nature of address indicator.

		The screening indicator is used to indicate who provided the dialed digits in the address. The digits could have been provided by the subscriber (originating party) or by the network (global title translation). The purpose of this parameter is to provide a means for the network to determine the origin of the digits and whether or not this number is viewed by the network as the true called party number or as an alias. In the case of ported numbers, the parameter will not contain the LRN of the calling party. The LRN of the calling party is found in the JIP parameter.

		The address presentation parameter serves the same purpose as in the calling party address. The default for this parameter is to be ''presentation restricted." The presentation of the dialed digits allows called parties to identify who is calling them (caller party ID). When presentation is restricted, the number can still be presented to another network, but it is restricted from presentation to an end user.

Calling Party's Category	H	G	F	E	D	C	B	A
Calling party's category unknown (default)	0	0	0	0	0	0	0	0
*French language operator	0	0	0	0	0	0	0	1
*English language operator	0	0	0	0	0	0	1	0
*German language operator	0	0	0	0	0	0	1	1
*Russian language operator	0	0	0	0	0	1	0	0
*Spanish language operator	0	0	0	0	0	1	0	1
Reserved for network-dependent language selection	0	0	0	0	0	1	1	0
	0	0	0	0	0	1	1	1
	0	0	0	0	1	0	0	0

Calling Party's Category	H	G	F	E	D	C	B	A
National networks operator service	0	0	0	0	1	0	0	1
Ordinary calling subscriber	0	0	0	0	1	0	1	0
*Calling subscriber with priority	0	0	0	0	1	0	1	1
*Data call (voiceband data)	0	0	0	0	1	1	0	0
Test call	0	0	0	0	1	1	0	1
Spare	0	0	0	0	1	1	1	0
*Pay phone	0	0	0	0	1	1	1	1
Spare (ITU-TS)	0	0	0	1	0	0	0	0
				to
	1	1	0	1	1	1	1	1
Emergency service call in progress	1	1	1	0	0	0	0	0
High-priority call indication	1	1	1	0	0	0	0	1
National Security & Emergency Preparedness Call	1	1	1	0	0	0	1	0
Spare (ANSI)	1	1	1	0	0	0	1	1
				to
	1	1	1	0	1	1	1	1
Network-specific use	1	1	1	1	0	0	0	0
				to
	1	1	1	1	1	1	1	0
Reserved for expansion	1	1	1	1	1	1	1	1

		The calling party's category indicates the type of subscriber originating the call. In the case of a special-language operator, the originator of the call (the operator services) will require special handling. The same is true of the pay phone, which may require special operator assistance.

		The test call indicator in this parameter is used for remote testing of translations (as discussed earlier in this chapter). A technician may initiate a test call from a remote maintenance center terminal to test and verify newly added translations or routing information. The IAM would then include the calling party's category parameter with the test call value.

Carrier Identification

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Network identification plan

		Unknown

0

0

0

0

		3-digit carrier identification code

0

0

0

1

		4-digit carrier identification code

0

0

1

0

		Spare

0

0

1

1

to

1

1

1

1

Type of network identification

0

0

0

		Spare

0

0

0

		Spare

0

0

1

		National network identification

0

1

0

 

Octet 1

H

G

F

E

D

C

B

A

		Spare

0

1

1

to

1

1

1

Spare

0

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Digit one

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

End of pulse signal

1

1

1

1

Digit Two

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

End of pulse signal

1

1

1

1

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

Digit Three

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

Octet 3

H

G

F

E

D

C

B

A

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Digit Four (if four-digit code is used)

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

End of pulse signal

1

1

1

1

		Carrier Selection Information

		H

		G

		F

		E

		D

		C

		B

		A

Carrier selection information

		No indication (default)

0

0

0

0

0

0

0

0

		Subscribers designated (preselected) carrier

0

0

0

0

0

0

0

1

		Subscribers designated carrier as input by caller

0

0

0

0

0

0

1

0

		Subscribers designated carrier (undetermined)

0

0

0

0

0

0

1

1

		Carrier designated by caller at time of call

0

0

0

0

0

1

0

0

		Spare

0

0

0

0

0

1

0

1

to

1

1

1

1

1

1

1

0

		Reserved

1

1

1

1

1

1

1

1

		The carrier identification parameter is used to identify the carrier selected by the caller. The selection can be accomplished in one of several ways. All subscribers have preselected carriers listed in the Line Information Database (LIDB) as a part of their customer

record. This is the carrier to be used for all long-distance calls, except when another carrier is selected manually.

		Any carrier can be selected by dialing the carrier access code. The carrier access code is the 10xxx number assigned to all long-distance carriers. This number allows a caller to use any long distance provider for that call. After the call is finished the next call defaults back to the preselected carrier.

		A subscriber may also be calling from a pay phone or some other phone where a long-distance carrier has not been preselected, but the caller has entered in a 10xxx code for carrier selection. This is a rarity in U.S. networks, as equal access has required that all subscribers have a designated carrier preselected for every line.

Cause Indicators

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Location

		User

0

0

0

0

		Local private network

0

0

0

1

		Local public network

0

0

1

0

		Transit network

0

0

1

1

		Remote local network

0

1

0

0

		Remote private network

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

1

0

Spare

0

Coding Standard

		ITU-TS Standard (default)

0

0

		Reserved for other international standards

0

1

		ANSI standard

1

0

		Reserved

1

1

Extension Bit

		Parameter continues to next octet

0

		Last octet

1

		Octet 2

		The cause value provides the reason for the message failure. These cause codes are grouped as ITU-TS and ANSI codes. All cause codes are divided into two parts; bits ABCD represent the cause while bits EFG represent the class.

ITU-TS cause codes (coding standard 0 0)

Class 0 0 0 and 0 0 1, normal event

H

G

F

E

D

C

B

A

		Unallocated (unassigned) number

0

0

0

0

0

0

1

		No route to specified transit network

0

0

0

0

0

1

0

		No route to destination

0

0

0

0

0

1

1

Class 0 0 0 and 0 0 1, normal event

H

G

F

E

D

C

B

A

		Send special information tone

0

0

0

0

1

0

0

		*Misdialed trunk prefix

0

0

0

0

1

0

1

		Preemption

0

0

0

1

0

0

0

		Preemption-circuit reserved for reuse

0

0

0

1

0

0

1

		Normal clearing

0

0

1

0

0

0

0

		User busy

0

0

1

0

0

0

1

		No user responding

0

0

1

0

0

1

0

		No answer from user (user alerted)

0

0

1

0

0

1

1

		Subscriber absent

0

0

1

0

1

0

0

		Call rejected

0

0

1

0

1

0

1

		Number changed

0

0

1

0

1

1

0

		Redirect to new destination

0

0

1

0

1

1

1

		Destination out of order

0

0

1

1

0

1

1

		Address incomplete

0

0

1

1

1

0

0

		Facility rejected

0

0

1

1

1

0

1

		Normal-unspecified (default)

0

0

1

1

1

1

1

		Class 0 1 0, resource unavailable

		H

		G

		F

		E

		D

		C

		B

		A

		No circuit/channel available

0

1

0

0

0

1

0

		Network out of order

0

1

0

0

1

1

0

		Temporary failure

0

1

0

1

0

0

1

		Switching equipment congestion

0

1

0

1

0

1

0

		Access information discarded

0

1

0

1

0

1

1

		Requested circuit/channel not available

0

1

0

1

1

0

0

		Precedence call blocked

0

1

0

1

1

1

0

		Resource unavailable-unspecified (default)

0

1

0

1

1

1

1

		Class 0 1 1, service or option not available

		H

		G

		F

		E

		D

		C

		B

		A

		Requested facility not subscribed

0

1

1

0

0

1

0

		*Outgoing calls barred within Closed User Group

0

1

1

0

1

0

1

		*Incoming calls barred within Closed User Group

0

1

1

0

1

1

1

		Bearer capability not authorized

0

1

1

1

0

0

1

		Bearer capability not presently available

0

1

1

1

0

1

0

		Inconsistency in designated outgoing access and subscriber class

0

1

1

1

1

1

0

		Service option not available-unspecified (default)

0

1

1

1

1

1

1

		Class 1 0 0, service or option not

		H

		G

		F

		E

		D

		C

		B

		A

		implemented

		Bearer capability not implemented

1

0

0

0

0

0

1

		Requested facility not implemented

1

0

0

0

1

0

1

		Only restricted digital info bearer capability available

1

0

0

0

1

1

0

		Service not implemented-unspecified (default)

1

0

0

1

1

1

1

Class 1 0 1, invalid message

H

G

F

E

D

C

B

A

		*User not member of Closed User Group

1

0

1

0

1

1

1

		Incompatible destination

1

0

1

1

0

0

0

		*Nonexistent Closed User Group

1

0

1

1

0

1

0

		Invalid transit network selection

1

0

1

1

0

1

1

		Invalid message, unspecified (default)

1

0

1

1

1

1

1

		Class 1 1 0, protocol error (i.e., unknown message)

		H

		G

		F

		E

		D

		C

		B

		A

		Message type nonexistent or not implemented

1

1

0

0

0

0

1

		Information element parameter nonexistent/not implemented

1

1

0

0

0

1

1

		Recovery on timer expiration

1

1

0

0

1

1

0

		Parameter nonexistent/not implemented-passed on

1

1

0

0

1

1

1

		Message with unrecognized parameter discarded

1

1

0

1

1

1

0

		Protocol error, unspecified (default)

1

1

0

1

1

1

1

		Class 1 1 1, interworking class

		H

		G

		F

		E

		D

		C

		B

		A

		Interworking, unspecified (default)

1

1

1

1

1

1

1

		ANSI cause codes (coding standard 1 0)

		Class 0 0 0 and 0 0 1, normal event

		H

		G

		F

		E

		D

		C

		B

		A

		Unallocated destination number

0

0

1

0

1

1

1

		Unknown business group

0

0

1

1

0

0

0

		Exchange routing error

0

0

1

1

0

0

1

		Misrouted call to a ported number

0

0

1

1

0

1

0

		Number portability Query on Release (QoR) number not found

0

0

1

1

0

1

1

		Class 0 1 0, resource unavailable

		Preemption

0

1

0

1

1

0

1

		Precedence call blocked

0

1

0

1

1

1

0

		Class 0 1 1, service or option not available

		H

		G

		F

		E

		D

		C

		B

		A

		Call type incompatibility with service request

0

1

1

0

0

1

1

		Call blocked due to group restrictions

0

1

1

0

1

1

0

Extension Bit

0

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

Diagnostics (if applicable)

0

0

0

0

0

0

0

0

		The diagnostics field is dependent on the cause value. Not all cause codes will require a diagnostics field afterward. The diagnostic field uses the same format as the specified parameters (i.e., called party number). The following lists the cause codes that generate a diagnostics field, and the parameter structure used for the diagnostic value.

 

Cause Code

Diagnostic

Structure

0

0

1

0

1

1

0

Called party number (new)

See called party parameter

0

1

0

0

1

1

0

Transit network identity

Transit network selection

0

1

0

1

0

1

0

Transit network identity

Transit network selection

0

1

1

1

0

0

1

Attribute identity

See below

0

1

1

1

0

1

0

Attribute identity

See below

1

0

0

0

0

0

1

Attribute identity

See below

		Attribute identity

		H

		G

		F

		E

		D

		C

		B

		A

		Information transfer capability

0

1

1

0

0

0

1

		Information transfer mode

0

1

1

0

0

1

0

		Information transfer rate

0

1

1

0

0

1

1

		Structure

0

1

1

0

1

0

0

		Configuration

0

1

1

0

1

0

1

		Establishment

0

1

1

0

1

1

0

		Symmetry

0

1

1

0

1

1

1

		Information transfer rate (destination to origination)

0

1

1

1

0

0

0

		Layer identification and corresponding user info

0

1

1

1

0

0

1

		This rather lengthy parameter is full of variables, and is dependent on the cause as to the full contents of the parameter. The parameter can be found in REL, Address Complete Messages (ACM), or Confusion messages (CON). The purpose is to identify the cause for the failure or disconnect or message rejection. Appendix C provides full explanations for all cause codes and diagnostics, to save space here.

Charge Number

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Nature of address indicator

		Spare

0

0

0

0

0

0

0

		ANI of the calling party; subscriber number

0

0

0

0

0

0

1

		ANI not available or not provided

0

0

0

0

0

1

0

		ANI of the calling party; national number

0

0

0

0

0

1

1

		Spare

0

0

0

0

1

0

0

		ANI of the called party; subscriber number

0

0

0

0

1

0

1

		ANI of the called party; no number present

0

0

0

0

1

1

0

		ANI of the called party; national number

0

0

0

0

1

1

1

		Spare

0

0

0

1

0

0

0

to

1

1

1

0

1

1

1

Octet 1

H

G

F

E

D

C

B

A

		Reserved for network-specific use

1

1

1

1

0

0

0

to

1

1

1

1

1

1

0

		Spare

1

1

1

1

1

1

1

Odd/Even bit

		Even number of address signals

0

		Odd number of address signals

1

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Reserved

0

0

0

0

		Numbering plan

		Unknown

0

0

0

		ISDN numbering plan (Rec E.164, E.163)

0

0

1

		Spare

0

1

0

		Reserved (ITU data numbering plan)

0

1

1

		Reserved (ITU Telex numbering plan)

1

0

0

		Private numbering plan

1

0

1

		Spare

1

1

0

		Spare

1

1

1

Spare

0

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

1st address signal

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

2nd address signal

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

Octet 3

H

G

F

E

D

C

B

A

		Digit 9

1

0

0

1

		Spare

1

0

1

0

		Code 11

1

0

1

1

		Code 12

1

1

0

0

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

		Circuit Assignment Map

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Map Type

		Spare

0

0

0

0

0

0

		DS1 map format

0

0

0

0

0

1

		Spare

0

0

0

0

1

0

to

1

1

1

1

1

1

Spare

0

0

		Octets 2-4

		H

		G

		F

		E

		D

		C

		B

		A

Map

x

x

x

x

x

x

x

x

		0 = 64-kbps circuit is not used

		1 = 64-kbps circuit is used

		The map portion of this parameter provides a 1-bit representation for each circuit. If the value of the circuit bit is a 1, then the 64-kbps circuit is used. If the value is a 0, it is not used. Up to 24 circuits may be represented in the map fields. All 24 circuits are represented, but set to 0 if the circuits are not used. This means that this parameter is always a fixed length and not variable.

		This parameter is only used when DS0 circuits that are not contiguous are used. Noncontiguous means that a full DS1 is not being utilized for these circuits. There may be a partial DS1 or the various DS0s may be split between multiple DS1s. Either way, the map indicates which circuits are or are not used within a DS1.

Circuit Group Supervision Msg Type Indicator

H

G

F

E

D

C

B

A

Circuit group blocking type indicator

		Block without release

0

0

		Block with immediate release

0

1

		Reserved for national use

1

0

		Spare

1

1

Spare

0

0

0

0

0

0

		This parameter provides instructions to another exchange on the method of circuit blocking to be implemented on the designated circuit. Blocking allows craft personnel to perform tests on a circuit without the change of the circuit being seized for another call.

		There are two methods of blocking, blocking with a release (which disconnects any call in progress) and blocking without release (which will not send a release message through the network).

Circuit Identification Name
Octet 1	H	G	F	E	D	C	B	A
Trunk number (first digit)		x	x	x	x	x	x	x
Spare	0
Octets 2-4	H	G	F	E	D	C	B	A
Trunk number (digits two through four)		x	x	x	x	x	x	x
Spare	0
Octet 5	H	G	F	E	D	C	B	A
CLLI code-office A		x	x	x	x	x	x	x
Spare	0
Octets 6-26	H	G	F	E	D	C	B	A
CLLI code-office Z		x	x	x	x	x	x	x
Spare	0

		The circuit identification name parameter is used to identify to a distant exchange the CLLI of a specific trunk. This parameter is coded using IA5 characters, with each character using one octet.

		Office A is designated as follows:

		If the trunk is a one-way trunk group, then the office which originates the calls for this trunk is office A.

		If the trunk is a two-way trunk, the office with the lower alphanumeric CLLI code is office A.

		The same rules apply to subgroups that can be one-way or two-way trunks. This parameter allows two exchanges to exchange information regarding their identity for usage in routing tables.

Circuit State Indicator	H	G	F	E	D	C	B	A
Transient	0	0	0	0	0	0	0	0
Spare	0	0	0	0	0	0	0	1
Spare	0	0	0	0	0	0	1	0
Unequipped	0	0	0	0	0	0	1	1
Incoming circuit busy, active	0	0	0	0	0	1	0	0
Incoming circuit busy, locally blocked	0	0	0	0	0	1	0	1
Incoming circuit busy, remotely blocked	0	0	0	0	0	1	1	0
Incoming circuit busy, locally and remotely blocked	0	0	0	0	0	1	1	1
Outgoing circuit busy, active	0	0	0	0	1	0	0	0

 

Circuit State Indicator	H	G	F	E	D	C	B	A
Outgoing circuit busy, locally blocked	0	0	0	0	1	0	0	1
Outgoing circuit busy, remotely blocked	0	0	0	0	1	0	1	0
Outgoing circuit busy, locally and remotely blocked	0	0	0	0	1	0	1	1
Idle	0	0	0	0	1	1	0	0
Idle, locally blocked	0	0	0	0	1	1	0	1
Idle, remotely blocked	0	0	0	0	1	1	1	0
Idle, locally and remotely blocked	0	0	0	0	1	1	1	1
Spare	0	0	0	1	0	0	0	0
				to
	1	1	1	1	1	1	1	1

		This parameter allows exchanges to send status information regarding specific trunk circuits, providing the status of the circuit in the distant exchange's perspective. The circuit identification code is carried in the field after the routing label.

		This parameter may be from one octet up to n octets in length. There may be situations when a two-way trunk will have more than one status indicator. For example, a two-way trunk can be incoming circuit busy, active, while also being outgoing circuit busy, locally blocked.

Circuit Validation Response Indicator	H	G	F	E	D	C	B	A
Successful	0	0	0	0	0	0	0	0
Failure (default)	0	0	0	0	0	0	0	1
Spare	0	0	0	0	0	0	1	0
				to
	1	1	1	1	1	1	1	1

		The circuit validation response indicator provides the results of a circuit validation in response to a distant exchange request.

COMMON LANGUAGE^TM Location Identifier (CLLI)

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Town (1st character)

0

0

0

0

0

0

0

Spare

0

Octets 2-4

H

G

F

E

D

C

B

A

Town (characters two through four)

x

x

x

x

x

x

x

Spare

0

Octet 5

H

G

F

E

D

C

B

A

State (1st character)

x

x

x

x

x

x

x

Spare

0

Octet 6	H	G	F	E	D	C	B	A
State (2nd character)		x	x	x	x	x	x	x
Spare	0
Octet 7	H	G	F	E	D	C	B	A
Building (1st character)		x	x	x	x	x	x	x
Spare	0
Octet 8	H	G	F	E	D	C	B	A
Building (2nd character)		x	x	x	x	x	x	x
Spare	0
Octet 9	H	G	F	E	D	C	B	A
Building subdivision (1st character)		x	x	x	x	x	x	x
Spare	0
Octet 10	H	G	F	E	D	C	B	A
Building subdivision (2nd character)		x	x	x	x	x	x	x
Spare	0
Octet 11	H	G	F	E	D	C	B	A
Building subdivision (3rd character)		x	x	x	x	x	x	x
Spare	0

		The COMMON LANGUAGETM Location Identifier (CLLI) parameter is used during circuit validation to identify an exchange. All signaling points in the ANSI SS7 network must have a CLLI code. This provides the means for identifying by location where a particular signaling point is located. A typical CLLI may look like ''RLGHNCXA03W." All characters are IA5 characters.

		Connection Request

		The connection request parameter is sent in the forward direction for the SCCP function. This allows the ISUP protocol to establish an end-to-end connection on which the SCCP may send TCAP or ISUP messages (if ISUP is using the service of SCCP).

		The local reference number (LRN) is the number assigned for the specific call, and is used as a reference in the originating exchange. The LRN allows the exchange to monitor all messages and associate them to their proper calls.

		The protocol class field identifies the protocol class to be used on this end-to-end connection. The protocol class is directly related to the SCCP protocol (refer to the chapter on SCCP for more details on protocol class). The protocol class specifies whether or not the services on this connection are to be connection-oriented or connectionless.

 

The credit field is used for changing the window size of the exchange during the connection. This is only valid if class 3 or 4 is specified (connection-oriented services).

Continuity Indicators

H

G

F

E

D

C

B

A

Continuity indicator

		Continuity check failed

0

		Continuity check successful

1

Spare

0

0

0

0

0

0

0

		The continuity indicator parameter indicates whether or not a continuity test was successful or not. The continuity check may be requested by an originating exchange according to predetermined criteria. The criteria for conducting a continuity check are found in the continuity check requirements indicator field of the circuit group characteristic indicator parameter.

		Egress Service

		This parameter is used to send network-specific information regarding a terminating exchange such as the interexchange carrier, the type of terminating access service, and the point of interconnection. This information is sent in the forward direction by the first incoming exchange to the terminating exchange.

End of Optional Parameter Fields Indicator	H	G	F	E	D	C	B	A
End of optional parameters	0	0	0	0	0	0	0	0

		The end of optional parameters parameter is the last octet in a message containing any optional parameters.

Event information

H

G

F

E

D

C

B

A

Event indicator

		Spare

0

0

0

0

0

0

0

		ALERTing

0

0

0

0

0

0

1

		PROGress

0

0

0

0

0

1

0

		In-band info or appropriate pattern now available

0

0

0

0

0

1

1

		*Call forwarded on busy

0

0

0

0

1

0

0

		*Call forwarded on no reply

0

0

0

0

1

0

1

		*Call forwarded unconditional

0

0

0

0

1

1

0

		Call deflected

0

0

0

0

1

1

1

		Notification for supplementary service

0

0

0

1

0

0

0

		Spare

0

0

0

1

0

0

1

to

1

1

0

1

1

1

0

 

Event information

H

G

F

E

D

C

B

A

		Service information included

1

1

0

1

1

1

1

		Spare

1

1

1

0

0

0

0

to

1

1

1

1

1

1

0

		Reserved

1

1

1

1

1

1

1

		H

		G

		F

		E

		D

		C

		B

		A

Event presentation restricted indicator (restrict)

		No indication

0

		Presentation restricted

1

Forward Call Indicators

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Incoming international call indicator

		Not an incoming international call

0

		Incoming international call

1

		H

		G

		F

		E

		D

		C

		B

		A

End-to-end method indicator

		No end-to-end method available

0

0

		Pass along method available

0

1

		SCCP method available

1

0

		Pass along and SCCP methods available

1

1

		H

		G

		F

		E

		D

		C

		B

		A

Interworking indicator

		No interworking encountered (SS7 all the way)

0

		Interworking encountered

1

		H

		G

		F

		E

		D

		C

		B

		A

IAM segmentation indicator

		No indication

0

		Additional info being sent by unsolicited info msg

1

		H

		G

		F

		E

		D

		C

		B

		A

ISDN User Part indicator

		ISUP not used all the way

0

		ISUP used all the way

1

		H

		G

		F

		E

		D

		C

		B

		A

ISDN User Part preference indicator

		ISUP preferred all the way (default)

0

0

		ISUP not required all the way ISUP required

0

1

		all the way

1

0

		Spare

1

1

Octet 2

H

G

F

E

D

C

B

A

ISDN access indicator

		Originating access non-ISDN

0

		Originating access ISDN

1

		H

		G

		F

		E

		D

		C

		B

		A

SCCP method indicator

		No indication

0

0

		*Connectionless method available

0

1

		*Connection-oriented method available

1

0

		*Connectionless and connection-oriented available

1

1

Spare

0

		H

		G

		F

		E

Ported number translation indicator

		Number not translated

0

		Number translated

1

		No QoR routing attempt in progress

0

		QoR routing attempt in progress

1

		Reserved for national use

0

0

		The forward call indicators are sent with an IAM to alert the distant exchange of the services required for the call. The international call indicator identifies international calls that have entered through a gateway STP. Without this indicator, it would be difficult for the distant exchange to know if the call was international (mapping of the dialed digits to a conversion table would be necessary).

		In addition to identifying international calls, the type of end-to-end signaling method available is also indicated through the end-to-end method indicator. This field identifies the method of signaling available for use; pass along method, SCCP method, or both are available. In U.S. networks, only the pass along method is currently supported.

		The interworking indicator identifies any networks encountered along the way which are not SS7 networks. The location of this network is not provided (as that is of no importance). The distant exchange only needs to be aware of its existence.

		The IAM segmentation indicator shows when an IAM has been divided into separate messages, because of length or any other reason. IAM information can be sent in an additional signal unit after the initial IAM.

		The ISUP indicators are used to indicate whether or not ISUP is used end to end, whether it is required end to end, and whether or not the subscriber interface at the originating exchange is ISDN.

		An SCCP indicator is also provided for those networks using the services of SCCP for supporting the ISUP. SCCP method of end-to-end signaling is not supported in U.S. networks.

 

The ported number translation indicator is used with the LNP application. It is used to indicate when a specific number has been looked up in the LNP database, to prevent unnecessary queries.

Generic Address Parameter

		Octet

		H

		G

		F

		E

		D

		C

		B

		A

Type of address

x

x

x

x

x

x

x

x

		Dialed number

0

0

0

0

0

0

0

0

		Destination number

0

0

0

0

0

0

0

1

		Supplemental user provided calling address-failed network screening

0

0

0

0

0

0

1

0

		Supplemental user provided calling address-not screened

0

0

0

0

0

0

1

1

		Completion number

0

0

0

0

0

1

0

0

		ITU spare

0

0

0

0

0

1

0

1

to

0

1

1

1

1

1

1

1

		Network specific use

1

0

0

0

0

0

0

0

to

1

0

1

1

1

1

1

1

		Ported number

1

1

0

0

0

0

0

0

		ANSI spare

1

1

0

0

0

0

0

1

to

1

1

1

1

0

1

1

1

		Transfer number 6

1

1

1

1

1

0

0

0

		Transfer number 5

1

1

1

1

1

0

0

1

		Transfer number 4

1

1

1

1

1

0

1

0

		Transfer number 3

1

1

1

1

1

0

1

1

		Transfer number 2

1

1

1

1

1

1

0

0

		Transfer number 1

1

1

1

1

1

1

0

1

		Callers Emergency Service Identification (CESID)

1

1

1

1

1

1

1

0

		Reserved for expansion

1

1

1

1

1

1

1

1

		Octet 2

		(For type dialed digits and destination number type of address)

		H

		G

		F

		E

		D

		C

		B

		A

Nature of address indicator

		Spare

0

0

0

0

0

0

0

		Subscriber number

0

0

0

0

0

0

1

		Spare reserved, for national use

0

0

0

0

0

1

0

		National (significant number)

0

0

0

0

0

1

1

		International number

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

		Abbreviated number

0

0

0

0

1

1

0

H

G

F

E

D

C

B

A

		Spare

0

0

0

0

1

1

1

to

1

1

1

1

1

1

1

(For type supplemental user provided calling address)

		H

		G

		F

		E

		D

		C

		B

		A

Nature of address indicator

		Spare

0

0

0

0

0

0

0

		Unique subscriber number

0

0

0

0

0

0

1

		Spare, reserved for national use

0

0

0

0

0

1

0

		Unique national significant number

0

0

0

0

0

1

1

		Unique international number

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

to

1

1

1

0

0

0

0

		Non-unique subscriber number

1

1

1

0

0

0

1

		Spare, reserved for national use

1

1

1

0

0

1

0

		Non-unique national number

1

1

1

0

0

1

1

		Non-unique international number

1

1

1

0

1

0

0

		Spare

1

1

1

0

1

0

1

		Spare

1

1

1

0

1

1

0

		Test line code

1

1

1

0

1

1

1

		Reserved for network-specific use

1

1

1

1

0

0

0

to

1

1

1

1

1

1

0

Spare

1

1

1

1

1

1

1

(For completion number type of address)

		H

		G

		F

		E

		D

		C

		B

		A

Nature of address indicator

		Spare

0

0

0

0

0

0

0

		Subscriber number

0

0

0

0

0

0

1

		Spare, reserved for national use

0

0

0

0

0

1

0

		National significant number

0

0

0

0

0

1

1

		International number

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

to

1

1

1

0

0

0

0

		Subscriber number, operator requested

1

1

1

0

0

0

1

		National number, operator requested

1

1

1

0

0

1

0

		International number, operator requested

1

1

1

0

0

1

1

		No number present, operator requested

1

1

1

0

1

0

0

		No number present, cut-through call to carrier

1

1

1

0

1

0

1

		950 + call from local exchange carrier public station, hotel/motel, or nonexchange access end office

1

1

1

0

1

1

0

		Test line code

1

1

1

0

1

1

1

H

G

F

E

D

C

B

A

		Reserved for network-specific use

1

1

1

1

0

0

0

to

1

1

1

1

1

1

0

		Spare

1

1

1

1

1

1

1

Odd/even indicator

		Even number of address signals

0

		Odd number of address signals

1

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

Reserved

0

0

Presentation

		Presentation allowed

0

0

		Presentation restricted

0

1

		Spare

1

0

		Spare

1

1

Numbering Plan

		Unknown numbering plan

0

0

0

		ISDN numbering plan (Rec. E. 164, E. 163)

0

0

1

		Spare

0

1

0

		Reserved ITU-TS Data Numbering Plan

0

1

1

		Reserved ITU-TS Telex Numbering Plan

1

0

0

		Private numbering plan

1

0

1

		Spare

1

1

0

		Spare

1

1

1

Spare

0

		Octet 4

		H

		G

		F

		E

		D

		C

		B

		A

Address Signal-1st address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Address Signal-2nd address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

Octet 4

H

G

F

E

D

C

B

A

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

		Octets 5-n

		H

		G

		F

		E

		D

		C

		B

		A

Address Signal-1st address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Address Signal-2nd address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

 

Octets 5-n	H	G	F	E	D	C	B	A
Spare	1	1	1	0
End of pulse signal	1	1	1	1

		The generic address parameter identifies the type of address (dialed digits, etc.) being presented in a call setup. It also indicates the numbering plan used in the address and the actual address. When LNP is provided, the GAP provides the actual dialed digits for a ported number. The called party address is then used for the location routing number (LRN).

		The GAP parameter is also used in LNP applications. When a number has been ported, the dialed digits are placed in the GAP parameter. The called party address contains the location number used to route the call to the proper exchange. See Chapter 10 for more details on LNP.

		The nature of address indicator is dependent on the type of address provided. All of the options are previously shown for clarity.

Generic Digits Parameter

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Type of digits

		Account code

0

0

0

0

0

		Authorization code

0

0

0

0

1

		Private network traveling class mark

0

0

0

1

0

		ANSI Spare

0

0

0

1

1

to

0

1

1

0

1

		Originating party service provider

0

1

1

0

1

		Bill to number

0

1

1

1

1

		Reserved for network-specific use

1

0

0

0

0

to

1

1

1

1

0

		Reserved for extension

1

1

1

1

1

Encoding scheme

		BCD even

0

0

0

		BCD odd

0

0

1

		IA5

0

1

0

		Binary

0

1

1

		Spare

1

0

0

to

1

1

1

		Octets 2-n

Digits

		(Encoded in the format specified above)

		The generic digits parameter provides additional numeric data pertaining to supplementary services such as authorization code, PIN number, or account code.

 

The type of digits is found in the first octet. These types are related to PBX features and/or business group features. The transfer of this data is possible from an ISDN-compatible PBX to another ISDN-compatible PBX through the PSTN using the SS7 ISUP protocol and parameters such as this one.

Generic Name Parameter

H

G

F

E

D

C

B

A

Presentation

		Presentation allowed

0

0

		Presentation restricted

0

1

		Blocking toggle

1

0

		No indication

1

1

Spare

0

0

Availability

		Name available/unknown

0

		Name not available

1

Type of name

		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

		The Generic Name parameter contains information to be used for name display features. In ANSI networks, Calling Name (CNAM) display requires the terminating exchange to access a database and search for the name information. In some networks (outside the U.S.) the name information is actually carried in the IAM from the originating exchange. The name information is found in this parameter in the IA5 format. Up to 15 characters may be sent.

Hop Count Parameter	H	G	F	E	D	C	B	A
Hop Counter				x	x	x	x	x
Spare	0	0	0

		The hop counter is used to ensure that ISUP looping does not occur. The initial message is sent in the forward direction with the maximum value allowed (network dependent). As the message is passed through each circuit, the counter is decremented by one. When the counter reaches zero, the message is discarded. The counter value is the number of contiguous SS7 circuits that this message must pass to reach its destination, and is provided in binary form.

Information Indicators

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Calling party address response indicator

		Calling party address not included

0

0

		Calling party address not available

0

1

		Spare

1

0

		Calling party address included, hold not provided

1

1

Hold provided indicator

		Hold not provided (default)

0

		*Hold provided

1

Spare

0

0

		H

		G

		F

		E

		D

		C

		B

		A

Calling party's category response indicator

		Calling party's category not included

0

		*Calling party's category included

1

Charge information response indicator

		Charge information not included

0

		*Charge information included

1

Solicited information indicator

		Solicited

0

		Unsolicited

1

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Spare

0

0

0

0

0

0

0

Multilocation business group info response indicator

		Multilocation business group info not included

0

		Multilocation business group info included

1

		This parameter provides additional information related to a call in progress. It can be sent in either direction, and can be a solicited message or unsolicited. Solicited indicates that the distant exchange requested information (billing information, for example) and the receiving exchange is replying to that request.

		This parameter does not provide the requested information, it simply indicates that the information is in this message.

Information Request Indicators

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Calling party address request indicator

		Calling party address not requested

0

		Calling party address requested

1

H

G

F

E

D

C

B

A

Holding indicator

		Holding not requested

0

		*Holding requested

1

Spare

0

		H

		G

		F

		E

		D

		C

		B

		A

Calling party's category request indicator

		Calling party's category not requested

0

		*Calling party's category requested

1

		H

		G

		F

		E

		D

		C

		B

		A

Charge information request indicator

		Charge information not requested

0

		Charge information requested

1

Spare

0

0

		H

		G

		F

		E

		D

		C

		B

		A

Malicious call identification request indicator

		Malicious call identification not requested

0

		*Malicious call identification requested

1

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Spare

0

0

0

0

0

0

0

Multilocation business group info indicator

		Multilocation business group info not requested

0

		Multilocation business group info requested

1

		The information request parameter is used to request specific information regarding a call already in progress. The response to the request parameter is the information indicators, with the appropriate parameters providing the actual data.

		This information is used in call processing and billing for the call. Not all of these procedures are currently in use in U.S. networks, yet the functionality is defined in both ITU and ANSI standards.

Jurisdiction Information Parameter (JIP)

H

G

F

E

D

C

B

A

Address Signal-1st address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

Jurisdiction Information Parameter (JIP)

H

G

F

E

D

C

B

A

		Digit 9

1

0

0

1

		Spare

1

0

1

0

		Code 11

1

0

1

1

		Code 12

1

1

0

0

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Address Signal-2nd address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

		The JIP is used in LNP applications to support billing systems. When an originating number has been ported, billing systems may not be able to determine the correct billing for the call (because one billion systems are still based on the North American Numbering Plan). The JIP provides the LRN assigned to the originating number, which is then used for determining proper billing for the call. The calling party number is no longer applicable for billing of a call in the case of ported numbers.

		This parameter is a variable length parameter consisting of address signals only. The parameter provides numerical data indicating the geographic origination of the call.

Message Compatability Information Instruction Indicators

H

G

F

E

D

C

B

A

Transit at intermediate exchange indicator

		Transit interpretation

0

		End node interpretation

1

Release call indicator

		Do not release call

0

		Release call

1

Message Compatability Information Instruction Indicators

H

G

F

E

D

C

B

A

Send notification Indicator

		Do not send notification

0

		Send notification

1

Discard message indicator

		Do not discard message (pass on)

0

		Discard message

1

Pass on not possible indicator

		Release call

0

		Discard information

1

Broadband/narrowband interworking indicator

		Pass on

0

0

		Discard message

0

1

		Release call

1

0

		Reserved, assume 00

1

1

Extension indicator

		Information continues through the next octet

0

		Last octet

1

		This parameter provides instructions to an exchange processing an ISUP message that it does not understand. This message can be sent in either direction. Additional octets may be added to this parameter at another time, but right now these are the only defined parameter values.

		Network Specific Facility

		This field is encoded according to rules set by the network operator.

		Service-related information is transparently transferred in either direction between the local exchange and the identified network that provides the service. The information is significant to both user and the identified network.

		Normal Call Indicator

Nature of Connection Indicators

H

G

F

E

D

C

B

A

Satellite indicator

		No satellite circuit in the connection

0

0

		One satellite circuit in the connection

0

1

		Two satellite circuits in the connection

1

0

		Three or more satellite circuits in the connection

1

1

Continuity check indicator

		Continuity check not required

0

0

		Continuity check required on this circuit

0

1

Nature of Connection Indicators

H

G

F

E

D

C

B

A

		Continuity check performed on a previous circuit

1

0

		Spare

1

1

		H

		G

		F

		E

		D

		C

		B

		A

Echo control device indicator

		Outgoing half echo control device not included

0

		Outgoing half echo control device included

1

		Spare

0

0

0

		The nature of connection indicators is sent in the forward direction to provide information regarding the circuit connection specified in the CIC parameter of the message. The values within this parameter allow intermediate exchanges to determine how to handle the processing of this message.

		Network Transport

		As seen previously, this parameter consists of other ISUP parameters. It is used to send ISUP parameters through the network transparently, without involving a call setup or other mechanism. The objective is to send parameters end-to-end through the network, without the intermediate exchanges having to process the message.

Notification Indicator

H

G

F

E

D

C

B

A

Notification indicator

		Spare

0

0

0

0

0

0

0

to

0

0

0

0

0

1

1

		Call completion delay

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

to

1

0

0

0

0

0

1

		Conference established (multiparty call)

1

0

0

0

0

1

0

		Conference disconnected

1

0

0

0

0

1

1

		Other party added to conference

1

0

0

0

1

0

0

		Isolated

1

0

0

0

1

0

1

		Reattached

1

0

0

0

1

1

0

		Other part isolated

1

0

0

0

1

1

1

		Other party reattached

1

0

0

1

0

0

0

		Other part split

1

0

0

1

0

0

1

		Other part disconnected

1

0

0

1

0

1

0

		Conference floating

1

0

0

1

0

1

1

		Spare

1

0

0

1

1

0

0

		Spare

1

0

0

1

1

0

1

		Spare

1

0

0

1

1

1

0

H

G

F

E

D

C

B

A

		Conference floating, served user preempted

1

0

0

1

1

1

1

		Spare

1

0

1

0

0

0

0

to

1

0

1

1

1

1

1

		Call is a waiting call

1

1

0

0

0

0

0

		Reserved for transfer in progress

1

1

0

0

0

0

1

		Reserved for call isolated from conference call

1

1

0

0

0

1

0

		Reserved for call split from conference call

1

1

0

0

0

1

1

		Reserved for call reattached to conference call

1

1

0

0

1

0

0

		Reserved for call added to conference call

1

1

0

0

1

0

1

		Spare

1

1

0

0

1

1

0

to

1

1

0

1

0

0

0

		Call transfer, alerting

1

1

0

1

0

0

1

		Call transfer, active

1

1

0

1

0

1

0

		Spare

1

1

0

1

0

1

1

to

1

1

1

1

0

0

0

		Remote hold

1

1

1

1

0

0

1

		Remote hold released

1

1

1

1

0

1

0

		Call is forwarded/deflected

1

1

1

1

0

1

1

		Spare

1

1

1

1

1

0

0

to

1

1

1

1

1

1

0

		Reserved

1

1

1

1

1

1

1

Extension indicator

		Octet continues through the next octet

0

		Last octet

1

		This parameter provides information regarding supplementary services. These services are related to business group services (such as Centrex) which provide PBX-like features to a group of business lines within a group. This parameter provides information regarding the nature of the calling party and its origin (forwarded call, call from hold, etc.).

Optional Backward Call Indicators

H

G

F

E

D

C

B

A

In-band information indicator

		No indication

0

		In-band info or an appropriate pattern is now available

1

Call forwarding may occur indicator

		No indication

0

		*Call forwarding may occur

1

Spare

0

0

Reserved for national use

0

0

 

Optional Backward Call Indicators

H

G

F

E

D

C

B

A

Network excessive delay indicator

		No indication

0

		Network excessive delay encountered

1

User-network interaction indicator

		No indication

0

		User-network interaction occurs, cut-through in both directions

1

		This parameter is sent in the backward direction providing information to another exchange regarding a call in progress. The inband information indicator is used to alert the distant exchange that in-band information such as a recording or a service tone is present on the voice circuit.

		The call forwarding may occur parameter is used to indicate that the call may be forwarded if the called party does not answer. There presently are no national ANSI procedures for this field.

		The user-network interaction indicator is sent from the originating exchange to indicate that additional information is being gathered from the caller (such as PIN number, or maybe special code) before routing the call.

Operator Services Information

H

G

F

E

D

C

B

A

Original access prefix

0

0

0

1

		Unknown

0

0

0

0

		1 + or 011 +

0

0

0

1

		0 + or 01 +

0

0

1

0

		0 -

0

0

1

1

		Spare

0

1

0

0

to

1

0

0

1

		Reserved for national use

1

0

1

0

to

1

1

1

1

Bill to information entry type and handling type

0

0

1

0

		Info entry unknown, unknown handling

0

0

0

0

		Info entry manual by operator, station handling

0

0

0

1

		Info entry manual by operator, person handling

0

0

1

0

		Info entry automated by tone input, station handling

0

0

1

1

		Info entry unknown, station handling

0

1

0

0

		Info entry unknown, person handling

0

1

0

1

		Info entry manual by operator, unknown handling

0

1

1

0

		Info entry automated by tone input, unknown handling

0

1

1

1

		Info entry automated by tone input, person handling

1

0

0

0

 

Operator Services Information

H

G

F

E

D

C

B

A

		Info entry automated by spoken input, unknown handling

1

0

0

1

		Info entry automated by spoken input, station handling

1

0

1

0

		Info entry automated by spoken input, person handling

1

0

1

1

		Spare

1

1

0

0

to

1

1

0

1

		Reserved for network-specific use

1

1

1

0

to

1

1

1

1

Bill-to type

0

0

1

1

		Unknown

0

0

0

0

		Calling card-14-digit format

0

0

0

1

		Calling card-89C format

0

0

1

0

		Calling card-other format

0

0

1

1

		Collect

0

1

0

0

		Third part number billing

0

1

0

1

		Sent paid (prepaid calling card)

0

1

1

0

		Spare

0

1

1

1

to

1

0

1

0

		Reserved for network-specific use

1

1

1

1

Bill-to specific information

0

1

0

0

		Spare

0

0

0

0

		NIDB authorizes

0

0

0

1

		NIDB reports, verify by automated means

0

0

1

0

		NIDB reports, verify by operator

0

0

1

1

		No NIDB query

0

1

0

0

		NIDB reports unavailable

0

1

1

0

		No NIDB response-timeout

0

1

1

1

		No NIDB response-reject component

1

0

0

0

		No NIDB response-ACG in effect

1

0

0

1

		No NIDB response-SCCP failure

1

0

1

0

		Spare

1

0

1

1

		Reserved for network-specific use

1

1

0

0

to

1

1

1

1

Special handling

0

1

0

1

		Unknown

0

0

0

0

		Call completion

0

0

0

1

		Rate information

0

0

1

0

		Trouble reporting

0

0

1

1

		Time and charges

0

1

0

0

		Credit reporting

0

1

0

1

 

Operator Services Information

H

G

F

E

D

C

B

A

		General assistance

0

1

1

0

		Spare

0

1

1

1

to

1

0

1

0

		Reserved for network-specific use

1

0

1

1

to

1

1

1

1

Spare

0

1

1

0

Accessing signaling

0

1

1

1

		Unknown

0

0

0

0

		Dial pulse

0

0

0

1

		Dualtone multifrequency (DTMF)

0

0

1

0

		Spare

0

0

1

1

to

1

0

0

1

		Reserved for network-specific use

1

0

1

0

to

1

1

1

1

		The operator services parameter is used to identify how a caller accessed an operator for assistance, and how the call should be billed. For example, if a caller dialed 01 + the number, special handling may be required. Billing may also be affected based on the caller's interaction with the operator (the caller may request the call to be billed to a calling card for example). The values in this parameter are used to identify how the call should be handled in the billing system.

Original Called Number

H

G

F

E

D

C

B

A

		Octet 1

Nature of address indicator

		Spare

0

0

0

0

0

0

0

		Unique subscriber number

0

0

0

0

0

0

1

		Spare, reserved for national use

0

0

0

0

0

1

0

		Unique national significant number

0

0

0

0

0

1

1

		Unique international number

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

to

1

1

1

0

0

0

0

		Non-unique subscriber number

1

1

1

0

0

0

1

		Spare, reserved for national use

1

1

1

0

0

1

0

		Non-unique national significant number

1

1

1

0

0

1

1

		Non-unique international number

1

1

1

0

1

0

0

		Spare

1

1

1

0

1

0

1

		Spare

1

1

1

0

1

1

0

		Test line test code

1

1

1

0

1

1

1

 

Original Called Number

H

G

F

E

D

C

B

A

		Reserved for network specific use

1

1

1

1

0

0

0

to

1

1

1

1

1

1

0

		Spare

1

1

1

1

1

1

1

Odd/even indicator

		Even number of address signals

0

		Odd number of address signals

1

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Reserved

0

0

Address presentation

		Presentation

0

0

		Presentation restricted (default)

0

1

		Spare

1

0

		Spare

1

1

Numbering plan

		Unknown

0

0

0

		ISDN numbering plan (E.164, E.163)

0

0

1

		Spare

0

1

0

		Reserved (ITU: Data numbering plan)

0

1

1

		Reserved (ITU: Telex numbering plan)

1

0

0

		Private numbering plan

1

0

1

		Spare

1

1

0

		Spare

1

1

1

Spare

0

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

1st address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

2nd address

		Digit 0

0

0

0

0

 

Octet 3

H

G

F

E

D

C

B

A

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

		This parameter is used when call redirecting (forwarding) occurs. The parameter identifies the address of the party that initiated the redirection. This parameter also provides information regarding the presentation of the calling party number, used by the end exchange when connecting the call to its destination.

		Only the first and second address signals are shown here (for brevity), but there can be additional address signals. The address signals are typically the telephone number assigned to the subscriber who initiated the redirecting.

Originating Line Information	H	G	F	E	D	C	B	A
Binary equivalent of the II digits	0	0	0	0	0	0	0	0
				to
	0	1	1	0	0	0	1	1
Reserved for future expansion	0	1	1	0	0	1	0	0
				to
	1	1	1	1	1	1	1	1

		This information is sent in the forward direction representing a toll class of service for the call.

		Outgoing Trunk Group Number

		This parameter provides the trunk number used for an interworking call. Interworking means that the call was sent to another exchange in another network. The trunk number represents the circuit used at the gateway switch into the other network. This parameter is only found in instances where internetworking occurs.

 

Precedence

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Precedence level

		Flash override (0)

0

0

0

0

		Flash (1)

0

0

0

1

		Immediate (2)

0

0

1

0

		Priority (3)

0

0

1

1

		Routine (4)

0

1

0

0

		Spare

0

1

0

1

to

1

1

1

1

Spare

0

Look ahead for busy (LFB)

		Look ahead for busy allowed

0

0

		Look ahead for busy not allowed

1

0

		Path reserved

0

1

		Spare

1

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Network identity (coded in BCD), the telephone country code is placed in the second to fourth digits of this parameter. The first digit is set to zero.

Octet 2

H

G

F

E

D

C

B

A

Multilevel Precedence and Preemption (MLPP)

		Defense switched network

0

0

0

0

0

0

0

		Spare

0

0

0

0

0

0

1

to

1

1

1

1

1

1

1

Extension

		Octet continues through the next octet

0

		Last octet

1

		Precedence is a feature provided in defense networks, where an individual of higher rank is given priority for outgoing trunks over someone of lower rank. This feature is typically found in AUTOVON systems, but is now being offered through the central office services.

		This parameter identifies the level of precedence allowed and whether or not the ''look ahead for busy" feature is allowed.

Range and Status

		Octet 1

Range

 

This field of the parameter is a binary representation of the range of circuits that are affected by the status field that follows it. Because this is a zero-based number, the actual circuit number is the binary representation plus one.

		In national circuits (ANSI only), the range is from 0 to 23. International circuits range from 0 to 31.

Octet 2

Status

		The status field provides the status of the circuits indicated in the range parameter. The status bits are numbered from 0 to 23, or 0 to 31 in international circuits. There is a direct correlation between the range and status fields. The number of status bits is equal to the value of the range field plus 1.

		Status bit 0 is located in the first bit position of the status octet. Other status bits follow in numerical order. More than one octet can exist. In the range field, if the range is coded as zero, the status bit is not provided.

		The status bits also depend on the message type for their value. For instance, in a Circuit Group Blocked message, the status bits are different than in the Circuit Group Unblocking message. The status bit values are as follows:

In Circuit Group Blocking messages:

		No blocking

0

		Blocking

1

In Circuit Group Blocking Acknowledgment messages:

		No blocking acknowledgment

0

		Blocking acknowledgment

1

In Circuit Group Unblocking messages:

		No unblocking

0

		Unblocking

1

In Circuit Group Unblocking Acknowledgment messages:

		No unblocking acknowledgment

0

		Unblocking acknowledgment

1

In Circuit Group Reset Acknowledgment messages:

		No blocking

0

		Blocked

1

		The range and status parameter is found in circuit group supervision messages to indicate the range of circuits that are affected by the status indicator, and the status of those circuits. The status field correlates to the type of circuit group message. The status bits are provided in numerical order, with each status bit corresponding with the CIC of the affected circuit.

 

As seen in the range field, the range field identifies the actual circuit number (or range of circuits), which is used to also identify which status bits are required for each circuit. Status bit 0 is the first status bit, found in the first bit location of the first octet in the status field.

Redirecting Number

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Nature of address indicator

		Spare

0

0

0

0

0

0

0

		Subscriber number

0

0

0

0

0

0

1

		Spare, reserved for national use

0

0

0

0

0

1

0

		National significant number

0

0

0

0

0

1

1

		International number

0

0

0

0

1

0

0

		Spare

0

0

0

0

1

0

1

to

1

1

1

0

0

0

0

		Subscriber number, operator requested

1

1

1

0

0

0

1

		National number, operator requested

1

1

1

0

0

1

0

		International number, operator requested

1

1

1

0

1

1

		No number present, operator requested

1

1

1

0

1

0

0

		No number present, cut-through call to carrier

1

1

1

0

1

0

1

		950 1 call from local exchange carrier

1

1

1

0

1

1

0

		public station, hotel/motel, or nonexchange access end-office

		Test line code

1

1

1

0

1

1

1

		Reserved for network specific use

1

1

1

1

0

0

0

to

1

1

1

1

1

1

0

		Spare

1

1

1

1

1

1

1

Odd/even bits

		Even number of address signals

0

		Odd number of address signals

1

		Octet 2

		H

		G

		F

		E

		D

		C

		B

		A

Reserved

0

0

Address presentation

		Presentation allowed

0

0

		Presentation restricted

0

1

		Spare

1

0

		Spare

1

1

Numbering Plan

		Unknown numbering plan

0

0

0

		ISDN numbering plan (Rec. E.164, E.163)

0

0

1

		Spare

0

1

0

		Reserved ITU-TS Data Numbering Plan

0

1

1

		Reserved ITU-TS Telex Numbering Plan

1

0

0

		Private numbering plan

1

0

1

Octet 2

H

G

F

E

D

C

B

A

		Spare

1

1

0

		Spare

1

1

1

Spare

0

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

Address Signal-1st address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Address Signal-2nd address

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

		When call forwarding is applied to a call, this parameter is used to indicate the telephone number from which the called number was last forwarded. Call forwarding can be invoked from any telephone, hence the need to identify from where the telephone number was last forwarded.

		The address signals, as is the case in all parameters with this field, can consist of several digits, even though only one octet is shown here (for brevity). At least four octets are needed to represent a telephone number. Any odd number of address signals requires a filler for the last half of the octet. The odd/even address indicator identifies those addresses that do not require a full octet, and contain a filler at the end.

Redirect Capability

H

G

F

E

D

C

B

A

Redirection possibility indicator

		Not used

0

0

0

		Redirection possible before ACM

0

0

1

		Redirection possible before ANM

0

1

0

		Redirection possible at any time during the call

0

1

1

Spare

1

0

0

to

1

1

1

Spare

0

0

0

0

Extension indicator

		Next octet

0

		Last octet

1

		This information is sent in the forward direction. It indicates that the succeeding exchange is allowed to initiate redirection of a call, and indicates when the redirection may take place (in relation to the call processing procedures).

Redirect Counter	H	G	F	E	D	C	B	A
Counter				x	x	x	x	x

		This parameter indicates the number of times a call has been redirected within the network. This may be used to control the maximum number of times a number can be redirected as part of a service offering. The number is represented in binary.

Redirection Information

H

G

F

E

D

C

B

A

		Octet 1

Spare

0

0

0

		Reserved

0

Original redirecting reason

		Unknown/not available (default)

0

0

0

0

		User busy

0

0

0

1

		No reply

0

0

1

0

		Unconditional

0

0

1

1

		Deflection

0

1

0

0

		Spare

0

1

0

1

to

1

1

1

0

		Reserved

1

1

1

1

Octet 2

H

G

F

E

D

C

B

A

Redirection counter

		No redirection has occurred

0

0

0

0

		Redirected 1 time

0

0

0

1

		Redirected 2 times

0

0

1

0

		Redirected 3 times

0

0

1

1

		Redirected 4 times

0

1

0

0

		Redirected 5 times

0

1

0

1

		Redirected 6 times

0

1

1

0

		Redirected 7 times

0

1

1

1

		Redirected 8 times

1

0

0

0

		Redirected 9 times

1

0

0

1

		Redirected 10 times

1

0

1

0

		Redirected 11 times

1

0

1

1

		Redirected 12 times

1

1

0

0

		Redirected 13 times

1

1

0

1

		Redirected 14 times

1

1

1

0

		Redirected 15 times

1

1

1

1

Redirecting reason

		Unknown/not available (default)

0

0

0

0

		User busy

0

0

0

1

		No reply

0

0

1

0

		Unconditional

0

0

1

1

		Spare

0

1

0

0

to

1

1

1

1

		This parameter is used with calls where call forwarding has been invoked. The information provided indicates the original reason for the forwarding, and in the case where the call has undergone more than one forward, the reason for the subsequent forwardings.

		It is quite possible for a call to be forwarded a number of times, without the knowledge of the caller. For example, a telephone number may be forwarded to another telephone number. When a caller tries to reach that number, they are forwarded to the second number. The second number may also be forwarded, resulting in the call being redirected again. This parameter indicates the number of times the call was redirected and the reason for the redirecting.

		Redirection Number

		This parameter identifies the number to which the called number is to be redirected. The values contained in this parameter include the nature of address indicator, numbering plan, and the telephone number the call is to be redirected to. The actual values have not  been shown here, because they are repeated in several other places in this book.

 

 

Remote Operations

H

G

F

E

D

C

B

A

Protocol profile

		Spare

0

0

0

0

0

to

1

0

0

0

0

		Remote operations protocol

1

0

0

0

1

		Spare

1

0

0

1

0

to

1

1

1

1

1

		Spare

0

0

Extension bit

		Next octet

0

		Last octet

1

Component (follows same format as TCAP component)

		Service Activation

		H

		G

		F

		E

		D

		C

		B

		A

Feature code indicators

Reserved for international use

0

0

0

0

0

0

0

0

to

0

1

1

1

1

0

1

1

Call waiting originating invoked

0

1

1

1

1

1

0

0

Dial call waiting invoked

0

1

1

1

1

1

0

1

Complete call req, ISUP used all the way

0

1

1

1

1

1

1

0

Complete call req, ISUP not used all the way

0

1

1

1

1

1

1

1

Network service attached

1

0

0

0

0

0

0

0

Network service released

1

0

0

0

0

0

0

1

Coin collect

1

0

0

0

0

0

1

0

Coin return

1

0

0

0

0

0

1

1

Network service recall

1

0

0

0

0

1

0

0

Billing verification

1

0

0

0

0

1

0

1

Hold available

1

0

0

0

0

1

1

0

Hold not available

1

0

0

0

0

1

1

1

Hold request

1

0

0

0

1

0

0

0

Hold acknowledge

1

0

0

0

1

0

0

1

Hold release request

1

0

0

0

1

0

1

0

Hold release acknowledge

1

0

0

0

1

0

1

1

Hold continuation request

1

0

0

0

1

1

0

0

Disconnect request

1

0

0

0

1

1

0

1

Reconnect request

1

0

0

0

1

1

1

0

Spare

1

0

0

0

1

1

1

1

to

1

0

0

1

0

0

1

0

		This parameter is used to invoke supplementary services from another exchange. Presently, there are not a lot of features called for in this parameter, but there is room for expansion.

		Service Code

		The service code field is a one-octet field representing the service code as assigned by the North American Numbering Plan Administration at Bellcore. Presently, this parameter is under further study, but can be used to identify a specific type of service, which a subscriber can invoke either in real time or otherwise. The number in this parameter is a binary number representing the decimal equivalent of the service code.

Special Processing Request

H

G

F

E

D

C

B

A

Special processing request

		Spare

0

0

0

0

0

0

0

0

		Reserved for international use

0

0

0

0

0

0

0

1

to

0

0

0

0

1

1

1

1

		Reserved for national use

0

0

0

1

0

0

0

0

to

0

1

1

1

1

1

1

0

		Service processing requested

0

1

1

1

1

1

1

1

		Reserved for network-specific use

1

0

0

0

0

0

0

0

to

1

1

1

1

1

1

1

0

		Spare

1

1

1

1

1

1

1

1

		In the event that a call originates in a private network, there may be a need for special number translation or authorization code verification. This parameter indicates the special processing requirements of just such a call. The receiver of this message is a service node in the PSTN from a service node in the private network.

 

Suspend/Resume Indicators

H

G

F

E

D

C

B

A

Suspend/Resume indicator

		ISDN subscriber initiated

0

		Network initiated (default)

1

		Spare

0

0

0

0

0

0

0

		The suspend/resume indicator is sent in the forward direction to indicate the originator of a suspend or a resume. There are only two options, either an ISDN subscriber or the network initiated the message.

		Transaction Request

		This parameter follows the same message structure as seen in the TCAP, providing the transaction ID and the SCCP address for those messages used to carry information regarding a call in progress. This parameter can only be used for calls that are already in progress, and allows the ISUP protocol to use the services of the TCAP protocol to deliver service information relating to a call.

		This parameter is carried in the IAM during the circuit connection establishment. The receiving exchange then uses this parameter for all subsequent messages related to the call on that circuit, such as feature invocation or call hand-off procedures.

Transit Network Selection

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Network identification plan (National ANSI networks)

		Unknown

0

0

0

0

		3-digit carrier identification with circuit code

0

0

0

1

		4-digit carrier identification with circuit code

0

0

1

0

		Reserved

0

0

1

1

to

0

1

1

1

		Reserved for network-specific use

1

0

0

0

to

1

1

1

1

Network identification plan (International networks)

		Unknown

0

0

0

0

		Public data network identification code

0

0

1

1

		Public land mobile network ID code

0

1

1

0

		Type of network identification

		ITU standardized identification

0

0

0

		National network identification

0

1

0

Spare

0

Octet 2

H

G

F

E

D

C

B

A

Digit One

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Digit Two

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

Digit Three

		Digit 0

0

0

0

0

		Digit 1

0

0

0

1

		Digit 2

0

0

1

0

		Digit 3

0

0

1

1

		Digit 4

0

1

0

0

		Digit 5

0

1

0

1

		Digit 6

0

1

1

0

Octet 3

H

G

F

E

D

C

B

A

		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

		Spare

1

1

0

1

		Spare

1

1

1

0

		End of pulse signal

1

1

1

1

Circuit Code

		Unspecified

0

0

0

0

		International call, no operator requested

0

0

0

1

		International call, operator requested

0

0

1

0

		Spare

0

0

1

1

to

0

1

1

1

		Reserved for network-specific use

1

0

0

0

to

1

1

1

1

		This parameter is sent in the forward direction to indicate the long-distance carrier or transit network to be used to carry this call. This is used whenever the call is an inter-LATA call or international call.

		The carrier ID is a three- or four-digit code administered by Bellcore that uniquely identifies each of the long-distance carriers. This is the same code dialed when using calling cards (10xxx, where xxx equals the carrier code).

		Presently, there are no implications allowing for the use of ISUP to international networks such as the public data network or the public land mobile network. These are for further study.

Transmission Medium Used

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Transmission medium used

		Speech

0

0

0

0

0

0

0

0

		Spare

0

0

0

0

0

0

0

1

		Reserved for 64-kbps unrestricted

0

0

0

0

0

0

1

0

		3.1-kHz audio

0

0

0

0

0

0

1

1

		Reserved

0

0

0

0

0

1

0

0

		Reserved

0

0

0

0

0

1

0

1

		Reserved for 64-kbps preferred

0

0

0

0

0

1

1

0

		Reserved

0

0

0

0

0

1

1

1

to

0

0

0

0

1

0

1

0

Octet 1	H	G	F	E	D	C	B	A
Spare	0	0	0	0	1	0	1	1
				to
	1	1	1	1	1	1	1	1

		The transmission used in a call setup is sent in the backward direction in the event the original circuit requested could not be used. This parameter then identifies the circuit type and is carried in the ANM, ACM, and CPG messages.

User Service Information

		Octet 1

		H

		G

		F

		E

		D

		C

		B

		A

Information transfer capability

		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

0

0

0

1

Coding standard

		ITU standardized coding

0

0

		National standard

1

0

Extension bit

		Octet continues through the next octet

0

		Last octet

1

* Note: Only permitted when 64-kbps information transfer rate is used.

Octet 2

H

G

F

E

D

C

B

A

Information transfer rate

		Code for packet mode calls

0

0

0

0

0

		64 kbps

1

0

0

0

0

		384 kbps

1

0

0

1

1

		1472 kbps (national ANSI only)

1

0

1

0

0

		1536 kbps

1

0

1

0

1

		1920 kbps

1

0

1

1

1

		Multirate (64 kbps based)

1

1

0

0

0

Transfer mode

		Circuit mode

0

0

		Packet mode

1

0

		Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 2a

		H

		G

		F

		E

		D

		C

		B

		A

Establishment

		Demand (default)

0

0

Octet 2a

H

G

F

E

D

C

B

A

Configuration

		Point-to-point (default)

0

0

Structure

		Default (see description)

0

0

0

		8-kHz integrity

0

0

1

		Service data unit integrity

1

0

0

		Unstructured

1

1

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 2b

		H

		G

		F

		E

		D

		C

		B

		A

Information transfer rate (destination to origination)

		Code for packet mode calls

0

0

0

0

0

		64 kbps

1

0

0

0

0

		384 kbps

1

0

0

1

1

		1472 kbps

1

0

1

0

0

		1536 kbps

1

0

1

0

1

		1920 kbps

1

0

1

1

1

		Multirate (64-kbps based)

1

1

0

0

0

Symmetry

		Bidirectional symmetric (default)

0

0

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 2.1

		H

		G

		F

		E

		D

		C

		B

		A

(present if octet 2 indicates multirate 64-kbps base rate)

Rate multiplier

		Reserved (0)

0

0

0

0

0

0

0

		One (1) to thirty (30)

0

0

0

0

0

0

1

to

0

0

1

1

1

1

0

		Thirty-one (31) to one hundred twenty seven (127)

0

0

1

1

1

1

1

to

1

1

1

1

1

1

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 3

		H

		G

		F

		E

		D

		C

		B

		A

User information layer 1 protocol

		ITU standardized rate adaption V.110/X.30

0

0

0

0

1

		Recommendation G.711 u-law speech

0

0

0

1

0

		Recommendation G.722 and G.725 7 kHz audio

0

0

1

0

1

		Non-ITU standardized rate adaption

0

0

1

1

1

Octet 3

H

G

F

E

D

C

B

A

		ITU standardized rate adaption V.120

0

1

0

0

0

		ITU standardized rate adaption X.31 HDLC

0

1

0

0

1

		flag stuffing

Layer 1 identification

0

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 3a

		H

		G

		F

		E

		D

		C

		B

		A

		(present if ITU standardized rate adaption V110/V120)

User rate

x

x

x

x

x

		Rate is indicated by E-bits specified in Rec. 1.460

0

0

0

0

0

		0.6 kbps Recommendations V.6 & X.1

0

0

0

0

1

		1.2 kbps Recommendations V.6

0

0

0

1

0

		2.4 kbps Recommendations V.6 & X.1

0

0

0

1

1

		3.6 kbps Recommendations V.6

0

0

1

0

0

		4.8 kbps Recommendations V.6 & X.1

0

0

1

0

1

		7.2 kbps Recommendations V.6

0

0

1

1

0

		8.0 kbps Recommendations I.460

0

0

1

1

1

		9.6 kbps Recommendations V.6 & X.1

0

1

0

0

0

		14.4 kbps Recommendations V.6

0

1

0

0

1

		16.0 kbps Recommendations I.460

0

1

0

1

0

		19.2 kbps Recommendations V.6

0

1

0

1

1

		32.0 kbps Recommendations I.460

0

1

1

0

0

		48.0 kbps Recommendations V.6 & X.1

0

1

1

1

0

		56.0 kbps Recommendations V.6

0

1

1

1

1

		64.0 kbps Recommendations X.1

1

0

0

0

0

		0.1345 kbps Recommendations X.1

1

0

1

0

1

		0.100 kbps Recommendations X.1

1

0

1

1

0

		0.075/1.2 kbps Recommendations V.6 & X.1

1

0

1

1

1

		1.2/0.075 kbps Recommendations V.6 & X.1

1

1

0

0

0

		0.050 kbps Recommendations V.6 & X.1

1

1

0

0

1

		0.075 kbps Recommendations V.6 & X.1

1

1

0

1

0

		0.110 kbps Recommendations V.6 & X.1

1

1

0

1

1

		0.150 kbps Recommendations V.6 & X.1

1

1

1

0

0

		0.200 kbps Recommendations V.6 & X.1

1

1

1

0

1

		0.300 kbps Recommendations V.6 & X.1

1

1

1

1

0

		12 kbps Recommendations V.6

1

1

1

1

1

Negotiation

		In-band negotiation not possible

0

		In-band negotiation possible

1

Synchronous/asynchronous

		Synchronous at the ''R" interface

0

		Asynchronous at the "R" interface

1

Extension bit

Octet continues through the next octet	0
Last octet	1
* Note: The first value is the transmit rate in the forward direction of the call, while the second value is the transmit rate in the backward direction of the call.

Octet 3b

H

G

F

E

D

C

B

A

		(present if ITU standardized rate adaption V110)

Spare

0

Flow control on receive

		Cannot accept data with flow control mechanism

0

		Can accept data with flow control mechanism

1

Flow control on transmit

		Not required to send data with flow control mechanism

0

		Required to send data with flow control mechanism

1

Network independent clock on receive

		Cannot accept data with independent clock

0

		Can accept data with independent clock

1

Network-independent clock on transmit

		Not required to send data with

0

		network-independent clock

		Required to send data with

1

		network-independent clock

Intermediate rate

		Not used

0

0

		8 kbps

0

1

		16 kbps

1

0

		32 kbps

1

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 3c

		H

		G

		F

		E

		D

		C

		B

		A

(present if ITU standardized rate adaption V.120)

Spare

0

In-band/out-band

		Not applicable to this standard

0

		Negotiation is done in-band using logical link zero

1

Assignor/assignee

		Message originator is "Default Assignee"

0

		Message originator is "Assignor Only"

1

Logical link identifier (LLI) negotiation

		Default LLI = 256

0

		LLI negotiation

1

Octet 3c

H

G

F

E

D

C

B

A

Mode of operation

		Bit transparent mode of operation

0

		Protocol sensitive mode of operation

1

Multiframe

		Multiframe establishment not supported

0

		Multiframe establishment supported

1

Rate adaption Header/no header

		Rate adaption header not included

0

		Rate adaption header included

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 3d

		H

		G

		F

		E

		D

		C

		B

		A

(present if ITU standardized rate adaption V110/V120

Parity

x

x

x

		Odd

0

0

0

		Even

0

1

0

		None

0

1

1

		Forced to 0

1

0

0

		Forced to 1

1

0

1

Number of data bits excluding parity bit

		Not used

0

0

		5 data bits

0

1

		7 data bits

1

0

		8 data bits

1

1

Number of stop bits

		Not used

0

0

		1 stop bit

0

1

		1.5 stop bits

1

0

		2 stop bits

1

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 3e

		H

		G

		F

		E

		D

		C

		B

		A

(present if ITU standardized rate adaption V110/V120)

Modem type

x

x

x

x

x

x

		Coded according to network-specific rules

Duplex mode

		Half duplex

0

		Full duplex

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

Octet 4

H

G

F

E

D

C

B

A

User information (layer 2 protocol)

		ANSI T1.602

0

0

0

1

0

		Recommendation X.25 link level

0

0

1

1

0

Layer 2 identifier

1

0

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		Octet 5

		H

		G

		F

		E

		D

		C

		B

		A

User information (layer 3 protocol)

		ANSI T1.607

0

0

0

1

0

		Recommendation X.25 packet layer

0

0

1

1

0

Layer 3 identifier

1

1

Extension bit

		Octet continues through the next octet

0

		Last octet

1

		The user service information parameter is used when the subscriber is requesting data transmission on the voice facility without use of a modem. In this case, the subscriber is using either ISDN or X.25 packet switching as an interface to the PSTN.

		The purpose of this parameter is to send the data transmission parameters to the distant exchange, so that the called party can receive the same parameters and establish the proper connection for receipt of the data. This parameter does not address the requirements of ATM or BISDN. These are addressed through another protocol, B-ISUP.

		There are many notes and prerequisites listed in the ANSI standard regarding this parameter. Not all of these are listed here. The use of several of the octets is dependent on the use of other octets. For example, octet 3b is only used when octet 3 indicates ITU standardized rate adaptation V.110/X.30. Many of the notes are provided, but the best source for this parameter is the ANSI publication of T1.113-1992.

		Broadband ISUP (B-ISUP) Message Types

		Broadband ISUP (BISUP) has been developed to support the usage of ATM voice circuits in the PSTN. The ISUP protocol was developed to support the connection and teardown of digital channelized circuits, such as DS1 and DS3. The ISUP protocol provides the data necessary to connect and control these channels in digital circuits, but ATM is based on virtual paths and virtual circuits not on channels.

		The B-ISUP protocol is based on ISUP, and uses the same signaling procedures when possible. It is important to understand the role of B-ISUP so as not to confuse its procedures with those used when ATM SS7 links are used. The B-ISUP protocol is intended for the setup and teardown of voice transmissions over ATM; not the management of SS7 over ATM links in the same node.

		Rather than duplicate the efforts from the previous section, this section will serve to identify the message types and their parameters used for broadband ISUP signaling within the SS7 network. These message types and their parameters are published as they are currently defined, and could change as the standards continue to evolve.

		Figure 9.61 reflects the message types that are defined for use in the broadband networks. They are defined in the previous section for the most part, for the exception of those that are new. The new message types are defined next.

Message Type	H	G	F	E	D	C	B	A
Address Complete	0	0	0	0	0	1	1	0
Answer	0	0	0	0	1	0	0	1
Blocking	0	0	0	1	0	0	1	1
Blocking Acknowledgment	0	0	0	1	0	1	0	1
Call Progress	0	0	1	0	1	1	0	0
Confusion	0	0	1	0	1	1	1	1
Consistency Check End	0	0	0	1	0	1	1	1
Consistency Check End Ack	0	0	0	1	1	0	0	0
Consistency Check Request	0	0	0	0	0	1	0	1
Consistency Check Request Ack	0	0	0	1	0	0	0	1
Forward Transfer	0	0	0	0	1	0	0	0
IAM Acknowledgment	0	0	0	0	1	0	1	0
IAM Reject	0	0	0	0	1	0	1	1
Initial Address Message	0	0	0	0	0	0	0	1
Network Resource Management	0	0	1	1	0	0	1	0
Release	0	0	0	0	1	1	0	0
Release Complete	0	0	0	1	0	0	0	0
Reset	0	0	0	1	0	0	1	0
Reset Acknowledgment	0	0	0	0	1	1	1	1
Resume	0	0	0	0	1	1	1	0
Segmentation	0	0	1	1	1	0	0	0
Subsequent Address	0	0	0	0	0	0	1	0
Suspend	0	0	0	0	1	1	0	1
Unblocking	0	0	0	1	0	1	0	0
Unblocking Acknowledgment	0	0	0	1	0	1	1	0
User Part Available	0	0	1	1	0	1	0	1
User Part Test	0	0	1	1	0	1	0	0
User-to-user Information	0	0	1	0	1	1	0	1
Reserved for Narrowband ISDN	0	0	0	0	0	0	1	1
				to
	0	0	1	1	0	1	1	1
Reserved for Code Extension	1	1	1	1	1	1	1	1

		Figure 9.61 Broadband ISUP (B-ISUP) requires some new message types, in addition to those already supported in ISUP. This figure shows all of the B-ISUP message types and their indicator values.

In addition to some changes in message types, some additional parameters have been added to support ATM and BISDN circuits. These parameters are illustrated below with their respective message types, and described in the section following. The values of the various parameters are defined in the Bellcore and ANSI standards, as well as the ITU-TS Recommendation Q.2931.

		Figure 9.62

		Address Complete (ACM)

		The address complete message has added several new parameters to support the virtual path connection identifiers and additional broadband parameters. These can be seen in the table above. The function has not changed, however.

 

		Figure 9.63

		Answer (ANM)

		The answer message also remains the same in function. The cut-through on a voice circuit (virtual path connection identifier in the case of broadband) does not take place in both directions in ANSI networks until the called party goes off-hook, and the ANM has been received. Tones are passed over the voice circuit in one direction only, meaning the cut-through takes place in the backward direction.

 

		Figure 9.64

		Call Progress (CPG)

		This message allows additional information regarding the status of a call to be sent to a remote exchange. Used only in broadband, this allows exchanges to send event information in either direction while a call is in progress.

		Figure 9.65

		Confusion (CFN)

		This message is the same as in normal ISUP. When a message is received which the exchange cannot identify, it returns the message type of confusion.

 

		Figure 9.66

		Exit (EXM)

		This message is virtually the same as in ISUP. It is used when interworking with other networks to indicate a message has been successfully passed to another network.

 

		Figure 9.67

		Initial Address Message (IAM)

		This also is the same as in normal ISUP. The main difference between the two protocols and their IAMs is in the procedures. Normally, the routing label would identify which trunk circuit is to be used. In broadband, it identifies the virtual path connection identifier, if there is one available at the originating exchange that will accommodate the call being requested. Each exchange (originating and destination) is responsible for half of the virtual path connections, which prevents the possibility of glare.

		Figure 9.68

		Release (REL)

		The release message (REL) has several new parameters. All pertain to identifying the circuit that is to be released.

 

Release Complete (RLC)

		The release complete (RLC) remains the same, and does not change for the exception of the destination signaling identifier.

		Figure 9.69

		Subsequent Address (SAM)

		This message type is used in international networks only, and provides additional addressing information. This does not apply to U.S. networks.

		Figure 9.70

		User-to-user Information (USIS)

		There are no procedures currently defined for this parameter in U.S. networks. The purpose of this message is to provide additional information to a user part from a remote user part in relation to a call already in progress. The term ''user-to-user" refers to two user parts sending information to one another.

 

		Figure 9.71

		Forward Transfer (FOT)

		Used when an operator is requested during direct dial to an international number. The operator is also recalled when the call is terminated to provide additional assistance. Currently, this is only used in international networks.

		Figure 9.72

		Suspend (SUS)

		This message is sent in either direction to indicate that the called party has been disconnected. This would be used only if the connection had first been established, then the called party disconnected. Rather than send a release, the suspend allows the call circuit to be maintained for a period of time before initiating the release procedure. For example, if a called party is using call waiting, they may issue a flash hook to answer the other party. The suspend would be sent to the first calling exchange to hold the call circuit until a timeout, or until the called party came back to the original call.

 

		Figure 9.73

		Resume (RES)

		This is used along with the suspend message (SUS) type. When the called party comes back to the call previously suspended, the resume message type is sent to indicate the call progress can continue as normal.

		Figure 9.74

		Blocking (BLO)

		This is a maintenance message used for blocking a particular circuit from a connection. It can be initiated either manually or automatically by network management. Allows a circuit to be removed from service while still being able to send traffic over the circuit. Maintenance personnel may choose to block a circuit while they send test messages over that circuit.

 

		Figure 9.75

		Reset (RSM)

		This is used when memory allocated to a specific virtual path connection identifier gets corrupted and can no longer remember the state of the connection. The reset is used to start both ends in the same known state. All resources are released and counters are reset, yet the connection is maintained.

		Figure 9.76

 

Unblocking (UBL)

		This is the opposite of the blocking message, used to unblock a circuit.

		Figure 9.77

		Blocking Acknowledgment (BLA)

		This message type is sent in acknowledgment to a blocking message. It indicates that the blocking message was received and the user parts have been blocked from using the indicated circuit.

		Figure 9.78

		Reset Acknowledgment Message (RAM)

		When memory at either end of a connection becomes corrupted, the signaling point may lose track of the state of a connection. In this case, a reset is requested on the specified virtual path connection identifier. This reset will release all resources associated with the connection.

 

		Figure 9.79

		Unblocking Acknowledgment (UBA)

		This message indicates receipt of an unblocking message. This acknowledges receipt of the unblocking message and confirms that the circuit identified has been unblocked from the user parts.

		Figure 9.80

		User Part Test (UPT)

		This test message is used to verify the status of the specified user part. The purpose is to ensure that a user part marked as available or prohibited at the sending exchange is an accurate representation of the true state of the user part at the destination signaling point.

		Figure 9.81

 

User Part Available (UPA)

		Sent in response to a user part test message, indicating that the specified user part is available. User part test messages are used to verify the status of a given user part.

		Figure 9.82

		Network Resource Management (NRM)

		This message is sent in the backward direction whenever the resources allocated to an established call need to be modified (i.e., additional resources allocated for additional bandwidth requirements).

		Figure 9.83

 

Segmentation Message (SGM)

		When messages exceed the maximum size of the SS7 packet (272 octets) the message must be segmented. This message type is used to send an additional segment to the destination signaling point.

		Figure 9.84

		IAM Acknowledgment (IAA)

		Unlike the normal ISUP procedures, B-ISUP requires an acknowledgment to an initial address message (IAM). The purpose is twofold. In the event that the requesting exchange has assigned the virtual path connection identifier, then the acknowledgment is used to confirm that the connection has been reserved at the remote exchange. However, if the originating exchange is unable to assign a virtual path connection identifier (because there is not ample bandwidth available within the range of circuits controlled by the originating exchange) then the acknowledgment is used to notify the originating exchange which virtual path connection identifier has been assigned by the remote exchange.

		Figure 9.85

 

IAM Reject (IAR)

		This is used to notify the originator of an IAM that the requested bandwidth is not available on any of the virtual path connection identifiers within the control of the remote exchange. Therefore, a connection cannot be established. Since the originating exchange has not assigned the virtual path connection identifier, it is assumed that the originating exchange does not have ample bandwidth within its range of circuits either. The call connection attempt is aborted.

		Figure 9.86

		Consistency Check Request (CCR)

		The consistency check request (CCR) is sent to request the beginning of a "continuity" test on a specified virtual path connection identifier within a virtual path. This is much like the continuity check used in the ISUP between two exchanges. The purpose is to ensure that a virtual connection can be established on the user plane between two exchanges. The test can be initiated by either exchange.

		Figure 9.87

 

Consistency Check Request Acknowledgment (CCRA)

		This is sent in response to the CCR, and establishes the connections necessary to perform the test. Once the acknowledgment has been received, a test pattern may be sent over the proposed virtual path connection identifier.

		Figure 9.88

		Consistency Check End (CCE)

		This parameter indicates the end of a consistency check. It can only be sent when the consistency check has been completed. The consistency check end (CCE) is treated as an acknowledgment that the test has been completed.

		Figure 9.89

		Consistency Check End Acknowledgment (CCE)

		This is sent in response to a consistency check end message. It indicates the end of a test. The acknowledgment cannot be sent until the test flow has been stopped.

 

Broadband Parameters

		Following is a description of the parameters that have been identified for usage in broadband ISUP. The association of these parameters to specific message types is shown in the previous section.

		Access Delivery Information

		This information indicates that a setup message (ISDN protocol) was generated by the destination. Only one bit in this octet is used, the rest is for future definition. This parameter is defined in the ITU-TS standards but not in the ANSI standards.

		Additional Calling Party Number

		This parameter provides additional address information required for certain supplementary services. Typically, another exchange or another network entity will be providing the supplementary service, requiring additional calling party address information from the other entity. The same format as the calling party address is used. This parameter is defined in the ITU-TS standards but not in the ANSI standards.

		Additional Connected Number

		This parameter is sent in the backward direction and is used in the same manner as the additional calling party number. The difference is this parameter is associated to an additional connected party number. The same format as the additional calling party number is used. This parameter is defined in the ITU-TS standards but not in the ANSI standards.

		ATM Adaptation Layer (AAL) Parameters

		This parameter is used to indicate which adaptation services will be required for the call. This information is of use to both the local exchanges, who will be providing the services, as well as the subscriber, who will be providing the end-point connection. The originating subscriber will be providing this information, based on the type of data that they will be sending, and depending on the type of source network being used at the originating subscriber's premise. Adaptation allows protocols such as Ethernet and Token Ring to interface to BISDN or ATM circuits seamlessly and transparently. The header information is stripped and encapsulated into an ATM header, then transported across the network to its destination, where it can then be reassembled to the destination network.

		ATM Cell Rate

		This information is used by the receiving exchange in setting up the ATM circuit. The receiving exchange must know how many cells per second are needed for this particular call to be successful. The originator will specify the transmission rate through the BISDN interface using the BISDN setup message, which maps to the SS7 IAM message.

		Automatic Congestion Level

		When an exchange reaches a specified level of congestion, it will use this parameter to indicate which level of congestion it has reached to the opposite exchange. The message is not propagated through the network, and is addressed to the adjacent exchange with which a connection has been established.

		Backward Narrowband Interworking Indicators

		This parameter identifies whether or not ISDN is used as the interface by the subscriber, and whether or not ISUP is available end to end within the SS7 network.

		Broadband Bearer Capability

		This parameter is used to indicate to the adjacent exchange how much bandwidth will be needed on the subscriber interface (BISDN interface) to accommodate the call. This applies to the bearer channel only, and has no meaning to the signaling network.

		Broadband Low Layer Information

		The parameters within this parameter are defined in the Q.2931 ITU-TS standards. This is used to ensure compatibility at the lower layers of the protocol stack at the subscriber interface. They are sent to the distant exchange to ensure the distant exchange is compliant.

		Broadband High Layer Information

		Like the low layer information parameter, this parameter and its contents are defined by ITU-TS Q.2931. The purpose is to ensure compatibility at the higher layers of the protocol stack at the subscriber interface at the distant end.

		Call Diversion Information

		When a call attempt is unsuccessful, this parameter is used to determine what type of treatment to provide for an attempted call. In some cases, an announcement may be requested, while in others, a busy tone or some other service tone may be used. This parameter is defined in the ITU-TS standards but not in the ANSI standards.

		Call Diversion May Occur

		Used to indicate that a call diversion may be indicated in a later message. This is necessary when interworking with narrowband ISDN (NISDN) networks. This parameter is defined in the ITU-TS standards but not in the ANSI standards.

 

Call History Information

		The purpose of this parameter is to provide a means for advising the distant exchange as to how long a call took to reach its destination. This is accomplished by providing a time value, sending it to the distant exchange, and the distant exchange comparing the time to its own real-time clock. The difference is considered propagation delay, which is sent to the originating exchange for processing. This parameter is defined in the ITU-TS standards but not in the ANSI standards.

		Called Party's Indicators

		This is used to identify the type of called party, such as normal subscriber or pay phone, and is used to determine if special treatment should be given to the call (such as in the case of a pay phone).

		Called Party Number

		This parameter provides the called party number, just as it does in normal ISUP. The called party number now includes a screening parameter, which is used to indicate whether or not the called party number is to be presented or screened from view. The telephone company is allowed access to the number for routing purposes, but if the number is to be screened, they cannot provide the number to the subscriber. This is used with certain services (such as 800 services) where the called party may not know what number the calling party dialed. The number would then be displayed to them, allowing them to determine how the call should be answered.

		Called Party Subaddress

		This information is also defined in ITU-TS Q.2931. This parameter carries the information defined in that standard through the SS7 network for delivery to the distant exchange.

		Calling Party Number

		This is sent in the forward direction during a call setup procedure to identify the calling party. The presentation parameter determines whether or not the calling party number may be displayed to the called party. If not, the calling party number cannot be transferred to the broadband ISDN interface.

		Calling Party's Category

		This parameter identifies the origin of the call, i.e., pay phone, data terminal, or an ordinary subscriber. The parameter also provides operators with a language indicator to indicate which language they should use when answering the call. Spanish, Russian, French, English, and German are presently defined within the protocol. Other languages would have to be defined by the agencies using the network and agreed upon mutually. The protocol provides additional codes to support network-defined languages.

		Calling Party's Subaddress

		Same as the called party's subaddress, but sent in the opposite direction.

		Carrier Identification Code

		This parameter is used to identify the carrier that a subscriber has selected. It is sent in the forward direction during call setup.

		Carrier Selection Information

		This identifies how the carrier selection code was selected; by the subscriber dialing digits or through preselection.

		Cause Indicator

		This is used when a call has failed or has been cleared for any reason.

		Charge Indicator

		It is sent in the backward direction to indicate to the originating exchange whether or not a call is chargeable or not chargeable, based on the destination and the called party number.

		Charge Number

		It provides the number to be billed for a call and is sent only in the forward direction.

		Closed User Group Information

		Currently, there are no procedures defined in ANSI or Bellcore networks for this parameter. A closed user group treats a group of numbers as if they were PBX extensions, much in the way Centrex treats a group of numbers as belonging to a business group. The user group can then be assigned specific features and privileges, allowing them to call within the group, but possibly blocking them from outside access.

		Connected Line Identity Request Indicator

		This is sent in the forward direction to indicate a request for identity of the connected number, rather than the called number (such as in the case of a forwarded call). Currently there are no procedures defined in ANSI or Bellcore networks.

		Connected Number

		While there are no procedures defined in U.S. networks for this parameter, its intended use is to identify the number to which a forwarded call was actually connected.

 

Connected Subaddress

		This parameter is used along with the connected number, and provides subaddress information according to the ITU-TS Recommendation I.330. As mentioned in the connected number description, these two parameters are used to identify which number a call was eventually terminated to such as in the case of a forwarded or a transferred call.

		Connection Element Identifier

		This information is sent in the forward direction to identify the ATM virtual connection. In the event that the originating exchange does not have any virtual connections within its control available, this parameter would be sent by the destination exchange indicating which virtual circuit it has assigned for the requested call.

		Consistency Check Request Information

		This information is used to indicate the result of the consistency check. The consistency check is like the continuity check used in normal ISUP procedures, but because of the nature of broadband, continuity tests can no longer apply. The consistency check is used instead, and is capable of testing the assignment of the virtual connection as well as the ability to transmit data through that virtual connection.

		Destination Signaling Identifier

		This parameter is used to associate the signaling connection with a virtual connection. This will most likely be used when B-ISUP is used in a fully associated signaling configuration.

		Echo Control Information

		As in the normal ISUP procedures, this parameter indicates whether or not echo control is required for half of the circuit or all of it.

		Egress Service

		This parameter provides information about the network of the terminating exchange.

		Forward Narrowband Interworking Indicator

		When interworking with a narrowband ISDN interface, this parameter provides information in the forward direction regarding the signaling abilities on the connection.

		Generic Address

		This is used in supplementary services, and can identify a destination number (dialed number).

 

Generic Digits

		These digits can be account codes, authorization codes, or any type of number used in supplementary services.

		Generic Name

		This parameter provides specific name-related information used in supplementary services.

		In-band Information Indicator

		This parameter is used to indicate that in-band signaling information or an appropriate pattern is available on the connection specified.

		Jurisdiction Information

		This is the same as the JIP parameter used in ISUP. Provides the LRN of the originating party to be used by billing systems when the calling party number has been ported to another service provider.

		Location Number

		This parameter provides the same information as the called or calling party number, but is associated with a user within a NISDN connection. This is only used when interworking with narrowband ISDN networks.

		Maximum End-to-end Transit Delay

		This parameter indicates the maximum transit delay allowed for a message traveling through the network. The delay maximum is for an end-to-end transmission.

		MLPP Precedence

		Used primarily with military networks, this parameter indicates the level of precedence supported for the connection. The Multilevel Precedence Preemption (MLPP) supplementary service is used in military installations to allow officers of higher rank to seize a trunk in use based on rank. This feature used to be limited to large AUTOVON systems installed on military bases, but is now offered through telephone service providers.

		MLPP User Information

		This is a one-octet parameter, which uses only one bit in the entire octet. That one bit is used to indicate whether or not the called party is an MLPP user.

		Narrowband Bearer Capability

		During the setup phase of a connection, the originator may request for a specific bandwidth. In some cases, the originator may allow a lower bandwidth for the connection, only if the requested bandwidth is not available. This is referred to as the fallback bandwidth. This parameter is used to indicate the fallback bandwidth that has been allocated for the call connection.

 

Narrowband High Layer Compatibility

		This parameter is used to ensure compatibility between two exchanges. When an exchange requests service to a specific exchange, it may request a specific level of service, or allow fallback to an available service. In the event the requested service is not available, and the fallback service is assigned, this parameter notifies the distant exchange of the fallback service assignment so that it may set up its end to be compatible.

		Narrowband Lower Layer Compatibility

		This parameter is like the previous parameter, but is concerned with compatibility at the lower layers rather than the upper layers. This also ensures compatibility at both ends of the exchange.

		National/International Call Indicator

		It is used to indicate to a national exchange that the origin of the call is from a national network or an international network. The call handling procedures for an international call are somewhat different than they are for a national call.

		Notification

		This parameter may be sent in either direction, and is used to notify the other exchange regarding supplementary services such as call diversion procedures. Call diversion procedures encompass the use of service tones and announcements if a call cannot be completed (such as in the case of a cellular subscriber being away from their car, and the cellular phone being turned off).

		Notification Indicator

		It is used with supplementary services to send notification to the user.

		OAM Traffic Descriptor

		This parameter indicates the cell rate that is required by Operations Administration and Maintenance (OAM) traffic on a specified virtual connection.

		Original Called Number

		When a call has been redirected, whether through forwarding or a transfer, this parameter identifies the original called party number. The connected called number will also be provided through that parameter. This is used when interworking with narrowband ISDN connections.

		Originating Line Information

		This information provides the toll class of service for a call. Sent only in the forward direction.

 

Origination ISC Point cCode

		This information is provided in an IAM to indicate the originating point code of an international ISC.

		Origination Signaling Identifier

		It is sent by the originator of a signaling or control message to identify the association with the distant signaling connection.

		Originating Facility Identifier

		This information is only used when intranetworking and identifies the outgoing facility selected to reach the adjacent network.

		Parameter Compatibility Information Parameter

		This information is used to inform the receiver how to interact in the event it receives an incorrect parameter it cannot recognize.

		Progress Indicator

		This is used to indicate an event which has taken place during the lifetime of a call. This is defined in Q.9231.

		Propagation Delay Counter

		While being transferred through the network, this parameter is accumulating timer information. Each time it passes through a network entity, the timer information is updated in 1 ms increments. By the time it reaches its final destination, the destination exchange can determine the amount of propagation delay experienced by the message.

		Redirecting Number

		When a call is forwarded to another number, this parameter identifies the number that forwarded the call. For example, a number may be forwarded to another number, which in turn has diverted the call to yet another number. The number that provided the diversion would be indicated in this parameter.

		Redirection Information

		This parameter is also related to call diverting, or call forwarding. When a call is redirected to another number, this parameter indicates the nature of the redirection. For example, if a mobile subscriber is not available, then the call is diverted to an announcement. This parameter would then provide information as to why the call was diverted and the nature of the call.

		Redirection Number

		When a call is being diverted to another number, this parameter identifies the number to which the call has been diverted. This parameter is sent in the backward direction.

		Redirection Number Restriction

		Also related to diverted calls, this parameter identifies whether or not the diverted user allows presentation of the telephone number. Because of legislature in many states, telephone companies must provide the option of screening the calling party number identification to the called party. This parameter indicates whether or not that is the case.

		Resource Identifier

		When a resource has been blocked or unblocked (such as an announcement), this parameter indicates which resource it applies to.

		Signaling Identifier

		The signaling identifier allows each exchange to assign independently of one another a signaling association, and correlate messages with each signaling association. A signaling association is received over a signaling identifier.

		Segmentation Indication

		When a message is segmented into several messages, this parameter is used to indicate that the message is segmented and that there is additional segmentation information.

		Special Processing Request

		This parameter is sent only in the forward direction when special processing is required at the terminating exchange. Special processing includes everything from verifying authorization codes to translating private network numbers.

		Subsequent Number

		When the called party requires additional information this parameter is used to provide the additional numbers or subsequent addresses.

		Suspend/Resume Indicators

		This parameter is sent in either the suspend or resume message to indicate whether or not the suspend or resume message was initiated by an ISDN subscriber or by the network. The suspend is used to temporarily place a circuit into a hold state, such as when the subscriber invokes another feature such as call waiting by performing a hook flash. The resume is used to indicate that the circuit is now ''reconnected" and transmission can resume.

		Transit Network Selection

		When an IAM is sent, this parameter indicates which transit network, if any, is to be used to carry the message. A transit network is one that is used to access another carrier's network when network boundaries must be crossed.

		User-Network Interaction Indicator

		This parameter is sent in the backward direction when additional information is needed from the calling party to process a call.

 

User-to-user Indicators

		This parameter carries the information defined in ITU-TS Q.2931, when the users at each end of the connection have information to share. The indicators are used to indicate that such information exists, while the following information parameter provides the actual information. The indicators also specify whether or not a reply is to be sent.

		User-to-user Information

		This parameter is used to send information from a user to the user at the remote exchange. The information is passed transparently through all intermediate exchanges.