WO2002013472A1

WO2002013472A1 - Data processing system

Info

Publication number: WO2002013472A1
Application number: PCT/GB2001/003570
Authority: WO
Inventors: Scott Cannon; John Lewis; Nicholas David Whitlow; Kiran Patel
Original assignee: Marconi Communications Limited
Priority date: 2000-08-10
Filing date: 2001-08-08
Publication date: 2002-02-14
Also published as: AU2001276547A1; JP2004506383A; GB0019708D0

Abstract

A communication system comprising an internet protocol (IP) network comprising means for transporting V5 signalling messages across the IP network and a protocol for the transport of the messages in a media gateway control protocol experimental parameter.

Description

DATA PROCESSING SYSTEM

The present invention relates to the filed of communications systems in general and to protocols for signalling therein.

The trend towards moving telephony traffic over internet protocol (D?) networks has led to an increasing need for interoperation of public switched telephone networks (PSTN) and IP networks. Network operators providing an IP access network may wish to provide a PSTN service across the IP access network and to this end to connect to a legacy (i e. conventional PSTN) Local Exchange via a gateway. In such an arrangement, the Local Exchange would use a conventional V5 interface as defined in the ETSI European Standards EN300 324 series and EN300 347 series for communication with the gateway for the purposes of PSTN call control.

A Head-End Gateway (HGW) provides the gateway between the IP world and the PSTN world. It provides standard IP interfaces to the D? network (e.g. Ethernet) and V5 interfaces to the PSTN. Voice and signalling are mapped by the HGW from one environment to the other. A Residential Gateway (RGW) provides the gateway between the IP world and the analogue PSTN world. It provides standard IP interfaces to the IP network (e.g. Ethernet) and analogue line interfaces to the telephony equipment. It maps analogue line interfaces to/from V5 PSTN and manages the transport of these V5 PSTN signals over the MGCP/TP protocol.

