TELECOMMUNICATIONS NETWORKS
The present invention relates to methods of signalling in telecommunications networks, and to networks and switches employing such methods.
Organisations of medium or large size commonly operate private telecommunications networks. PBX's (private branch exchanges) in such a network may be connected by dedicated privately owned links. Increasingly however, public telecommunications operators (PTOs) are offering virtual private networks (VPNs) for this purpose. When PBX's are directly interconnected by dedicated links, then the use of feature-rich signalling protocols such as QSIG (also known in its ISO version as PSS1 , that is Private Signalling System no. 1 ) makes it possible for most of the functionality offered by modern PBX's to be available across the network. In particular, QSIG supports the signalling of private numbers and a number of Additional Network Features (ANFs) and supplementary services such as, for example, Completion of Calls to Busy Subscribers (CCBS). While QSIG and similar protocols are effective over private networks using dedicated links, problems arise when it is desired to use a PTO core network to support a virtual private network. Even if the access network from a PBX uses QSIG, the signalling system conventionally used in core networks, namely ISUP (ISDN user part), is able to support basic call handling, but little else. To overcome this limitation, a transport parameter known as APP has been developed for use within the core network. This provides a mechanism for enveloping signals relating to, e.g., QSIG (Q interface Signalling protocol) features not supported by ISUP so that the relevant data is transported transparently across the core network.
According to a first aspect of the present invention there is provided a method of operating a telecommunications network comprising a core network and an access network connected via a switch to the core network, the method including: a) transmitting on the core network a core network signalling channel which includes a first transport parameter, which first transport parameter
encapsulates information elements for features which are not directly supported by the core network signalling channel; and b) transmitting on the access network an access network signalling channel which includes a second transport parameter, which second transport parameter encapsulates at least some of the information elements encapsulated in the first transport parameter .
As described above, the transport parameter was developed to solve the problem of carrying in the core network additional data from, e.g. , QSIG signalling in the access network. However, there is another problem, in that many local exchanges and access networks do not support QSIG or similarly advanced protocols but only support earlier and more limited protocols such as DSS1 (Digital
Signalling System no. 1 ). It has been proposed to overcome this limitation by upgrading to new access network signalling systems such as DSS1 + , but this requires extensive modification of local exchanges and PBX's and so is highly costly. The present invention removes the need for such costly changes, by adding to the access network signalling channel its own transport parameter. This allows the encapsulation of QSIG messages or other signals which are not otherwise supported by the access network, and makes possible effective interworking of the access networks and networks operating to different standards.
Preferably the transport parameter is an Application Transport Parameter (APP) which includes a context identifier field which identifies the protocol to which the information which is encapsulated by the transport parameter relates.
Advantageously, the network may be configured as a Virtual Private Network linking a first PBX at a first site to a second PBX at a second site remote from the first site, the method then comprising: i) transmitting a first access network signalling channel from the first PBX to a switch in the core network; ii) in the core network, transmitting the core network signalling channel to a destination exchange; iii) at the destination exchange,
transmitting to the second PBX a second access network signalling channel which supports a set of features which is different to the set of features supported by the first access network channel; and transmitting in the second access network signalling channel a transport parameter which encapsulates data for features of the signalling set of the first access network signalling channel which are not in the set of features supported by the second access network signalling channel. The invention also encompasses networks configured to operate in accordance with the method of the first aspect, exchanges and PBX's adapted for operation in such a network, and signals for use in such a network
According to a second aspect of the present invention, there is provided a method of operating a telecommunications network, including a)receiving at a local exchange an ISUP signalling channel which includes a first transport parameter (ISUP-APP) containing data relating to features which are not directly supported by ISUP; and b) transmitting onwards from the exchange a DSS1 signalling channel including a second transport parameter (DSS1 -APP) including at least some of the said data contained in the first transport parameter. For the reasons noted above, the present invention is especially advantageous in the context of an interface between ISUP and DSS1 networks.
Methods, networks and switches embodying the present invention will now be described in further detail, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic of a network embodying the present invention;
Figure 2 is a diagram showing the format of a public/private parameter transmitted on a signalling channel in the network of Figure 1 ;
Figure 3 is a schematic of a second network embodying the present invention; Figure 4 is a diagram showing the format of an APP transport parameter;
Figure 5 is a call flow diagram;
Figure 6 shows a software architecture for implementing the network of Figure 1 ;
Figure 7 shows platforms for implementing the network of Figure 1 ; Figure 8 is a flow diagram for elements of the software of Figure 6; and Figure 9 is a diagram showing a third example of a network embodying the present invention. A telecommunications system comprises a core network 1 connects user terminals 2a, 2b via local exchanges LE1 , LE2 and access networks 3, 4. The access network for the first local exchange LE1 supports a QSIG ( Q interface SIGnalling protocol) signalling channel between the local exchange LE1 and a PBX 5. More specifically, the channel uses the ISO version of QSIG known as PSS1 (Private Signalling System no. 1 ). The access network for the second local exchange LE2 supports a DSS1 (Digital Signalling System no. 1 ) signalling protocol, augmented by an application transport parameter APP, as will be further described below. A PBX 6 is connected to the second local exchange LE2 via the access network. DSS1 is described, e.g., in international standards publications Q931 (DSS1 Basic Call) and Q932 (DSS1 Supplementary Services) and is well known to those skilled in this field.
Within the core network, signalling is carried using ISUP (ISDN user part) signalling channels. The ISUP signalling incorporates APP parameters which are used to envelope features of the local access signalling channels in order to transport them transparently across the network. In this manner, the core network is used to implement a virtual private network VPN which incorporates the two PBXs, and which has its own private numbering scheme. In addition, the PBXs and customer terminal equipment connected to the PBX's have public telephone numbers. ISUP is described, e.g., in international standards publications Q730 (ISDN Supplementary Services 1993) and Q731 and is well known to those skilled in this field.
It will be understood that the signalling protocols referred to above are given by way of example only, and that alternative signalling schemes may be used. In use, when a calling party at a first terminal TE1 wishes to call another party having a second terminal TE2 connected to the second PBX, then the first PBX opens a QSIG signalling channel to the local exchange LE1 . This uses the conventional QSIG protocol for establishing and progressing the call, other than in
that a public/private parameter is passed to the local exchange LE1 . Figure 2 shows the format of the public/private parameter which is included in layer 3a of the protocol stack.
The data passed on the signalling channel to the local exchange LE2 may include, for example, the private number of the called party. In addition, the first PBX inserts in the signalling stream the PPP parameter. As shown in the Figure, this is an eight bit parameter. In this instance, bit 2 has its value set to indicate that the calling party has chosen routing on the private CdPN (called party number). At the local exchange, the private CdPN received from the PBX is translated to a corresponding public number. This is carried publicly in the ISUP signalling and is used to route the call through the core network. The private number, and the PPP parameter are not used within the core network, but are transported through the network using an APP parameter in the ISUP signalling. Figure 4 shows the format of the APP parameter. This parameter represents an addition to ISUP which can be used to carry QSIG information elements (IE) and any other application-specific data. The Application Context Identifier field is used to identify the nature of the encapsulated data. In this case the data is the PPP parameter and the private CdPN. The data itself is then carried in bytes 4a to 4n of the parameter. This data is delivered transparently through the ISUP channel across the core network to the destination local exchange LE2.
Table 1 shows the Information Elements (IE) transferred from the first PBX onto the QSIG channel in the access network. The elements shown in grey are mapped onto the QSIG access signalling within the SETUP message to initiate a call. In a given SETUP message it may be that not all of the parameters are sent together. For example, the "Sending Complete" parameter is sent only when the number is complete.
In terms of call flows, the incoming side sends a CALL PROCEEDING message to the outgoing side to indicate that the call is being processed. The overall call flow by which the call is setup, routed and terminated is generally conventional in nature and will not be described further here.
When the QSIG signalling channel reaches the local exchange LE1 , some of the lE's will not be forwarded, as they have only local significance within the
access network. Other lEs are mapped into the core network signalling system, which in the present example is ISUP 97. These parameters are either mapped into their equivalent field in ISUP, e.g. Bearer Capability in Bearer Capability, or are enveloped in the ISUP APP transport parameter. This latter carries private information which is relevant only to the access signalling and not to the intemodal signalling. Some parameters are mapped into both the APP envelope and into ISUP fields. For example the called party number field in the APP envelope may contain the private Called Party Number CdPN, while this is also translated into a public number carried in the ISUP CdPN field for the public network to route the call. Table 2 shows where QSIG parameter have been mapped onto ISUP 97 via an Initial Address Message (IAM).
The Information Elements which are contained in the ISUP signalling channel are then delivered to the destination local exchange LE2 and output onto a DSS1 signalling system which has been augmented by the addition of a transport parameter APP. Conveniently this transport parameter has the same format as the ISUP APP shown in Figure 4. Table 3 shows the mapping of the Information Elements from the ISUP IAM into a SETUP message in the DSS1 _APP signalling channel. In the example of Figure 1 , the information elements are then delivered to a destination PBX. Alternatively, as in the network of Figure 9, DSS1 APP may be used to connect the core network to another core network. In the example of Figure 9, the UK PSTN 92 is connected via an access network using DSS1 APP signalling to a Service Switching Point (SSP) in a further network 91 which uses different protocols, for example the Virtual Private Network of Concert Communications. As shown in the Figure, this network employs an IN (intelligent network) architecture. A second DSS1_APP link is used to connect the further network 91 to a remote point of presence RPoP, from which connections extend to a number of remote sites using, respectively, DSS1 , DPNS and QSIG signalling.
The use of the APP parameter in the DSS1 channel alows the implementation across the network of a Additional Network Features and Supplementary Services. Also, in relation to Basic calls, it allows the delivery of both private and public numbers and the use of a PPP parameter to select one or other, as described and claimed in our application (Agent's ref A25313) entitled Telecommunications Networks and also filed this day (the contents of which are
incorporated herein by reference), and illustrated in the detailed embodiment described below.
The use of the APP parameter allows the access CAUSE parameter to be carried across the network. When a call is released, this indicator is associated with a number (from 1 to 1 27) that gives the reason for the connection being terminated. However not all access cause values can be matched onto the core network (e.g. CAUSE no.s 6 30 81 96 98 100 101 ). The use of the APP parameter makes it possible to bypass ISUP and to deliver end to end information between two access signalling networks. It will be understood that the use of the APP parameter in the access signalling channel is not limited to the specific uses already identified, but that it provides an enveloping mechanism that can carry any type of information, together with a context identifier that indicates the kind of information that is inside the envelope. For example, DPNSS (digital private network signalling system) lE's might be carried in the APP envelope. DSS1 APP is fully compatible with DSS1 and with QSIG and can carry any specific end to end IE.
Figure 3 shows a further example of a network which uses DSS1 _APP. In this example, the public core network uses different platforms to support VPN (virtual private network) and ISDN services. DSS1 _APP is used to provide enhanced capabilities via the ISDN platform, while PSS1 (QSIG) is used for access to the VPN.
Architectures for implementing the invention will now be described in further detail.
Figure 5 shows the call flows on the signalling channels between the different switches in the example described above. A SETUP message is passed from the originating PBX to the first local exchange which generates and forwards an intial address message. In a conventional manner, once the setup procedure has been completed, then a circuit for the voice or data call is established between the Calling and Called parties. It is assumed that within the core network, the call between the originating local exhcnage and the destination exchange is routed via a transit exchange TE. The parameters shown shaded are carried via the Application Transport Parameter APP. It can be seen that these include the Calling Party and Called Party subaddresses, and also the PPP parameter.
Although in this example the APP parameter is used in the SETUP message, it may also be used in other contexts, for example in ALERT, RELEASE COMPLETE, CONNECT and DISCONNECT messages.
Figure 6 illustrates the architecture of the software used to implement the invention in this example. In the orginating and destination local exchanges , VPN processing modules are interfaced via call control modules to signalling interfaces. In originating local exchange, additional call control procedures are added to the VPN module. These additional features implement two functions: 1 ) translation of private numbers into public Calling and Called party numbers; 2) enveloping of private numbers into the Application Transport Parameter (APP). Figure 8 is a flow diagram illustrating the implementation of these additional call features. At step S1 the incoming private number is read. In step S2 this is used to address a look-up table which is stored locally at the exchange and which maps private numbers to the public numbering system used by the core network. If at stage S3 no corresponding public number is found, then the procedure terminates. Otherwise, the public number is written into the CdPN ISUP field. The private CdPN is written into the data field of the APP in setep S6. Also the Application Context Identifier of the APP is set in S7 to indicate that the parameter contains QSIG data. The procedure ends at S8, at which point the VPN reverts to the conventional call setup procedure.
The transit exchange merely forwards all received information. At the destination exchange, additional functions in the VPN map parameters received onto their equivalents in the outgoing DSS1_APP channel. Without the use of the APP parameter in the DSS1_APP channel, it would be necessary to discard the private enveloped parameters received at the destination exchange.
The enveloping mechanism described above makes it possible to carry two private Calling Party Numbers or any other PBX-specific information. For example, the APP parameter can also carry a specific CAUSE value which indicates why a call has been released. Different CAUSE values apply to the core and access networks. Conventionally when a call is released by the active network, then if a directly corresponding cause does not exist within the core network, it has been necessary to map the actual cause onto the closest similar cause provided for by the core network signalling protocol. Using the APP parameter allows the actual
access network CAUSE value to be transported across the network to another access network and PBX, where it can be interpreted appropriately.
Figure 7 shows a physical architecture to support the functions described above. The PBX or "PINX" may be, for example a device such as that available commercially from NORTEL as a Meridian M 1 PBX, and the local and transit exchanges may comprise digital exchanges such as those available commercially form Ericsson as AXE10 or GPT Ltd as System X, or Nortel as DMS-100. Within the different platforms, the different elements have the following functions:
• The Supplementary Service Control (SS-C) is responsible for the provision of procedures for the support of a particular supplementary service.
• The Coordination Function provides coordination between GFT-Control, the various SS-Control entities, ROSE, ACSE, DSE and Call Control for different Supplementary services. It also provides functions to support the handling of unrecognised APDUs. • The Remote Operation Service Element (ROSE) is responsible for the encoding of supplementary service information provided by the SS-C, into the appropriate ROSE Application Protocol Data Unit (APDU). The ROSE APDUs are then delivered either to the GFT control or the DSE via the Co-ordination Function.
• The Dialogue Service Element (DSE) may be used to create one or more dialogues between two PTNXs or to provides services via the Co-ordination
Function, so that ROSE elements not implicitly associated by a network layer connection can be explicitly associated. These services can allow ROSE APDUs to be exchanged and delivered to the GFT-Control.
• The Association Control Service Element (ACSE) provides a set of services to establish and release an explicit Application association.
• The Generic Functional Transport (GFT) provides connection oriented, connectionless oriented and notification services to the SSC, ACSE, ROSE and DSE via the Coordination Function.
Tablel
Table 2