Correlation of signalling messages

[0001] This invention relates to correlation of signalling messages conforming to different protocols, for example for bearer identifier discovery in a distributed switch environment.

[0002] Existing telecommunications networks, for example the international public switched telephone network (PSTN) are typically configured so that equipment (such as switches) in the transmission or bearer network, which carries user traffic (voice and data signals), is co-located with equipment (such as signalling points) in the associated signalling network, which carries control signals for coordinating the operation of the bearer network.

[0003] However, attention is now being directed to the possibility of telecommunications networks comprising distributed telecommunications switches, in which there is a separation of the switching/adaptation functionality from the signalling functionality. Furthermore, consideration is being given to the possibility of connecting dissimilar such networks (i.e. networks relying on different bearer technologies and/or signalling protocols).

[0004] Dissimilar telecommunications networks are typically interconnected via a “gateway” which provides the necessary conversions or adaptations between the bearer traffic and signalling protocol in each of the networks. In such an architecture control devices such as Media Gateway Controllers can be physically remote from the adaptation devices, such as Media Gateways. Media Gateway Controllers can communicate with the Media Gateways they control using protocols such as Simple Gateway Control Protocol (SGCP), Media Gateway Control Protocol (MGCP), and the Megacop/H.248 protocol currently being defined. Media Gateway Controllers communicate with each other using extensions of current Call Control protocols such as Signalling System No.7 ISDN User Part (SS7 ISUP), Session Initiation Protocol (SIP—IETF RFC 2543), or ITU Recommendation H.323. New protocols may be defined for this interface in the future.

[0005] Protocol monitoring applications, such as tracing across a signalling network the protocol messages associated with a call, or building Call Data Records (CDRs) to summarise the key parameters relating to a call, require the ability to correlate across different protocols, which may refer to a single entity in multiple different, inconsistent ways. It is an object of this invention to facilitate such correlation.

[0006] According to one aspect of this invention there is provided a method of establishing a correlation between the contents of signalling messages conforming to different protocols but relating to a common bearer data item, comprising the steps of:

[0007] monitoring messages traversing at least first and second signalling channels which conform to respective first and second signalling protocols;

[0008] selecting first messages containing an identification related to an end user of said bearer data item and a first identification of a bearer channel carrying said bearer data item;

[0009] selecting second messages containing a second identification of a bearer channel carrying said bearer data item and a call identifier with system-wide significance;

[0010] selecting third messages containing an identification related to an end user of said data item and a call identifier with system-wide significance; and

[0011] using said selected third messages to establish a correlation between the first and second bearer channel identifications.

[0012] According to another aspect of this invention there is provided a method of establishing a correlation between the contents of signalling messages conforming to different protocols but relating to a common bearer data item, comprising the steps of:

[0013] monitoring messages traversing at least first and second signalling channels which conform to respective first and second signalling protocols;

[0014] selecting first messages containing an identification related to an end user of said bearer data item and a first identification of a bearer channel carrying said bearer data item;

[0015] selecting second messages containing a second identification of a bearer channel carrying said bearer data item and a transaction identifier;

[0016] selecting third messages containing an identification related to an end user of said data item and packet network address information;

[0017] selecting fourth messages containing packet network address information and a transaction identifier; and

[0018] using said selected third and fourth messages to establish a correlation between the first and second bearer channel identifications.

[0019] According to a further aspect of this invention there is provided a method of establishing a correlation between the contents of signalling messages conforming to different protocols but relating to a common bearer data item, comprising the steps of:

[0020] monitoring messages traversing at least first and second signalling channels which conform to respective first and second signalling protocols;

[0021] selecting first call initiation messages containing a first identification of a bearer channel carrying said bearer data item;

[0022] selecting second call initiation messages containing a second identification of a bearer channel carrying said bearer data item;

[0023] determining elapsed time between occurrence of said first and second messages; and

[0024] establishing a correlation between first and second messages for which the elapsed time is below a predetermined threshold, and thus between the first and second bearer channel identifications.

[0025] According to another aspect of this invention there is provided apparatus for establishing a correlation between the contents of signalling messages conforming to different protocols but relating to a common bearer data item, comprising:

[0026] monitoring equipment for monitoring messages traversing at least first and second signalling channels which conform to respective first and second signalling protocols;

