Patent Application
20100014456
1. Field of the Invention
The present invention relates to a method and apparatus for use in a communications network, for example in a Universal Mobile Telecommunications System, particularly where interoperating with an IP Multimedia Subsystem.
2. Description of the Related Art
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
By way of background, UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packets switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.
The standardisation of UMTS has progressed in phases. The first phase was known as Release '99. The Release '99 specifications define the basic architecture that consists of the UMTS Terrestrial Radio Access Network (UTRAN), Circuit Switched Core Network (CS-CN) and Packet Switched Core Network (PS-CN). The release '99 specification offers traditional circuit as well as packet-switched services. The next phase in the standardisation process was Release 4, adding new services to the '99 architecture. Release 5 represented a significant shift, offering both traditional telephony as well as packet-switched services over a single converged packet-based network.
The UMTS Release 5 architecture added a new subsystem known as the IP Multimedia Subsystem (IMS) to the PS-CN for supporting traditional telephony as well as new multimedia services. IMS provides IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
Specific details of the operation of a UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS which are available from http://www.3gpp.org.
In a Universal Mobile Telecommunications System (UMTS) network, the “user plane” is used to carry data streams of user-generated information such as speech or data. The user plane consists of both the actual user generated data streams and the data bearers used to transport the data streams. It is important to understand how user plane protocols work, as besides transporting speech they also carry valuable information regarding the quality of the connection. The interoperability of the Iu (3GPP TS 25.415) and Nb (3GPP TS 29.415) user plane protocols is shown in
With reference to
Iu and Nb user plane protocols allow the sending entity to include in the frame header a sequence number and a checksum calculated over the contents of the frame. When the peer Iu/Nb protocol entity receives the frame, it first checks the header checksum and discards the frame if the checksum is bad. If the header checksum is correct, but the payload is damaged, the frame's FQC field is set to “Bad”. This information can be used to estimate speech quality, and lost frames can be detected based on the frame number field in the frame header (only Iu/Nb frames with PDU Type 0 and PDU Type 1 are used to carry speech, so speech quality estimation can ignore all the PDU Type 14 control frames).
These protocols may use a frame number with values from 0 to 15 that can be based on time. The frame number is incremented by one at each new time interval (and after value 15 the value 0 is again used). For example, for the Adaptive Multi-Rate (AMR) codec (3GPP TS 26.102) the frame number is stepped at each new 20 ms interval. The frame number may be useful at the receiver to know the timing of the frame, e.g. when the frame should be played out, especially when there is big delay variation in the network.
According to a first aspect of the present invention there is provided a method for use by a gateway node of a telecommunications network that is arranged to receive frames from a source node for onward transmission towards a destination node, the frames including respective frame numbers for use in correctly sequencing and/or timing the frames at the destination node, and the method comprising, when it is determined that a potential or actual discontinuity in frame numbering has occurred that might cause incorrect sequencing and/or timing at the destination node of frames numbered subsequent to the discontinuity in relation to frames numbered prior to the discontinuity, sending a discontinuity indication towards the destination node to notify the destination node of the potential or actual discontinuity.
The frame numbers may be generated and included in their respective frames at the source node.
The method may comprise including the discontinuity indication in at least one of the subsequent frames sent towards the destination node.
The method may comprise including the discontinuity indication in at least the first subsequent frame.
The method may comprise including the discontinuity indication only in the first subsequent frame.
The source node may be one of a plurality of such source nodes, and the method may comprise determining that a potential or actual discontinuity in frame numbering has occurred when the source node from which the gateway node is receiving frames changes from one source node to another of the plurality.
The frames may derive from a further node of the network. The further node may be a mobile node.
The telecommunications network may be a Universal Mobile Telecommunications System.
The or each source node may comprise a Radio Network Controller.
Frames received from the source node may be sent in the Iu User Plane.
Frames sent from the gateway node may be sent in the Nb User Plane.
The frames may be PDU type 0 or PDU type 1 frames.
The discontinuity indication may be included in a spare extension part of such a PDU type 0 or PDU type 1 frame.
The spare extension part may comprise at least one bit of a spare octet.
The discontinuity indication may be sent in a control message. The control message may be a PDU type 14 frame.
The method may comprise determining that a potential or actual discontinuity in frame numbering has occurred when a Serving Radio Network Subsystem relocation happens.
The mobile node may be a User Equipment.
The gateway node may comprise a Media Gateway. The gateway node need not be the first gateway node in the communications path following the source node.
The method may comprise transmitting frames towards the destination node via a further gateway node.
The frame numbers may provide information relating to the timing of their respective frames. The destination node and/or the further gateway node may use the frame numbers to generate timing information relating to their respective frames. The further gateway node may include such timing information in the frames transmitted onwards towards the destination node, instead of or as well as the corresponding respective frame numbers. Frames need not be numbered according to a sequential scheme, or a scheme requiring translation of frame numbers into timing information. For example, frame numbers may indicate more directly the timing of their respective frames.
The method may comprise determining whether such a potential or actual discontinuity in frame numbering has occurred.
The destination node may be a node of an IP Multimedia Subsystem.
According to a second aspect of the present invention there is provided an apparatus for use as a gateway node of a telecommunications network that is arranged in use to receive frames from a source node for onward transmission towards a destination node, the frames including respective frame numbers for use in correctly sequencing and/or timing the frames at the destination node, and the apparatus comprising means for sending, when it is determined that a potential or actual discontinuity in frame numbering has occurred that might cause incorrect sequencing and/or timing at the destination node of frames numbered subsequent to the discontinuity in relation to frames numbered prior to the discontinuity, a discontinuity indication towards the destination node to notify the destination node of the potential or actual discontinuity.
According to a third aspect of the present invention there is provided an operating program which, when run on an apparatus, causes the apparatus to carry out a method according to the first aspect of the present invention.
According to a fourth aspect of the present invention there is provided an operating program which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the second aspect of the present invention.
The operating program may be carried on a carrier medium. The carrier medium may be a transmission medium. The carrier medium may be a storage medium.
The applicants have identified the following potential problem with the above-described existing frame numbering system used in the Iu and Nb protocols. When the network entity that is generating the frame numbers changes, the frame numbers will typically start from a new random position, because the new network entity will typically not have information concerning the frame number that the old source was using at the time when the switch occurred. This may happen, for example, at a Serving Radio Network Subsystem (SRNS) relocation situation, where the changing network entity is the RNC. This situation will now be explained further with reference to
Before the relocation event, the RNC1 receives frames 1 and 2 in turn from the UE, and generates sequential frame numbers X and X+1 for inclusion in respective Iu frames sent onward to the MGw1. The frame numbers are for use in correctly sequencing and/or timing the frames at the intended destination node. The MGw1 includes these frame numbers in the corresponding respective Nb frames sent to the MGw2 (which in turn uses these frame numbers to generate timing information for frames with data sent onward to the IMS).
After frame 2, a relocation event occurs such that the UE is communicating with RNC2 instead of RNC1 from frame 3. The RNC2 would generally have no knowledge of the frame sequence that RNC1 was using, and therefore starts frame number sequencing independently from a position Y instead of position X+2 as it ideally would for continuity with the previous frame numbering (there are no frame numbers sent from the UE to the RNCs that could be used either). A discontinuity in frame numbering has therefore occurred that might cause incorrect sequencing and/or timing, at the destination node, of frames numbered subsequent to the occurrence of the discontinuity in relation to frames numbered prior to the discontinuity.
The MGw2 also does not have information that an SRNS relocation has occurred. If MGw2 relies on the frame number being based on time, then it will make a wrong decision 15 times out of 16 for the timing. As the MGw2 is sending the data in the frames onward towards the IMS, it will be sending wrong information in the RTP timestamp (see IETF RFC 3550, “RTP: A Transport Protocol for Real-Time Applications”). This is against the IETF RTP specification. A possible consequence of this is that the timing of the playout of frames may be changed, leading to quality problems, for example for a Voice over Internet Protocol (VoIP) service.
It might be considered that, to address this issue, RNC2 would simply need information on the last frame number used by RNC1. However, to handle the correct timing of this would be difficult to achieve practically.
It might also be considered to address this issue by keep the frame number consistent at the MGw1, such that MGw1 would correct the numbering when it is determined that RNC2 is using an “incorrect” frame number sequence. However, this would require that MGW2 modifies each packet from RNC2, and this would consume extra capacity; also it would not be in accordance with the TrFO principle to be transparent to the frames.
The above-mentioned issue would instead addressed according to an embodiment of the present invention by sending an indication (a “discontinuity indication”) from the MGw1 when it determines that a new frame number sequence has been started, so that a user of the frame number is able to determine whether or not the frame number can be relied upon. Such a discontinuity indication is sent towards the intended destination node in order to notify the destination node of a potential or actual discontinuity in frame numbering that might cause incorrect sequencing and/or timing, at the destination node, of frames numbered subsequent to the discontinuity in relation to frames numbered prior to the discontinuity.
One embodiment of the present invention makes use for this purpose of a spare extension field provided at the end of a PDU type 0 or PDU type 1 frame for data sent in the Iu and Nb User Plane (see 3GPP TS 25.415). By way of illustration,
For an SRNS relocation, the MGw that performs switching from the old RNC to the new RNC indicates when it has performed the switch using the extra information field, with the correct bit set as appropriate, in the first frame that uses the new frame number.
It will be appreciated that there are alternative methods for sending the indication. For example, it may be sent in a separate control message, for example a PDU type 14 frame (see 3GPP TS 25.415, “UTRAN Iu interface user plane protocols”). Either a new procedure for this indication can be provided, or the new information can be added to an existing procedure, e.g. rate control. A skilled person would fully appreciate how such an indication can be provided in many different ways.
With an embodiment of the present invention, a receiver is able to use the frame number for timing information more reliably. This has benefits to the service quality, e.g. speech quality.
Also, when an UMTS network is interoperating with an IMS network, a correct RTP timestamp (see IETF RFC 3550) must be used in the IMS network, so as not to produce problems e.g. for playout of a VoIP service. With the extra information relating to a potential or actual discontinuity in the frame numbering according to an embodiment of the present invention, the RTP timestamp can be set correctly, and therefore the service quality can be improved, e.g. for connections from UMTS to IMS. This has relevance to the 3GPP TS 29.163 (“Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks”) and 3GPP TS 29.415 amongst others.
Although an embodiment of the present invention is described above in the context of a UMTS network interoperating with an IMS network, it will be appreciated that notification of a potential or actual discontinuity in frame numbering in a manner corresponding to that described above will have relevance to other types of communications networks.
It will be appreciated that operation of one or more of the above-described components can be controlled by a program operating on the device or apparatus. Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website. The appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2006/050666 | 2/3/2006 | WO | 00 | 12/15/2008 |
