User:Kayclose/sandbox

'''

Need for ISUP Cause Values (CV) for Fast Trouble-shooting
''' 1.0	Introduction The release cause values in the troubleshooting of ISUP layer errors of the SS7 signaling systems is very vital in that for every single call originated or terminated between 2 TDM (time division multiplexing) interconnected peer offices are teared down completely via REL (codes and cause values) messages which reveals the nature of the Release be it as a result of “normal call clearing”, “network out of order”, “Invalid number format or address incomplete”. These releases and their various categorizations have been reviewed in this paper by the simulations conducted between 2 ISUP peers and results collected and analysed. 2.0 ISUP Overview As stated and explained in details on the ITUT recommendation Q. 761 series, the ISDN User Part (ISUP) is responsible for setting up and releasing trunks used for inter-exchange calls. As its name implies, ISUP was created to provide core network signaling that is compatible with ISDN access signaling. The combination of ISDN access signaling and ISUP network signaling provides an end-to-end transport mechanism for signaling data between subscribers. Today, the use of ISUP in the network has far exceeded the use of ISDN on the access side. The primary benefits of ISUP are its speed, increased signaling bandwidth, and standardization of message exchange. It ultimately uses trunk resources more effectively. The difference in post-dial delay for calls using ISUP trunks is quite noticeable to the subscriber who makes a call that traverses several switches. 2. 1 ISUP Call Flow The ISUP call flow process as achieved through the Network Switching System contains different message exchanges also known as H1/H0 header levels which logically describes how the complete call origination is initiated. Depending on the particular call, a switch personnel could tell from the information contained in the flow if the call a successful one or not.

2.2 Successful call Scenario Using a 2-number A/ B scenario, a successful call can be simulated 1st when the B number is dialed on A’s phone without further number conversion sends out an IAM (initial address message). This contains information that is necessary to establish the call connection such as the call type, called/calling party number, and information about the bearer circuit. It responds with an Address Complete Message (ACM). The ACM indicates that the call to the selected destination can be completed. For example, has been determined to be in service and not busy as the case may be. Once the ACM has been sent, ringing is applied to the terminator and ring back is sent to the originator. When the terminating set goes off-hook, an Answer Message (ANM) is sent to the originator and conversation begins. The call ends which with a release message sent back to the B-number with a cause value (Normal call clearing).

1.0	Introduction The release cause values in the troubleshooting of ISUP layer errors of the SS7 signaling systems is very vital in that for every single call originated or terminated between 2 TDM (time division multiplexing) interconnected peer offices are teared down completely via REL (codes and cause values) messages which reveals the nature of the Release be it as a result of “normal call clearing”, “network out of order”, “Invalid number format or address incomplete”. These releases and their various categorizations have been reviewed in this paper by the simulations conducted between 2 ISUP peers and results collected and analysed. 2.0 ISUP Overview As stated and explained in details on the ITUT recommendation Q. 761 series, the ISDN User Part (ISUP) is responsible for setting up and releasing trunks used for inter-exchange calls. As its name implies, ISUP was created to provide core network signaling that is compatible with ISDN access signaling. The combination of ISDN access signaling and ISUP network signaling provides an end-to-end transport mechanism for signaling data between subscribers. Today, the use of ISUP in the network has far exceeded the use of ISDN on the access side. The primary benefits of ISUP are its speed, increased signaling bandwidth, and standardization of message exchange. It ultimately uses trunk resources more effectively. The difference in post-dial delay for calls using ISUP trunks is quite noticeable to the subscriber who makes a call that traverses several switches.

2. 1 ISUP Call Flow The ISUP call flow process as achieved through the Network Switching System contains different message exchanges also known as H1/H0 header levels which logically describes how the complete call origination is initiated. Depending on the particular call, a switch personnel could tell from the information contained in the flow if the call a successful one or not.

2.2 Successful call Scenario Using a 2-number A/ B scenario, a successful call can be simulated 1st when the B number is dialed on A’s phone without further number conversion sends out an IAM (initial address message). This contains information that is necessary to establish the call connection such as the call type, called/calling party number, and information about the bearer circuit. It responds with an Address Complete Message (ACM). The ACM indicates that the call to the selected destination can be completed. For example, has been determined to be in service and not busy as the case may be. Once the ACM has been sent, ringing is applied to the terminator and ring back is sent to the originator. When the terminating set goes off-hook, an Answer Message (ANM) is sent to the originator and conversation begins. The call ends which with a release message sent back to the B-number with a cause value (Normal call clearing).