[0027] a first selector for selecting first messages containing an identification related to an end user of said bearer data item and a first identification of a bearer channel carrying said bearer data item;

[0028] a second selector for selecting second messages containing a second identification of a bearer channel carrying said bearer data item and a call identifier with system-wide significance;

[0029] a third selector for selecting third messages containing an identification related to an end user of said data item and a call identifier with system-wide significance; and

[0030] a correlator for establishing a correlation between the first and second bearer channel identifications in accordance with said selected third messages.

[0031] According to a further aspect of this invention there is provided apparatus for establishing a correlation between the contents of signalling messages conforming to different protocols but relating to a common bearer data item, comprising:

[0032] monitoring equipment for monitoring messages traversing at least first and second signalling channels which conform to respective first and second signalling protocols;

[0033] a first selector for selecting first messages containing an identification related to an end user of said bearer data item and a first identification of a bearer channel carrying said bearer data item;

[0034] a second selector for selecting second messages containing a second identification of a bearer channel carrying said bearer data item and a transaction identifier;

[0035] a third selector for selecting third messages containing an identification related to an end user of said data item and packet network address information;

[0036] a fourth selector for selecting fourth messages containing packet network address information and a transaction identifier; and

[0037] a correlator for establishing a correlation between the first and second bearer channel identifications in accordance with said selected third and fourth messages.

[0038] According to another aspect of this invention there is provided apparatus for establishing a correlation between the contents of signalling messages conforming to different protocols but relating to a common bearer data item, comprising:

[0039] a monitor for monitoring messages traversing at least first and second signalling channels which conform to respective first and second signalling protocols;

[0040] a first selector for selecting first call initiation messages containing a first identification of a bearer channel carrying said bearer data item;

[0041] a second selector for selecting second call initiation messages containing a second identification of a bearer channel carrying said bearer data item;

[0042] a monitor for determining elapsed time between occurrence of said first and second messages; and

[0043] a correlator for establishing a correlation between first and second messages for which the elapsed time is below a predetermined threshold, and thus between the first and second bearer channel identifications.

[0048] Referring to FIG. 1, a Media Gateway Controller (MGC) 10 and an associated Media Gateway (MG) 12 link the public switched telephone network (PSTN) 14 to a packet network 16, which in this example is shown as using Asynchronous Transfer Mode (ATM) technology. The PSTN 14 uses SS7 ISUP over its signalling links 18 to the MGC, and time division multiplexing (TDM) for transmission of user traffic (for example voice calls and other bearer data items) over its transmission or bearer channels 20 to the MG 12. The MGC 10 exchanges signalling messages with other MGCs, such as an MGC 10a, over a signalling link 22 using SS7 ISUP with extensions which have been previously defined for this purpose. The MG 12 transfers the voice calls, in the form of Voice over ATM messages, to and from the ATM network 16 over ATM channels 24 which also carry ATM signalling messages in conventional manner. The MGC 10 controls the MG 12 via a link 26 carrying MGCP messages.

[0049] FIG. 2 shows part of one possible sequence of messages used to set up a call across such a network, as follows:

• • [0050] 1. the PSTN 14 sends an Initial Address Message (IAM) to the MGC 10;
  • [0051] 2. the MGC 10 then sends a Create Connection (CRCX) message to the MG 12, to define an endpoint for a packet network connection over the channels 24;
  • [0052] 3. when this has been accomplished the MG 12 returns an OK acknowledgement containing address information for the packet network endpoint, coded as a Session Description Protocol (SDP-RFC 2327) Connection Description Parameter;
  • [0053] 4. thereafter the MGC sends another IAM over the link 22 to the packet network.
    In calls controlled by a single MGC message number 4 does not occur. For a call in the opposite direction, i.e. terminating in the PSTN, the same messages would occur but the messages 1 and 4 would be interchanged.

[0054] Although the different messages on their respective links all relate to the same overall call or transaction, the different ways in which their respective protocols identify the call (e.g. by reference to the subscriber, or to the equipment used to carry the call, or to an arbitrary reference number) prevent a simple association of these messages to derive a complete description of the call. Such descriptions are desirable, for example, to build Call Detail Records for billing and other management functions, or in order to trace progress of the call through the system during fault finding.

