A method is disclosed for detecting and diagnosing faults in a network. The network has a plurality of nodes through which switched virtual connections can be established. First, all attempts at establishing routes through the network are recorded. Then, the location of a failure is determined by analyzing the attempted routes.
|
0. 19. A method of collecting routing information when attempting to set-up a virtual connection through a network comprising the steps of:
a) attempting to establish a virtual connection from a source to a destination through a plurality of nodes in the network providing alternate routes to said destination by exchanging set-up messages;
b) collecting routing information from each node identifying at least the node and trunk group visited on each attempted route through the network; and
c) returning the routing information to the source in the set-up messages.
0. 23. A system for collecting routing information when attempting to set-up a virtual connection through a network comprising the steps of:
a) means to establish a virtual connection from a source to a destination through a plurality of nodes in the network providing alternate routes to said destination by exchanging set-up messages;
b) means to collect routing information from each node identifying at least the node and trunk group visited on each attempted route through the network; and means to return the routing information to the source in the set-up messages.
7. A method of detecting and diagnosing faults in a network having a plurality of nodes through which switched virtual connections can be established, comprising the steps of:
a) entering a diagnostics mode for a given user when a suspected fault is detected;
b) attempting to establish a virtual connection originating at said given user through the network to a destination user via a plurality of alternate routes;
c) collecting diagnostics data for each attempted route through the network to said destination user;
d) analyzing the said diagnostics data to identifying the source of a failure; and
e) automatically deactivating said diagnostics mode after a predetermined number of connection setups originating from said given user.
8. A method of detecting and diagnosing faults in a network having a plurality of nodes through which switched virtual connections can be established, comprising the steps of:
a) entering a diagnostics mode for a given user when a suspected fault is detected;
b) attempting to establish a virtual connection originating at said given user through the network to a destination user via a plurality of alternate routes;
c) collecting diagnostics data for each attempted route through the network to said destination user, said diagnostics data being carried in a call information element of a setup message; and
d) analyzing the said diagnostics data to identify the source of a failure; and
wherein said information element is a call trace element.
13. A packet switched data communications network, comprising:
a) a plurality of interconnected network nodes;
b) a plurality of users connected to at least some of said network nodes;
c) means for attempting to establish virtual connections between users over a plurality of alternate routes through said network by exchanging call set-up messages through a plurality of said nodes in the network;
d) means at each node on said alternate routes for inserting diagnostics data identifying at least the node and physical trunk group visited in said call set-up messages while in a diagnostics mode and returning said diagnostics data to an originating node; and
e) diagnostic means for analyzing said diagnostics data returned in said call set-up messages to identify the source of a failure.
18. A packet switched data communications network, comprising:
a) a plurality of interconnected network nodes;
b) a plurality of users connected to at least some of said network nodes;
c) means for attempting to establish virtual connections between users over a plurality of alternate routes through said network;
d) means for recording, in a diagnostic mode, attempts at establishing routes through said network; and
e) diagnostic means for analyzing said recorded attempts to identify the source of a failure;
wherein said nodes include service cards having a call control unit and a signalling stack for setting up a virtual connection, and a service card managing a virtual connection collects diagnostics information for said recorded attempts at establishing routes through said network.
1. A method of detecting and diagnosing faults in a network having a plurality of nodes through which switched virtual connections can be established, comprising the steps of:
a) entering a diagnostics mode for a given user when a suspected fault is detected;
b) attempting to establish a virtual connection originating at said given user through a plurality of said nodes on in the network to a destination user via a plurality of alternate routes by exchanging call set-up messages through the network;
c) collecting diagnostics data from each node identifying at least the node and physical trunk group visited on each attempted route through die the network to said destination user and returning said diagnostics data in said call set-up messages; and
d) analyzing the said diagnostics data to identify the source of a failure.
2. A method as claimed in
3. A method as claimed in
4. A method as claimed in
6. A method as claimed in
9. A method as claimed in
10. A method as claimed in
11. A method as claimed in
12. A method as claimed in
14. A packet switched network as claimed in
15. A packet switched network as claimed in
16. A packet switched network as claimed in
0. 20. The method as defined in
0. 21. The method as defined in
0. 22. The method as defined in
|
|||||||||||||||||||||||||||||||||
This invention relates to the field of digital networks, for example, asynchronous transfer mode (ATM) networks and, more particularly, to a methodology for detecting and diagnosing switched connection failures in a signaling network when attempting to setup a call.
Network switches, controlled by signaling software, can dynamically setup end-to-end connections across the network, the instance, Switched Virtual Channel (SVC) or Soft Permanent Virtual Channel (SPVC) connections in an ATM network. Sometimes these connections fail to route successfully.
Today's signaling software provides very simple cause and diagnostics information to aid in trouble shooting failed call attempts. Often, the cause and diagnostics are inadequate to trouble shoot the root cause of the problem as only a single reason is provided as to the failure. Much manual work, often involving more than one operations person, must be done to actually locate the root cause of the problem. This becomes very costly in terms of network resources and time.
More detailed connection diagnostics are required to aid in troubleshooting in these situations.
An object of the present invention is to alleviate the prior art problem.
According to the present invention there is provided a method of diagnosing faults in a network having a plurality of nodes through which switched virtual connections can be established, comprising the steps of recording all attempts at establishing routes through the network; and analyzing the attempted routes to identify the source of a failure.
The switched connection diagnostics functionality, embodying the present invention, collects details in call processing messages for each switch and physical trunk visited plus rejection causes for every attempted route during the call setup phase. The collected information is returned in the call processing messages back to the source switch which in turn presents this information to network operators. These details enable the network operators to easily isolate and troubleshoot problems.
This invention enables signaling software to gather detailed information for a switched connection for every leg of a call setup rather than simply providing one reason as to routing failure, thus allowing quick problem resolutions with minimal effort.
The invention also provides a packet switched data communications network, comprising a plurality of interconnected network nodes; a plurality of users connected to at least some of said network nodes; means for attempting to establish virtual connections between users over a plurality of alternate routes through said network; and means for recording, in a diagnostic mode, attempts at establishing routes through said network; and diagnostic means for analyzing said recorded attempts to identify the source of a failure.
The invention will now be described in more detail, by way of example, with reference to the accompanying drawings, in which:
In
A switched virtual channel (SVC) connection can be setup from Customer Premise Equipment 1 (CPE-1) to Customer Premise Equipment 2 (CPE-2) using users uA and uD for the calling and called addresses, respectively. Alternatively, a soft permanent virtual channel (SPVC) connection can be setup from the port on A where CPE-1 is attached at uA to the port on D where CPE-2 is attached at uD. If a routing problem occurs with either the SVC or SPVC connection setups, then the following steps should be taken to diagnose the problem depending on the type of connection.
SVC Case:
A customer at CPE-1 complains that its application is not functioning. The Service Provider turns on or activates the switched connection diagnostics for use uA, and instructs the customer to try the application again. The SVC connection setup is retried and switched connection diagnostics are collected. The results from the diagnostics are analyzed. By using the routing reject points, the Service Provider can locate and then correct the problem in the network. The Customer retries his application and is once again back in service.
SPVC Path Case #1—Path is Waiting for Resources:
The Service Provider configures an SPVC path from user uA to user uD, and connects it. The path setup enters a Waiting for Resources state. The Service Provider initiates the switched connection diagnostics for the specific problematic SPVC path. The SPVC path is retried and switched connection diagnostics are collected. The results from the diagnostics are analyzed. By using the routing reject points, the Service Provider can locate and then correct the problem in the network. The SPVC path is retried. The call is completed and now enters the connected state.
SPVC Path Case #2—Path is Connected:
The Service Provider configures an SPVC path from user uA to user uD, and connects it. The path enters the connected state. The Service Provider desires to determine the reason why the path took the route it did. The Service Provider initiates the switched connection diagnostics for the specific SPVC path.
A bridge and roll optimize operation is performed on the path in order to gather switched connection diagnostics for the path. International application PCT/CA97/00507, filed Jul. 17, 1997, describes an implementation of the bridge and roll operation. This operation may be service affecting. However, if it is completed close to the instance at which the path was first connected, there is a high probability that a more optimal route does not exist. The results are analyzed and routing reject points can then be further investigated to discern the cause of the path's present routing.
For a specific example of an application of the switched connection diagnostics, assume each switch has routing tables allowing uA to route an SVC to uD, and assume tgCD has no remaining bandwidth for the SVC. The SVC would start from A, use tgAB (assume primary trunk group) to get to B, then proceed to use tgBC to get to C. Once at C, routing determines that tgCD is full and cranks back to B. B then cranks back to A as there are no other routes from B to D. A crankback occurs when a node passes a call back to a previous node because it is unable to establish an onward connection. From A, the alternate trunk group tgAE is used. From E, tgEC is used, and again at C, routing determines tgCD is full and cranks back to E. E then cranks back to A as there are no other routes from E to D. Now A has exhausted its routes so the SVC is released back to CPE 1.
Switched connection diagnostics record all routes attempted, i.e. A, tgAB, B, tgBC, C, reject reasons (cause and diagnostics), A, tgAE, E, tgEC, C, reject reasons. If this list is followed, it can be determined that all roads lead to C, but there is NO usable route from C to D. The next step in the procedure is to focus diagnostics efforts at C to determine why tgCD is not usable.
Having regard specifically to SVC switched connection diagnostics, SVCs are setup from user terminal to user terminal across the network. The point of attachment into the network from the user terminal defines the entry and exit points for the SVC. The point of attachment is defined by a Call Processing User and its physical access i.e. its Trunk Group and the controlling signalling link. The switch routes an SVC from the User at the entry point to the User at the exit point. Routing tables, either static or dynamic, present in each node steer SVC setup messages from the source User to the destination User. When routing chooses a route, i.e. a trunk group, the signalling message is sent out on the signalling link controlling the trunk group.
For SVCs, switched connection diagnostics are provided on a per User basis, and may be turned on (activated) or off (de-activated). The default for diagnostics is off, awaiting activation.
Every calling User that originates an SVC when switched connection diagnostics are activated will gather diagnostics information during call setup. This enables an end-user application to startup. The end-user has the opportunity to signal potentially more than one SVC, and diagnostics will gather information on all SVCs originated from the application.
If diagnostics are not de-activated for a User after an SVC routing problem has been diagnosed, then call setup performance for the User will be degraded as unwanted diagnostic information is collected for every call on the User. To guard against inadvertently leaving switched connection diagnostics active, the diagnostics are gathered for a predetermined number of connection setups, for example the first 10 SVCs/SPVC paths setup for the User. After 10 calls for the User, the switched connection diagnostics deactivates itself.
If switched connection diagnostics are active for a User, and that User is the destination of a call, there is no effect. Switched connection diagnostics applies only to calls originated by a User.
In the case of SPVC switched connection diagnostics, the SPVC path definition contains the source, destination and administrative information for connection setup. The SPVC connection setup procedure initiates an SVC from the source endpoint towards the destination endpoint, and therefor uses the same routing procedures as SVCs. In one reference model, the SPVC path endpoints are the ports on the switch where the customer premise equipment (CPEs) are attached. The Users, i.e. uA and uD, plus port and endpoint information define the endpoints for the SPVC path. Again, routing uses routing tables, either static or dynamic, present in each node to steer SPVC setup messages from the source User to the destination User.
Switched connection diagnostics are provided on a per SPVC path basis, and may be turned on or off for the next SPVC path setup attempt. By default, the diagnostics are off. Once switched connection diagnostics have been turned on for an SPVC path, the next time the SPVC path is setup, diagnostics information are collected for that SPVC.
When an SVC or SPVC call is being setup, routing attempts to route the call from source to destination. It uses loop detection and crankback optimizations to route the call. In this process, many different routes may be attempted. For every route tried, each switch and trunk group traversed is recorded. When a route is rejected, the reason is also recorded. A node management (Node Management Terminal Interface or NMTI) or network management system can interpret this information to illustrate the routing points of failure.
Depending on the circumstances, switched diagnostics may provide more information when employed with hop-by-hop routing to setup a call, in comparison to source routing for call setup. A particular source routing technique is Private Network Node Interface (PNNI), wherein routing tables are regenerated and distributed to all nodes running PNNI. If a node becomes isolated because the physical access to it fails, then all routes to the isolated node are removed from all routing tables. For example, in
Turning to
The first and fourth scenarios are processed by call control which logs diagnostics at this level. However, if scenarios two or three occur, then the diagnostic information must reflect this. If the local end rejects the call, then perhaps the service card servicing the signalling link is overburdened. If the remote end rejects the call, then perhaps the service card at the remote end is overburdened. This information pinpoints perhaps a troubled service card.
Diagnostics are collected on a per service card basis. The service card, that manages the SVC User and SPVC path, collects switched connection diagnostics information when diagnostics is enabled. The service card can store switched connection diagnostics information for a predetermined number, say only 50 SVC or SPVC path setup attempts. The 50 most recent setup attempts are stored. This should be sufficient to allow several external network management requests to initiate switched connection diagnostics requests, then subsequently collect the results.
The enhanced signalling used to carry diagnostics information will now be described in more detail. Enhanced signalling is achieved by using information elements (IEs) defined to be in “Codeset 6”, information elements specific to the local network.
The ITU-T Q.2931 signalling specification standardized coding format for information elements is followed. Therefore, all information elements contain an Information Element Identifier, Length and Instruction fields as shown below.
8
7
6
5
4
3
2
1
Octet
Information Element Identifier
1
1
0
0
1
0
0
0
1
2
Ext
Coding
Fla
Res
1E Action Ind
Std
g
Length
3
Length (continued)
4
The contents of the IE instruction field are always coded with a Flag of ‘follow explicit instructions’ and an IE Action Indicator of ‘discard information element and proceed’.
New information element identifiers are allocated so as to not collide with “Codeset 0” identifiers. Codeset 6 information elements are preceded in a message by a Broadband Locking Shift information element. Non locking shift procedures are not supported.
8
7
6
5
4
3
2
1
Octet
0
1
1
0
0
0
0
0
1
Broadband Locking Shift IE Identifier
1
0
0
1
0
0
0
1
2
Ext
Coding
Fla
Res
IE Action Ind
Std
g
Length of Broadband Locking Shift IE
3
Length of Broadband Locking Shift IE
4
(continued)
1
0
0
0
0
1
1
0
5
Ext
Spare
Codeset
Identifier
The purposes of the Locking Shift information element is to indicate the new active Codeset of succeeding information elements. The specific Codeset remains active until another locking shift is encountered indicating the new active Codeset. Coding Standard (octet 2) is used to indicate ITU-T standardized coding. The Flat (octet 2) indicates to follow explicit instructions of the action indicator. The IE action indicator (octet 2) indicates to discard information element and proceed. The Codeset Identifier (octet 5) identifies the Codeset, in this case Codeset 6.
Coding Rules as specified by the ITU-T and ATM Forum are followed. The following Table specifies information elements used for enhanced signalling. The identifier, maximum length and maximum number of occurrences are given for each information element.
Bits
Max Length
Max no of
8
7
6
5
4
3
2
1
Information Element
(Bytes)
Occurrences
0
0
0
0
0
0
1
1
Call Trace
1476
1
0
1
1
0
0
0
0
1
Broadband locking shift
5
1
There are four particular messages which are used for enhanced signalling procedures: Connect, Setup, Release, and Release Complete messages. Each can include the Broadband Locking Shift information element, followed by a Call Trace information element which may have a length ranging from 20 to 1476 octets. Details of the Call Trace IE a given below.
A Connect message is used to return call trace information to the originating node on a Successful call completion. Both the Release and Release Complete messages are used to transfer the reason for a routing failure. Information about the routing failure can be carried in either a Cause information element or optionally the Call Trace information element. Only the cause of the routing failure is carried in the Cause IE whereas the Call Trace IE carries complete information. The Setup message is used to collect call tracing information inside the call trace IE as the message traverses the network.
The purpose of the Call Trace IE is to trace the progress of a call as it traverses the network. The information relating to the node address, port and rejection causes is collected, as well as failure reasons and extra diagnostic information. The Call Trace IE contents form an ordered list representing node traversal information in chronological order. Each asterisked octet group represents a sub-structure and may be repeated in the Call Trace IE, 0 or more times while appearing in any order.
8
7
6
5
4
3
2
1
Octet
0
0
0
0
0
0
1
1
1
Call Trace IE Identifier
1
0
0
1
0
0
0
1
2
Ext
Coding
Fla
Res
IE Action Ind
Std
g
Length of Call Trace IE
3
Length of Call Trace IE (continued)
4
0
0
0
0
0
0
0
1
5*
Call Transited Indication
Call Transited Information
5.1*
etc.
0
0
0
0
0
0
1
0
6*
Call Blocked Indication
Call Blocked Information
6.1*
etc.
0
0
0
0
0
0
1
1
7*
Call Blocked After Transmit Indication
Call Blocked After Transmit Information
7.1*
etc.
0
0
0
0
0
1
0
0
Call Completed Indication
Call Completed Information
8.1*
etc.
Each Call Trace IE is comprised of four components: Call Transited Indication, Call Blocked Indication, Call Blocked After Transit Indication, and Call Completed Indication. Each of the aforementioned components has a common structure. This structure consists of the component identifier, the length of the structure, and the component data.
The Call Transited Indication (octet group 5 of Call Trace IE) denotes the successful traversal of a single node in the network. As shown in the format below, both node and port information are included.
8
7
6
5
4
3
2
1
Octet
0
0
0
0
0
0
0
1
Call Transited Indication
5.1
Length
5.2
0
0
0
0
1
0
0
1
5.3
Reserved
Slot Format
Address
Identifier
Identifier
Domain
5.4
Domain (continued)
5.5
Major Node Number
5.6
Major Node Number (continued)
5.7
Inbound Slot Number
5.8
Inbound Slot Number (continued)
5.9
Inbound Port Number
5.10
Inbound Sub-Port
5.11
Inbound Sub-Port (continued)
5.12
0
0
0
0
Outbound
0/1
5.13
Reserved
Selection
Fla
Type
g
Outbound Slot Number
5.14
Outbound Slot Number (continued)
5.15
Outbound Port Number
5.16
Outbound Sub-Port
5.17
Outbound Sub-Port (continued)
5.18
The following list details the individual fields of the Call Transited Indication sub-structure:
The Call Blocked Indication (octet group 6 of Call Trace IE) denotes the failure of a call to traverse a single node in the network. The sub-structure includes node and port information, the ingress port/sub-port as well as the reason for call blockage.
8
7
6
5
4
3
2
1
Octet
0
0
0
0
0
0
1
0
Call Blocked Indication
6.1
Length
6.2
0
0
0
0
1
0
0
1
6.3
Reserved
Slot Format
Address
Identifier
Identifier
Domain
6.4
Domain (continued)
6.5
Major Node Number
6.6
Major Node Number (continued)
6.7
Slot Number
6.8
Slot Number (continued)
6.9
Port Number
6.10
Sub-Port
6.11
Sub-Port (continued)
6.12
Cause Value
6.13
Diagnostics Cause Value
6.14
Diagnostics Cause Value (continued)
6.15
Length of Diagnostics
6.16
Diagnostics
6.17 etc.
The following list details the specific fields of the Call Blocked Indication sub-structure:
The Call Blocked After Transit Indication (octet group 7 of Call Trace IE) denotes a failure of a call to traverse a single node in the network. The sub-structure includes node and port information. In addition, incoming and outgoing port/sub-port (VPI) may be present. The Call Blocked After Transit Indication always contains information to indicate the cause of the route failure at that point in the network.
8
7
6
5
4
3
2
1
Octet
0
0
0
0
0
0
1
1
Call Blocked
After Transit Indication
7.1
Length
7.3
0
0
0
0
1
0
0
1
7.3
Reserved
Slot Format
Address
Identifier
Identifier
Domain
7.4
Domain (continued)
7.5
Major Node Number
7.6
Major Node Number (continued)
7.7
Slot Number
7.8
Slot Number (continued)
7.9
Port Number
7.10
Sub-Port
7.11
Sub-Port (continued)
7.12
Outbound Slot Number
7.13
Outbound Slot Number (continued)
7.14
Outbound Port Number
7.15
Outbound Sub-Port
7.16
Outbound Sub-Port (continued)
7.17
Cause Value
7.18
Diagnostics Cause Value
7.19
Diagnostics Cause Value (continued)
7.20
Length of Diagnostics
7.21
Diagnostics
7.22 etc.
The following list details the specific fields of the Call Blocked After Transit Indication sub-structure:
The Call Completed Indication (octet group 8 of Call Trace IE) denotes the successful traversal of a single node in the network. The sub-structure includes node and port information as shown below.
8
7
6
5
4
3
2
1
Octet
0
0
0
0
0
0
0
1
Call Completed Indication
8.1
Length
8.2
0
0
0
0
1
0
0
1
8.3
Reserved
Slot Format
Address
Identifier
Identifier
Domain
8.4
Domain (continued)
8.5
Major Node Number
8.6
Major Node Number (continued)
8.7
Slot Number
8.8
Slot Number (continued)
8.9
Port Number
8.10
Inbound Sub-Port
8.11
Inbound Sub-Port (continued)
8.12
0
0
0
0
Selection
0/1
8.13
Reserved
Type
Fla
g
Slot Number
8.14
Slot Number (continued)
8.15
Port Number
8.16
Outbound Sub-Port
8.17
Outbound Sub-Port (continued)
8.18
The following list details the specific fields of the Call Completed Indication sub-structure:
In operation, call tracing is established at the exchange originated the call to be traced. At this point, a Call Trace IE is inserted into all calls to be traced. It is only explicitly enabled at the point of origin in the network and is implicitly defined to be active by all other nodes in the network if the Call Trace IE is found to be present.
1. Actions Required at the Originating Exchange:
a) Initiating a Call Trace:
When a new call is initiated, the originating exchange (i.e., switch) checks for the presence of a Call Trace IE in the call setup message. If not existent, a Call Trace IE without components is inserted.
When an outgoing slot, port, or sub-port is selected, the Call Trace IE is modified before the setup message is forwarded. A ‘Call Transited’ component, containing the node address, ingress and egress slot/port/sub-port, is appended to the end of the IE. The point of origin has now been traced as the setup message at the exchange.
A copy of the Call Trace IE with the ‘Call Transited’ structure is saved by the originating exchange.
b) Receipt of a Connect Message:
The originating exchange checks for the presence of the Call Trace IE in the Connect message. If the IE is found, its contents contain a complete trace of -the successful call across the network. The information can be used by the management layer for diagnostic information. The IE is not forwarded to the originating interface if it does not support enhanced signalling.
If the IE is not found, a copy of the Call Trace IE that was saved is added to the Connect message.
2. Actions Required at a Transit Exchange:
a) Receipt of a Setup Message:
Upon successful route selection, the setup message is examined for the presence of a Call Trace IE. If present, a ‘Call Transited’ component, containing the node address, ingress slot/port/sub-port and egress slot/port/sub-port is appended before the message is forwarded to the next exchange while a copy of the Call Trace IE is locally saved.
b) Receipt of a Connect Message:
The Connect message is examined for the presence of a Call Trace IE. If present, the message is forwarded to the preceding exchange without modification to the Call Trace IE.
If the Call Trace IE is absent, the exchange checks for a previously saved copy. If such a copy exists, it is added without modification to the Connect message. The Connect message is then sent to the preceding exchange. In this case, a complete end-to-end call trace is not being performed.
3. Actions Required at the Destination Exchange:
a) Receipt of a Setup Message:
Upon successful route selection, the setup message is examined for the presence of a Call Trace IE. If present, a ‘Call Completed’ component is appended to the Call Trace IE. A copy of the Call Trace IE is saved and the Setup message is then forwarded to the destination. The Call Trace IE is removed if enhanced signalling has not been enabled at the destination interface.
b) Receipt of a Connect Message:
The Connect message is examined for the presence of a Call Trace IE. If present, the message is forwarded to the preceding exchange without modification to the Call Trace IE.
If the Call Trace IE Is absent, the exchange checks for a previously saved copy. If a copy exists, it is added to the Connect message before the message is forwarded to the preceding exchange.
Three levels of information can be provided by a node at the point of failure: a cause value, a diagnostics cause value with user defined (proprietary) diagnostics, or a Call Trace IE. When a failure occurs, a Release or Release Complete message is generated by the exchange at the point of failure. The exchange will incorporate one of the aforementioned levels of failure information into the message. As a result, the preceding node has the responsibility to process the failure information correctly.
1. Actions Required at the Originating Exchange:
a) Detection of a call failure at the originating node:
A Call Trace IE is inserted into the Setup message. When the originating exchange detects that it is unable to process with the call, a ‘Call Blocked’ component is appended to the Call Trace IE. If enhanced signalling is enabled, the Call Trace IE is copied to the Call Rejection message which is sent to the originating user.
If the originating exchange is unable to include a copy of the Call Trace IE, normal call clearance procedures are followed.
b) Receipt of a Release or Release Complete message with a Call Trace IE:
The Call Trace IE is copied without modification to the Call Clearance message. The message is then sent to the originating user. The Call Trace IE contains a complete trace of the call and can be used by the management layer for local diagnostics.
c) Receipt of a Release or Release Complete message without a Call Trace IE:
The originating exchange determines if a Call Trace IE has been saved for this call. If the IE exists, a ‘Call Blocked After Transit’ component is appended. The IE is then copied to the Call Clearance message which is then sent to the originating user.
d) Call Failure on receipt of Connect:
A call failure will occur if the exchange is unable to complete the call after receiving a Connect message.
If a Call Trace IE is present in the Connect message, a ‘Call Blocked’ component is appended. If enhanced signalling is enabled, the component is then copied to the Call Trace IE that is sent to the originating user.
Otherwise, the saved Call Trace IE is copied to the Release message. A ‘Call Blocked’ component is appended to the Call Trace IE.
If the originating exchange is unable to include a copy of the Call Trace IE, normal call clearance procedures are followed.
2. Actions Required at a Transit Exchange:
a) Detection of a call failure at a Transit Exchange:
At a transit exchange, a Call Trace IE is inserted into the Setup message. When the originating exchange detects that it is unable to process with the call, a ‘Call Blocked’ component is appended to the Call Trace IE. If enhanced signalling is enabled, the Call Trace IE is copied to the Call Rejection message which is sent to the originating user.
If the originating exchange is unable to include a copy of the Call Trace IE, normal call clearance procedures are followed.
b) Receipt of a Release or Release Complete message with a Call Trace IE:
The Call Trace IE is copied without modification to the Call Clearance message. The message is then sent to the originating user. The Call Trace IE contains a complete trace of the call and can be used by the management layer for local diagnostics.
c) Receipt of a Release or Release Complete message without a Call Trace IE:
The transit exchange determines if a Call Trace IE has been saved for this call. If the IE exists, a ‘Call Blocked After Transit’ component is appended. The IE is then copied to the Call Clearance message which is then sent to the originating user.
d) Call Failure on receipt of Connect:
A call failure will occur if the transit exchange is unable to complete the call after receiving a Connect message.
If a Call Trace IE is present in the Connect message, a ‘Call Blocked’ component is appended. If enhanced signalling is enabled, the component is then copied to the Call Trace IE that is sent to the originating user.
Otherwise, the saved Call Trace IE is copied to the Release message. A ‘Call Blocked’ component is appended to the Call Trace IE.
If the transit exchange is unable to include a copy of the Call Trace IE, normal call clearance procedures are followed.
3. Actions Required at the Destination Exchange:
a) Detection of a call failure at the Destination Exchange:
When the destination exchange determines that it cannot proceed with a call, then if possible, the Call Trace IE included in the Setup message should be copied to the Call Clearance message. A ‘Call Blocked’ component is then appended to the Call Trace IE.
In all failure cases at the destination exchange, it is possible for a ‘Call Blocked’ or ‘Call Blocked After Transit’ component to be appended after a ‘Call Completed’ component.
b) Receipt of a Release or Release Complete message with a Call Trace IE:
At the destination exchange, the Call Trace IE is copied without modification to the Call Clearance message. The message is then sent to the originating user. The Call Trace IE contains a complete trace of the call and can be used by the management layer for local diagnostics.
c) Receipt of a Release or Release Complete message without a Call Trace IE:
The destination exchange copies the Call Trace IE that has been saved to the Call Clearance message being sent to the preceding exchange. A ‘Call Blocked After Transit’ component is appended to the Call Trace IE. This implies that the final Call Trace IE will always contain a ‘Call Completed’ component followed by a Call Trace component.
d) Call Failure on receipt of Connect:
A call failure will occur if the destination exchange is unable to complete the call after receiving a Connect message.
If a Call Trace IE is present in the Connect message, a ‘Call Blocked’ component is appended. If enhanced signalling is enabled, the component is then copied to the Call Trace IE that is sent to the originating user.
Otherwise, the saved Call Trace IE is copied to the Release message. A ‘Call Blocked’ component is appended to the Call Trace IE. If a ‘Call Blocked’ component is added, it may succeed a ‘Call Completed’ component that was already appended to the Call Trace IE.
If the destination exchange is unable to include a copy of the Call Trace IE, normal call clearance procedures are followed.
1. Actions Required at the Originating Exchange:
a) Receipt of Release or Release Complete containing Crankback and Call Trace IE:
If an alternate route is available, the Call Trace IE is copied to the outgoing Setup message and a ‘Call Transited’ component is appended. A copy of the updated IE is saved locally.
If no alternate route is available, the Call Trace IE is copied to the Release message to be sent to the originating user.
b) Receipt of a Release or Release Complete containing Crankback only:
If an alternate route is available, the Call Trace IE that was saved locally is copied to the outgoing Setup message. A ‘Call Blocked After Transit’ component is appended. When the alternate route is successfully selected, a ‘Call Transited’ component is then appended. A copy of the updated IE is again saved locally.
If an alternate route is unavailable, the Call Trace IE is copied to the Call Clearance message to be sent to the originating user and a ‘Call Blocked After Transit’ component is appended.
2. Actions Required at a Transit Exchange:
a) Receipt of Release or Release Complete containing Crankback and Call Trace IE:
At a transit exchange, if an alternate route is available, the Call Trace IE is copied to the outgoing Setup message and a ‘Call Transited’ component is appended. A copy of the updated IE is saved locally.
If no alternate route is available, the Call Trace IE is copied to the Release message to be sent to the originating user.
b) Receipt of Release or Release Complete containing Crankback only:
At a transit exchange, if an alternate route is available, the Call Trace IE that was saved locally is copied to the outgoing Setup message. A ‘Call Blocked After Transit’ component is appended. When the alternate route is successfully selected, a ‘Call Transited’ component is then appended. A copy of the updated IE is again saved locally.
If an alternate route is unavailable, the Call Trace IE is copied to the Call Clearance message to be sent to the originating user and a ‘Call Blocked After Transit’ component is appended.
3. Actions Required at the Destination Exchange:
a) Receipt of Release or Release Complete containing Crankback and Call Trace IE:
At the destination exchange, if an alternate route is available, the Call Trace IE is copied to the outgoing Setup message and a ‘Call Transited’ component is appended. A copy of the updated IE is saved locally.
If no alternate route is available, the Call Trace IE is copied to the Release message to be sent to the originating user.
b) Receipt of Release or Release Complete containing Crankback only:
At the destination exchange, if an alternate route is available, the Call Trace IE that was saved locally is copied to the outgoing Setup message. A ‘Call Blocked After Transit’ component is appended. When the alternate route is successfully selected, a ‘Call Transited’ component is then appended. A copy of the updated IE is again saved locally.
If an alternate route is unavailable, the Call Trace IE is copied to the Call Clearance message to be sent to the originating user and a ‘Call Blocked After Transit’ component is appended.
The balance of the figures demonstrate three different trace scenarios that incorporate the aforementioned operations. Symbols used in the diagrams represent the following:
∂
User
O
Network Node
ct
Call Trace IE
#
Call Transmitted Indication
$
Call Blocked Indication
@
Call Blocked After Transit Indication
!
Call Completed Indication
()
‘Contains’
The Setup message originates at user a and progresses through the network along nodes A, B, and E before arriving at user b. User b responds to Setup Message with a Connect message to indicate that the call has successfully completed.
The Setup message originates at user a and traverse a path along nodes A, C, and B. At node B a routing failure occurs. The Setup message then traverses a path from B through nodes C, D and E until a successful call completion is reached at user b. A Connect message is then sent back through nodes E, D, C, and A to user a.
The call is initiated from user a through node A. The message progresses by the preferred route to node B. Node B rejects the call due to a resource problem, but does not include a Call Trace IE. The call progresses to node D when the alternate route A-D is selected. Node D also rejects the call. The final Call Trace IE in the Release message from node D contains information of the 2 node failures.
Those skilled in the art will recognize that various modifications and changes could be made to the invention without departing from the spirit and scope thereof. It should therefore be understood that the claims are not to be considered as being limited to the precise embodiments set forth above, in the absence of specific limitations directed to each embodiment.
Bosloy, Jonathan L., Burns, John C., Watkinson, David, Bews, Stephen C.
| Patent | Priority | Assignee | Title |
| 7505567, | Dec 30 2005 | AT&T Corp | Method for providing detection of fault location for defect calls in a VoIP network |
| 7773727, | Dec 30 2005 | AT&T Corp | Method for providing predictive maintenance relating to trunk operations in a VoIP network |
| 9294958, | Jul 20 2012 | Qualcomm Incorporated | Method and apparatus for dynamically configuring a cell update message |
| 9491282, | May 13 2015 | Cisco Technology, Inc. | End-to-end call tracing |
| Patent | Priority | Assignee | Title |
| 4881230, | Oct 05 1987 | Rolm Systems | Expert system for processing errors in a multiplex communications system |
| 5051996, | Mar 27 1989 | The United States of America as represented by the United States | Built-in-test by signature inspection (bitsi) |
| 5271000, | Mar 22 1991 | International Business Machines Corporation | Method and apparatus for testing and evaluation of distributed networks |
| 5825772, | Nov 15 1995 | Extreme Networks, Inc | Distributed connection-oriented services for switched communications networks |
| 5974046, | May 16 1997 | Electronics and Telecommunications Research Institute; Korea Telecom | Maintenance method for subscriber lines of broadband network termination apparatus in an asynchronous transfer mode permanent virtual connection switching system |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Nov 14 2002 | Alcatel Canada Inc. | (assignment on the face of the patent) | / | |||
| Jan 30 2013 | Alcatel-Lucent Canada Inc | CREDIT SUISSE AG | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 029826 | /0927 |
| Date | Maintenance Fee Events |
| May 20 2008 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| May 20 2008 | M1555: 7.5 yr surcharge - late pmt w/in 6 mo, Large Entity. |
| May 10 2012 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
| Date | Maintenance Schedule |
| Mar 11 2011 | 4 years fee payment window open |
| Sep 11 2011 | 6 months grace period start (w surcharge) |
| Mar 11 2012 | patent expiry (for year 4) |
| Mar 11 2014 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Mar 11 2015 | 8 years fee payment window open |
| Sep 11 2015 | 6 months grace period start (w surcharge) |
| Mar 11 2016 | patent expiry (for year 8) |
| Mar 11 2018 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Mar 11 2019 | 12 years fee payment window open |
| Sep 11 2019 | 6 months grace period start (w surcharge) |
| Mar 11 2020 | patent expiry (for year 12) |
| Mar 11 2022 | 2 years to revive unintentionally abandoned end. (for year 12) |