Abstract:
A method and apparatus in a gateway node of a telecommunications network for receiving frames from a source node such as a Radio Network Controller (RNC) and forwarding the frames with correct sequencing and timing to a destination node in an IP Multimedia Subsystem (IMS) network. Upon determining that a potential or actual discontinuity in frame numbering has occurred, the apparatus sends a discontinuity indication toward the destination node. The indication may be included in the first frame subsequent to the discontinuity. The destination node is thus made aware that the frame numbering may not be reliable.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    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. 
         [0003]    2. Description of the Related Art 
         [0004]    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. 
         [0005]    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 3 rd  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. 
         [0006]    The standardisation of UMTS has progressed in phases. The first phase was known as Release &#39;99. The Release &#39;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 &#39;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 &#39;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. 
         [0007]    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. 
         [0008]    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. 
         [0009]    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  FIG. 1  of the accompanying drawings. The Iu user plane protocol is used to transfer Radio Access Bearers (RABs) containing user generated data on the Iu interface between the UMTS Terrestrial Radio Access Network (UTRAN) and the UMTS Core Network (CN); for CS services this would be between the Radio Network Controller (RNC) of the UTRAN and the Circuit Switched Media Gateway (CS-MGw) of the CS-CN. The Nb user plane protocol is used on the Nb interface within the CS-CN between the CS-MGws. The functionality inside the Iu and the Nb user plane protocols is identical for the most part. The major difference is that the protocols are used on different interfaces. 
         [0010]    With reference to  FIG. 1 , the RNC transforms the user plane protocols used in the RNC into an Iu user plane format, and uses a data bearer to transport the Iu frames to the CN. The CS-MGw terminates the Iu frames sent by the RNC and possibly processes the payload. Finally, the CS-MGw frames the payload into an Nb user plane format and sends it to another CS-MGw in the CN. The Iu and Nb user plane protocols are designed to be data bearer independent. This means that the user plane can be easily adapted to use different transport technologies. 
         [0011]    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&#39;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). 
         [0012]    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. 
       SUMMARY OF THE INVENTION 
       [0013]    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. 
         [0014]    The frame numbers may be generated and included in their respective frames at the source node. 
         [0015]    The method may comprise including the discontinuity indication in at least one of the subsequent frames sent towards the destination node. 
         [0016]    The method may comprise including the discontinuity indication in at least the first subsequent frame. 
         [0017]    The method may comprise including the discontinuity indication only in the first subsequent frame. 
         [0018]    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. 
         [0019]    The frames may derive from a further node of the network. The further node may be a mobile node. 
         [0020]    The telecommunications network may be a Universal Mobile Telecommunications System. 
         [0021]    The or each source node may comprise a Radio Network Controller. 
         [0022]    Frames received from the source node may be sent in the Iu User Plane. 
         [0023]    Frames sent from the gateway node may be sent in the Nb User Plane. 
         [0024]    The frames may be PDU type 0 or PDU type 1 frames. 
         [0025]    The discontinuity indication may be included in a spare extension part of such a PDU type 0 or PDU type 1 frame. 
         [0026]    The spare extension part may comprise at least one bit of a spare octet. 
         [0027]    The discontinuity indication may be sent in a control message. The control message may be a PDU type 14 frame. 
         [0028]    The method may comprise determining that a potential or actual discontinuity in frame numbering has occurred when a Serving Radio Network Subsystem relocation happens. 
         [0029]    The mobile node may be a User Equipment. 
         [0030]    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. 
         [0031]    The method may comprise transmitting frames towards the destination node via a further gateway node. 
         [0032]    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. 
         [0033]    The method may comprise determining whether such a potential or actual discontinuity in frame numbering has occurred. 
         [0034]    The destination node may be a node of an IP Multimedia Subsystem. 
         [0035]    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. 
         [0036]    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. 
         [0037]    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. 
         [0038]    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. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0039]      FIG. 1 , discussed hereinbefore, illustrates schematically various nodes in a call chain within a UMTS network; 
           [0040]      FIG. 2  is a generic diagram for use in illustrating both a problem with interworking of known UMTS protocols with the IMS, and also how this problem is addressed with an embodiment of the present invention; 
           [0041]      FIG. 3  illustrates schematically the flow of frames across the parts illustrated in  FIG. 2 , and illustrates frame numbers both before and after Serving Radio Network Subsystem relocation; 
           [0042]      FIG. 4  shows a general PDU type 0 frame that is used in one embodiment of the present invention to convey information relating to frame numbering; and 
           [0043]      FIG. 5  shows a PDU type 0 frame more particularly when used in one embodiment of the present invention to convey information relating to frame numbering. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0044]    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  FIGS. 2 and 3 . 
         [0045]      FIG. 2  illustrates schematically a UE relocating from RNC 1  to RNC 2 , with RNC 1  and RNC 2  being in communication with MGw 1  using the Iu protocol, which in turn is in communication with MGw 2  using the Nb protocol, which itself is a gateway to the IMS.  FIG. 3  illustrates schematically the flow of frames (e.g. speech frames) between the parts illustrated in  FIG. 2 , the frames originating from the UE, and shows example frame numbers both before and after SRNS relocation. 
         [0046]    Before the relocation event, the RNC 1  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 MGw 1 . The frame numbers are for use in correctly sequencing and/or timing the frames at the intended destination node. The MGw 1  includes these frame numbers in the corresponding respective Nb frames sent to the MGw 2  (which in turn uses these frame numbers to generate timing information for frames with data sent onward to the IMS). 
         [0047]    After frame  2 , a relocation event occurs such that the UE is communicating with RNC 2  instead of RNC 1  from frame  3 . The RNC 2  would generally have no knowledge of the frame sequence that RNC 1  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. 
         [0048]    The MGw 2  also does not have information that an SRNS relocation has occurred. If MGw 2  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 MGw 2  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. 
         [0049]    It might be considered that, to address this issue, RNC 2  would simply need information on the last frame number used by RNC 1 . However, to handle the correct timing of this would be difficult to achieve practically. 
         [0050]    It might also be considered to address this issue by keep the frame number consistent at the MGw 1 , such that MGw 1  would correct the numbering when it is determined that RNC 2  is using an “incorrect” frame number sequence. However, this would require that MGW 2  modifies each packet from RNC 2 , and this would consume extra capacity; also it would not be in accordance with the TrFO principle to be transparent to the frames. 
         [0051]    The above-mentioned issue would instead addressed according to an embodiment of the present invention by sending an indication (a “discontinuity indication”) from the MGw 1  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. 
         [0052]    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,  FIG. 4  shows a PDU type 0 frame having the spare extension at the end, comprising up to four octets. A receiver would typically ignore the spare extension if it does not have the capability to understand it. 
         [0053]      FIG. 5  shows the use of one of the spare extension octets in an embodiment of the present invention to send an indication of when a new frame number sequence is started (discontinuity). One bit of the extra information field (for example, bit seven) is set to 1 to indicate when the frame number has started from a new position, leaving the remaining bits available for other purposes. When the frame number is not started from a new position (no discontinuity), which would generally be the most common situation, the extra information octet need not be present. However, if certain bits of the spare extension are being used for other purposes, then the bit allocated for the frame number indication would simply be set to 0. 
         [0054]    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. 
         [0055]    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. 
         [0056]    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. 
         [0057]    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. 
         [0058]    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. 
         [0059]    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.