[0055] FIG. 3 highlights fields in (by way of example) the SS7 and MGCP protocols which may be used to correlate messages belonging to a single call traversing the network shown in FIG. 2. The PSTN trunk associated with a call is identified in the SS7 ISUP (or Telephone User Part—TUP) signalling by the combination of Destination Point Code (DPC), Originating Point Code (OPC) and Circuit Identification Code (CIC) fields, as defined in the ITU's Recommendation Q.767. In the MGCP protocol used between the MGC and the MG, the same trunk is identified by an endpointname of the form localEndpointname@Domainname, where localEndpointname is a character string, and Domainname is a Domain name as defined by the Internet Engineering Task Force's document RFC 821. In order to associate, say, an SS7 ISUP call protocol sequence with the corresponding MGCP protocol sequence, it is necessary to be able to correlate these two identifications.

[0056] The invention enables the association between the SS7 OPC-DPC-CIC trunk identification and the endpointname used by the MGCP (or any similar protocol) to be discovered and stored for subsequent use by any appropriate application program, such as for billing.

[0057] To this end, the various signalling links and channels in the network surrounding the MGC 10 are provided with passive monitoring devices 28 and 30 as shown in FIG. 2. For monitoring SS7 links Hewlett-Packard acceSS7 monitoring equipment may be used; for other channels (e.g. ATM or IP) equipment of similar functionality with interfaces adapted to match those technologies would be used. The monitoring devices 28 and 30 detect and generate copies of all signalling messages traversing the links and channels around the MGC 10. These copies are then transferred, for example via a local area network, to a monitoring control centre 32, which typically comprises data storage equipment and associated data processing equipment operating under the control of appropriate software program instructions to perform the required analyses of the data collected.

[0058] Using the data thus acquired, a table of associations between OPC-DPC-CIC identifications and endpointnames can be built by the monitoring control centre 32. For this purpose the required associations are deduced as follows:

• • [0059] where an IAM between MGC's (inter-MGC IAM) is generated following the arrival of an SS7 IAM (or vice versa), these two messages can be correlated by the combination of Calling & Called address parameters;
  • [0060] the SDP connection description parameter included in inter-MGC IAMs and MGCP OK messages can be used to correlate these messages;
  • [0061] the MGCP OK message can be correlated with the MGCP CRCX message using the transaction ID included in both of them.
    Thus each pair of message types described above provides a step in a sequence by which all four types of messages can be associated as relating to a single call: SS7 IAM with inter-IAM; inter-IAM with MGCP OK; and MGCP OK with MGCP CRCX. This in turn enables the required correspondence to be deduced between an MGCP endpointname (in the CRCX message) and an ISUP OPC-DPC-CIC identification (in the SS7 IAM).

[0062] This requires the buffering of initial IAM and MGCP messages for a short time, for example in the monitoring control centre, until the associated messages on the other links occur and can be detected.

[0063] Another way of making an association (although it is only tentative in nature) is to correlate the OPC-DPC-CIC identification from the SS7 IAM with the endpointname in an MGCP CRCX message which occurs within a predetermined short time interval after the IAM arrives (and provided no other such IAM messages occur between the times the chosen IAM and the CRCX are monitored, and also provided no subsequent CRCX messages are monitored during a suitably long time period thereafter). Associations detected in this manner should be marked as ‘suspected’ rather than ‘known’ in the table, until they can be confirmed by the first technique described above. This approach may speed up the discovery process in cases where a high proportion of calls are controlled by a single MGC.

[0064] This alternative method can be refined by eliminating from consideration any messages containing OPC-DPC-CIC identifications or endpointnames already present (as ‘known’) in the association table. This increases the probability that the messages under consideration will reduce to a single IAM and CRCX pair. As the table of discovered associations becomes more nearly complete, this method becomes more successful.

[0065] The association table can be accessed in use by protocol monitoring applications which need to establish linkages between messages relating to a particular call. Depending on the particular type of application, ‘suspected’ associations could be either ignored or used, with an appropriate warning to the application user.

[0066] The techniques described above eliminate the need for error-prone manual configuration of an association table, as has been previously required. They rely only on standardised protocol message formats, and thus avoid the possible need to deal with multiple, proprietary, vendor-specific Operation Support System (OSS) interfaces as would be required if data to build the association table were extracted from such OSSs.

[0067] The invention has been described by way of example in the context of SS7 and MGCP protocols. However, it will be understood that the invention is equally applicable in connection with the use of any other protocol defining messages which contain indications of end users and/or bearer channels.