2.3 Unsuccessful Call Scenario An IAM message from the A number to the B number is exchanged but without an ACM. (e.g. with the assumption that the B-number is busy). After receiving the IAM, B-Number’s exchange checks the status of the destination line instead of an ACM, as in the above case, a REL message with a cause value of User Busy is sent to A’s exchange, indicating that the call cannot be set up. While this example shows a User Busy condition, there are many reasons that a call set-up attempt might be unsuccessful.

3.0 Release (REL) OVERVIEW Release codes are used to identify and debug any events occurring in ISDN User Part signaling. Every event in ISUP signaling generates a release code number. Even for a normal ISUP call, a release code is generated. There are lot of applications developed based on the release code from ISUP signaling. Similarly Telecom operators trace for Release codes to debug any call failures. Identified by the “Cause Values” which are the messages generated by the network, which the equipment have translated to the associated phrases. These cause values traditionally numbering 127 with the common or mostly occurring ones to be highlighted further in this paper. There are 7 different classes of Cause values with some identified cause numbers grouped as follows:

3.1 Normal •	Cause No. 1 - Unallocated number: This cause indicates that the called party cannot be reached because, although the called party number is in a valid format, it is not currently allocated •	Cause No. 16 - Normal call clearing: This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. under normal situations, the source of this cause is not the network •	Cause No. 17 - User busy: This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call. •	Cause No. 20 – Subscriber absent: This cause is used when a mobile station has logged off, radio contact is not obtained with a mobile station or a personal telecommunications user is temporarily not addressable at any user-network interface. •	Cause No. 27 – Destination out of order: This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signal message was unable to be delivered to the remote party; e.g. a physical layer or data link layer failure at the remote party, or user equipment off-line. Cause No. 28 - Invalid number format, address incomplete): This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete. or this cause indicates the user should be returned a Special Intercept announcement 3.2 Resource unavailable •	Cause No. 34 - No circuit/channel congestion: This cause indicates that there is no appropriate circuit/channel presently available to handle the call. •	Cause No. 41 - Temporary Failure: This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user may wish to try another call attempt almost immediately. May also indicate a data link layer malfunction locally or at the remote network interface or that a call was cleared due to protocol error(s) at the remote network interface. •	Cause No. 42 - Switching Equipment Congestion: This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic. 3.3 Service or option not available •	Cause No. 50 – Requested facility not subscribed: The cause is used to report that the user cannot use this feature because s/he has not subscribed to it. •	Cause No. 52 – Outgoing calls barred: This cause indicates that because of call screening provided by the network, the calling user is not permitted to make a call. •	Cause No. 57 – Bearer capability (Data/voice) not authorized: This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use it. This is a common problem caused by wrong provisioning of the line at the time of installation 3.4 Service or option not implemented •	Cause No. 63 – Service or option not available, unspecified: This cause is used to report a service or option not available, only when no other cause in this class applies. •	Cause No. 65 - Bearer Capability not implemented : This cause indicates that the equipment sending this cause does not support the bearer capability requested. •	Cause No. 66 – Channel type not implemented: This cause is returned when the called party has reached a channel type not supported.

3.5 Invalid message; e.g. parameter out of range •	Cause No. 88 - Incompatible destination: This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility or other compatibility attributes (e.g. data rate, DN subaddress) which cannot be accommodated. This call can also be returned by a switch to a CPE when trying to route a call to an incompatible facility, or one without data rate. •	Cause No. 91 - Invalid transit network selection: This cause indicates that an Invalid transit network selection has been requested. 3.6 Protocol error •	Cause No. 102 - Timeout disconnect (Recovery on timer expiration): This cause indicates that a procedure has been initiated by the expiry of a timer in association with error handling procedures.

3.7 Interworking class •	Cause No. 127 -Internetworking, unspecified: This cause indicates that an interworking call (usually a call to SW56 service) has ended. May also be seen in the case of a non specific rejection by your long distance carrier (try again at a different rate).

Fig 3.1 Sample Release (REL) and categories

4.0 Data Analysis and failure resolutions Realtime data analysis was processed by monitoring ISUP call processing between 2 nodes over TDM for 30-mins of a 1 hour period.The call information gathered and processed shows the frequency of various cause values and their percentage of occurrence within this period.

This analysis has helped in the following ways: 1.	To review the overall traffic performance. 2.	To understand the frequency of normal or abnormal release occurrence. 3.	To identify individual cause value classes. 4.	To further troubleshoot call failure in where abnormal releases occurred.

5. CONCLUSION ISUP protocol which belong to the transport, session and application layer of the C7/SS7 has provided a transparent approach towards the resolution of all interface call related problems from the cue point of RELEASE cause codes, values and class.

From the clear understanding of the descriptions of various cause values as enumerated in this paper, a different approach to call analysis have been arrived at which in turn will beneficial to switch engineers, data analysts and core network planners.