It is desirable that (as near as possible) any customer using PSTN services and connecting to a Local Exchange across such an D? access network enjoys the same level of service (such as call waiting, 3-party calls) as a customer connected to the Local Exchange directly via a legacy access network. Similarly the network operator would expect to be able to support the same types of telephony equipment (PBX's, payphones, answer-machines etc) over the IP access network as can be supported over the legacy access network.

Standard MGCP signalling (with its associated line package) as defined in Internet Engineering Task Force (IETF) request for comment RFC 2705, is recognised as a means of controlling analogue telephone lines across an IP network. However, the functionality it provides and the types of events/signals it supports tends to limit its use to a standard telephone handset (i.e. not legacy payphones, answering machines, PBX's etc).

V5 PSTN signalling is designed to support a greater range of signalling messages than MGCP in terms of the conditions it may request that an access network apply to an analogue line. MGCP supports signalling for IP telephony, but not for full PSTN telephony.

The implementation of V5 varies from country to country. By way of example, the UK V5 PSTN may request that the following signals, none of which is available from the MGCP line package, be applied to the line: • Reversed Linefeed

• Reduced Linefeed

• End of call pulses

• Meter pulses

Hence there is a need to identify a signalling protocol between the residential gateway (RGW) and the head-end gateway (HGW) that will allow this transparency of service.

The present invention provides a protocol for the transport of V5 signalling in which the signalling is transported in a media gateway control protocol (MGCP) experimental parameter.

The present invention also provides a communications system comprising an internet protocol (D?) network comprising means for transporting V5 signalling messages across the IP network.

Preferred embodiments of the invention will now be described by way of example with reference to the drawings in which

Figure 1 illustrates in block diagram form an D? access network connected to a PSTN network;

Figure 2 illustrates signalling across an D? network according to the present invention Figure 1 shows a combination of IP and PSTN networks with PSTN service being provided across an D? network. A first piece of PSTN telephony equipment is connected to local exchange via narrowband multiplexer 30 and links 15 and 35. A second piece of PSTN telephony equipment is connected to a RGW via analogue link 45. Local exchange is connected to a HGW via link 25. HGW is connected to RGW via IP network 70. Links 15 and 45 are directly connected to analogue telephony equipment 10 and 40, via standard analogue lines (e.g. 2-wire copper). Links 35 and 25 between narrowband multiplexer 30 and local exchange 20 and between local exchange 20 and HGW 60 are V5 links, i.e. supporting V5 protocol. The links between RGW and IP network and between HGW and D? network are IP connections (e.g. Ethernet2) supporting (amongst other protocols) MGCP.

In Figure 1, analogue line signalling information is passed between a local exchange 20 and end users 10 and 40. For a conventional connection this is achieved by passing the signalling information using the V5 PSTN protocol between an access multiplexer 30 connected to the telephony equipment 10 and the local exchange 20. Here,. The access multiplexer 30 is responsible for generating and detecting the line signals at the analogue interface to the local telephony equipment 10 and for passing all V5 signalling to the local exchange 20 over the PSTN using specific El PCM timeslots known as C- Channels. With an D? network 70 within the access network (i.e. between telephony equipment 40 and local exchange 20) the functionality conventionally provided by access multiplexer 30 is effectively divided between the HGW and the RGW. The HGW is responsible for terminating the V5 signalling received from the local exchange 20 and the RGW is responsible for detecting and generating line conditions on analogue line 45 to telephony equipment 40. The line signalling information is passed between the two gateways 50, 60 using the extended MGCP protocol according to the present invention. Advantageously, use of the present invention allows both sets of telephony users to experience the same level of PSTN service.

Figure 2 illustrates the way underlying transport protocols change as the PSTN signalling is passed between the IP and PSTN worlds and in particular the use of the MGCP experimental parameter for transporting V5 PSTN signalling information. Fig 2 illustrates the V5 PSTN signalling being terminated at the HGW 60, this includes the PSTN layer 2 (V5 PSTN data link or DL) and the layer 3 (V5 PSTN protocol). Only the information elements within the PSTN protocol are passed over the IP network. This information is passed (as detailed below) within the X- parameter of MGCP messages. At the RGW 50 any received information is extracted from the X- parameter and the relevant signals applied at the analogue line 45. Similarly events detected at the RGW 50 are mapped to V5 PSTN information elements and passed over the IP network 70 as part of X- parameters within MGCP messages. The standard MGCP transport mechanism is employed for all MGCP messages, that is the UDP protocol utilising the standard IP protocol. These messages can then be passed over any recognised data link/physical layer (e.g. Ethernet, although other media may be used).

The general principal is that V5 PSTN signalling information shall be transported unchanged using an MGCP experimental parameter X- (for example X-052). All V5 signalling may be transported in this way, including V5 response messages such as Pulse Notification and Autonomous Signalling Sequence Response. A typical X- parameter according to the present invention is shown here. For example, a request to apply line reversal may be transported in the following string:

X-052: 02 03 01 81

The information that follows the parameter (i.e. after the colon) is coded as ASCII hexadecimal octets separated by spaces. The information within this parameter string is based on the V5 PSTN signalling frame contents. The first octet defines the V5 PSTN message type. In the above example the message type is defined by "02" to be message type SIGNAL. This is followed by all of the information element contents of the equivalent V5 PSTN frame. In the above example the information element contents is "03 01 81" indicating "Steady Signal Type Information Element". In addition to the PSTN signalling information elements the PSTN protocol messages also include a sequence number element. The sequence number is used to ensure successful message delivery across the V5 interface and is not passed to over the IP network 70.

The above "X minus" parameter is defined as "non-critical" in RFC 2705. By "non- critical" is meant that any X-052 experimental parameter received by an MGCP entity that does not recognise the parameter may safely ignore it.

MGCP also controls the setting up and clearing down of media paths. As a result, the use of MGCP to convey V5 PSTN signalling according to the present invention, advantageously also allows it to be used for the media path control, so removing the need for two protocols - one for signalling and one for media.

The messages transported between the RGW and HGW are the line signal part of the V5 PSTN Protocol (FE primitives) and the port control part of the V5 Control Protocol. Examples of these messages are given below.

In the following the MGCP codings of the requested verbs NTFY (notify) and RQNT (notification request) and the MGCP parameters X (request identifier) and O (observed events) are as defined in RFC 2705 (see e.g. section 3.2 thereof).

V5 PSTN Protocol Messages can be sent in both directions (i.e. RGW-^HGW and HGW^RGW) across IP Network 70. The MGCP message used to transport the V5 PSTN Protocol messages is dependent on the direction of the message, as shown below.

MGCP messages used in the direction RGW- HGW have the general format:

NTFY <TI> <EI> <PV>

X: 0

O: oc

X-052: nn nn nn nn

Where "nn" represents a pair of ASCII encoded hexadecimal octets.

This signal is used to transmit such messages as Pulse Notification, Disconnect Indication, Signal(resources unavailable), Autonomous Signalling Sequence Response etc. For example the register recall signal message is as follows: NTFY <TI> <EI> <PV>

X: 0

O: oc

X-052: 02 02 01 F6

MGCP messages used in the direction HGW->RGW have the general format:

RQNT <TI> <EI> <PV>

X: 0

X-052: nn nn nn nn

This signal is used to transmit such messages as establish, signal, disconnect, etc. By way of example, the following message may be sent from the HGW to the RGW.

Cadence Ring Signal:

RQNT <TI> <EI> <PV>

X: 0

X-052: 02 01 03 82

V5 Port Protocol Messages are sent in the direction from the HGW to the RGW only. The MGCP message format is illustrated below by way of example for the two V5 Port Control messages. Port Control Unblock:

RQNT <TI> <EI> <PV>

X: 0

X-052: 10 11

Port Control Block:

RQNT <TI> <EI> <PV>

X: 0

X-052: 10 13

Two call scenarios are detailed below in the tables 1 and 2. Both depict a user initiated call. In table 1 a conventional HGW attempts to map V5 PSTN signalling onto conventional MGCP. Signals that cannot be mapped in this way are identified. Table 2 shows the HGW using the extended protocol, according to the present invention. This method allows all signals to be mapped thus providing the user with a greater level of service capability.

The following sequences only detail the PSTN signalling part of the call. The control of the bearer path is not shown. Table 1.

A typical PSTN call sequence (UK national map) in which to the HGW maps V5 signalling to standard MGCP - User Initiated call, calling side clears

Reversed line feed and disconnect clear pulses cannot be passed using standard MGCP. The following sequence illustrates how this can be achieved using the extended MGCP protocol.

Table 2.

A typical call sequence (UK national map) using this protocol - User Initiated call, calling side clears

Claims

1. A protocol for the transport of V5 signalling in which the signalling is transported in a media gateway control protocol (MGCP) experimental parameter.

2. A communications system comprising an internet protocol (D?) network comprising means for transporting V5 signalling messages across the IP network.