GB2368243A

GB2368243A - Error handling in the Iur interface of a UMTS terrestrial radio access network

Info

Publication number: GB2368243A
Application number: GB0024765A
Authority: GB
Inventors: Bjoerrn Ehrstedt; Toomas Wigell; Mikael Jan Are Winberg
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2000-10-10
Filing date: 2000-10-10
Publication date: 2002-04-24
Anticipated expiration: 2020-10-10
Also published as: GB2368243B; GB0024765D0

Abstract

In a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FC_CF) sent from the DRNC to the SRNC, where the FC_CF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC. The method comprises starting a timer at the SRNC when a data frame is sent from the SRNC to the DRNC and, in the event that the timer expires before a FC_CF is received by the SRNC from the DRNC, either sending a further data frame or a credit request from the SRNC to the DRNC.

Description

Error Handling in the Iur Interface of a UMTS Terrestrial Radio Access Network Field of the Invention The present invention relates to error handling at the Iur interface of a UMTS Terrestrial Radio Access Network (UTRAN), the Iur interface being the interface between Radio Network Controllers (RNCs) of the UTRAN. More particularly, the present invention relates to handling errors resulting from the loss of data frames (DFs) and/or Flow Control control frames (FC~CFs) sent across the Iur interface.

Background to the Invention The European Telecommunications Standardisation Institute (ETSI) is currently in the process of standardising a new set of protocols for mobile telecommunications systems.

The set of protocols is known collectively as the Universal Mobile Telecommunications System (UMTS). Figure 1 illustrates schematically a UMTS network 1 which comprises a core network 2 and a UMTS Terrestrial Radio Access Network (UTRAN) 3. The UTRAN 3 comprises a number of Radio Network Controllers (RNCs) 4, each of which is coupled to a set of neighbouring Base Transceiver Stations (BTSs) 5. Each BTSs 5 is responsible for a given geographical cell and the controlling RNC 4 is responsible for routing user and signalling data between that BTS 5 and the core network 2. All of the RNCs are coupled to one another. A general outline of the UTRAN 3 is given in Technical Specification TS 25.401 V3.3. 0 (1999-09) of the 3rd Generation Partnership Project, 3GPP.

User and signalling data may be carried between an RNC and a mobile terminal (referred to in UTRAN as User Equipment (UE)) using Radio Bearers (RBs).

Typically, a mobile terminal is allocated one or more RBs, each of which is capable of carrying a flow of user or signalling data. At a Radio Link Control (RLC) entity, RBs are mapped onto respective logical channels. At a Media Access Control (MAC) entity, a set of logical channels is mapped in turn onto a transport channel, of which there are two types: a"common"transport channel which is shared by different mobile terminals and a"dedicated"transport channel which is allocated to a single mobile terminal. One

type of common channel is a Forward Access CHannel (FACH). Several transport channels (e. g. FACHs) are in turn mapped at the physical layer onto a Secondary Common Control Physical CHannel (S-CCPCH) for transmission over the air interface between a BTS and a mobile terminal.

When a mobile terminal registers with an RNC, via a BTS, that RNC acts at least initially as both the serving and controlling RNC for the mobile terminal. The RNC both controls the air interface radio resources and terminates the layer 3 intelligence (Radio Resource Control (RRC) protocol), routing data associated with the mobile terminal directly to and from the core network. Figure 2 illustrates the protocol model for the FACH transport channel when the serving and controlling RNCs are coincident

and where Uu indicates the interface between UTRAN and the mobile terminal (lue), and lub indicates the interface between the RNC and a NodeB (where NodeB is a generalisation of a BTS). It will be appreciated that the MAC (MAC-c) entity in the RNC transfers MAC-c Packet Data Units (PDUs) to the peer MAC-c entity at the mobile terminal, using the services of the FACH Frame Protocol (FACH FP) entity between the RNC and the NodeB. The FACH FP entity adds header information to the MAC-c PDUs to form FACH FP PDUs which are transported to the NodeB over an AAL2 (or other transport mechanism) connection. An interworking function at the NodeB interworks the FACH frame received by the FACH FP entity into the PHY entity.

Consider now the situation which arises when a mobile terminal leaves the area covered by a RNC with which the terminal is registered, and enters the area covered by a second RNC. Under the UTRAN protocols, the RRC remains terminated at the first RNC whilst the terminal takes advantage of a cell and common transport channel of the second RNC. Thus, the first RNC remains as the serving RNC with a connection to the core network whilst the second RNC becomes the controlling RNC. The controlling RNC is in control of the NodeB where the mobile terminal is located and in particular of the logical resources (transport channels) at that NodeB. In this scenario the controlling RNC is referred to as a"drift"RNC (the controlling RNC will also be acting as a serving RNC for mobile terminals registered with that RNC). The protocol model for the FACH transport channel when the serving and controlling RNCs are separate is

illustrated in Figure 3. It will be noted that a new interface Iur is exposed between the serving and the controlling RNCs. An lur FACH FP is used to interwork the Common MAC (MAC-c) at the controlling RNC with the Dedicated MAC (MAC-d) at the serving RNC.

In order to make efficient use of the radio resources (controlled by the drift RNC) for FACH and Dedicated Shared Channels (DSCH), the sending of data from a MAC-d entity (in so-called data frames (DFs) ) from the SRNC to the DRNC is regulated using Flow Control control frames (FC-CF) which are sent to the SRNC by the DRNC for a given UE (under the control of the MAC-c entity at the DRNC). An FCCF contains credits which define the number of packets which a user may transmit and are used by the DRNC to control the user data flow from the SRNC. Credits are initially allocated and sent to the SRNC following the creation of a UE context at the DRNC.

A problem with the described flow control mechanism is that DFs sent from the SRNC to the DRNC, or the credits sent to the SRNC in FCCFs, may be lost on the lur interface. In the former case, the DRNC will assume that the SRNC has not used the previously allocated credits and will not issue further credits. In the latter case, the SRNC, having used up its existing credits, will be waiting for further credits from the DRNC. In both scenarios, the system will hang.

Statement of the Invention It is an object of the present invention to overcome or at least mitigate the disadvantages of existing flow control mechanisms for the Iur interface of UTRAN. This and other objects are achieved, at least in part, by the use of timers in the SRNC and/or drift RNC to report the absence of a response to the sending of a DF or FCCF.

According to a first aspect of the present invention there is provided in a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FCCF contains a

credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising : starting a timer at the SRNC when a data frame is sent from the SRNC to the DRNC; and in the event that the timer expires before a FCCF is received by the SRNC from the DRNC, either sending a further data frame or a credit request from the SRNC to the DRNC.

According to a second aspect of the present invention there is provided in a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FCCF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising: starting a timer at the DRNC when a FCCF is sent from the DRNC to the SRNC; and in the event that the timer expires before a data frame is received by the DRNC from the SRNC, sending a further FCCF from the DRNC to the SRNC.

Embodiments of the present invention may be employed for different kinds of traffic channel extending over the Iur interface. For example, the invention may be applied to FACH and DSCH traffic channels.

In a multi-vendor environment, it is possible that a UTRAN may comprise RNCs supplied by different vendors. In this case, no assumptions can be made regarding the fault handling capabilities of a peer RNC. In a preferred embodiment of the present invention, the methods of both the first and second aspects of the present invention are employed at a single RNC. Thus, the RNC is able to deal with errors arising when the RNC is operating as either a SRNC or a DRNC.

According to a third aspect of the present invention there is provided a Radio Network Controller (RNC) for use in a UTRAN, the RNC having processing means for implementing the method of the above first and/or second aspects of the invention.

Brief Description of the Drawings Figure 1 illustrates schematically a UMTS network comprising a core network and a UTRAN; Figure 2 illustrates a protocol model for a FACH transport channel when serving and controlling RNCs of the UTRAN of Figure 1 are coincident; Figure 3 illustrates a protocol model for a FACH transport channel when serving and controlling RNCs of the UTRAN of Figure 1 are separate; Figure 4 illustrates a known flow control mechanism for the lur interface of the UMTS network of Figure 1;

Figures Sa to 5c illustrate signalling associated with an error control mechanism implemented at a SRNC of a UTRAN; and Figures 6a to 6c illustrate signalling associated with an error control mechanism implemented at a DRNC of a UTRAN.

Detailed Description of a Preferred Embodiment The general structure of a UMTS network has been described above with reference to the schematic drawing of Figure 1. Protocol models for the FACH transport channel have also been described with reference to Figures 2 and 3 for the cases where the serving RNC and controlling RNC are both coincident and separate.

Considering the scenario illustrated in Figure 3, where a mobile terminal communicates with the core network of a UMTS system via separate serving and drift RNCs within the UTRAN, signalling and user data packets destined for the mobile terminal are received at an RLC entity (not shown) of the serving RNC from the core network and are "mapped"onto logical channels, namely a Dedicated Control CHannel (DCCH) and a Dedicated traffic CHannel (DTCH). These logical channels are received by the MAC-d entity which constructs MAC-c/sh Service Data Units (SDUs) comprising a payload section containing logical channel data and a MAC header containing amongst other

things a logical channel identifier. SDUs are transported over the lur interface between the MAC-d entity and the MAC-c entity using data frames (DFs). One DF may include

one or more SDUs of the same size and having the same"priority". A data frame also includes the user's buffer size, i. e. the amount of data in the RLC buffers (for a given priority).

As already described, Flow Control control frames (FCCFs) are used to transport control information from the DRNC (MAC-c entity) to the SRNC (MAC-d entity). Where the User is making use of a FACH channel, a FACH FCCF will comprise a common channel priority indicator and an amount of credits for that priority. The credits indicate the number of MAC-c/sh SDUs which the MAC-d entity is allowed to transmit ("Credits"= 0 means stop the transmission, while"Credits"="unlimited" means that an unlimited number of SDUs may be transmitted). This flow control mechanism is illustrated in Figure 4.

After establishment of common transport channel resources for a given DE in the DRNC, the UE has a certain number of (Initial) Credits. When user data arrives, the SRNC will transmit an appropriate number of user packets (MAC-c/sh SDUs) using FACH DF (s) to the DRNC. Additional credits are granted to the UE by the Flow Control function in the DRNC by sending a FCCF to the SRNC for that particular UE.

Under the current UMTS proposals, if the initial DF (s) with user packets sent using the Initial Credits is lost (or erroneously received), and these initial DF (s) consume all initial credits, then further data transmission is stopped. This is because the DRNC will be assuming that the SRNC has Initial Credits while the SRNC has in fact already used its Initial Credits and is waiting for the new Credits. Loss or erroneous reception of FCCFs from the DRNC may also cause a deadlock to occur in the data transmission from the SRNC to the DRNC. When the DRNC has received a DF with user buffer size information from the SRNC, its flow control function calculates new Credits for that user and sends them (if any) with the FCCF message to the SRNC. If this FCCF is lost (or erroneously received), then further data transmission is stopped because the SRNC has not received any new Credits.

The deadlock condition due to lost (or erroneously received) DFs or FCCFs can be avoided by introducing supervision of FC~CFs in the SRNC. More particularly, after

transmission of a DF from the SRNC, the SRNC starts time supervision for receipt of a corresponding FCCF from the DRNC. A number of different responses may be used to handle expiration of the timer. These responses are: 'the SRNC transmits an empty DF with user buffer information to the DRNC if a) it has any user data to send, or b) the user buffer level exceeds a certain threshold value-see Figure 5a ; . the SRNC transmits a new DF with subsequent user data using initial credits with user buffer information to the DRNC if a) it has any user data to send, or b) the user buffer level exceeds a certain threshold value-see also Figure 5a ; . the SRNC requests new credits, sending a Capacity Request CF (CRCF) with user buffer information to the DRNC if a) it has any user data to send, or b) the user buffer level exceeds a certain threshold value-see Figure 5b; . the SRNC repeats transmission of the last transmitted DF, see Figure 5c.

The deadlock condition due to lost (or erroneously received) DFs or FCCFs can alternatively be avoided by introducing supervision for DFs in the DRNC. The DRNC should start time supervision after establishment of common transport channel resources for a given UE in the DRNC to supervise reception of initial DFs-see Figure 6a. It should also start time supervision after sending of FCCFs to the SRNC to supervise reception of subsequent DFs-see Figures 6b and 6c. At timer expiration, the DRNC recalculates the new credits for that user and sends them (if any) with a new FCCF message to the SRNC.

The supervision time on the DRNC side could have e. g. three different values: . a long value for the case when the DRNC doesn't know which common channels the user is currently using (situation after establishment of common transport channel resources for a given UE in the DRNC before receiving the first DF); a medium-long value if the user queue was indicated as empty. In this case the time point of arriving of new user packets from the SRNC is unknown;

a short value for the case when the SRNC is indicated to have queuing packets.

It is preferable to use a combination of supervision at the DRNC and at the SRNC. The loss (or erroneous reception) of initial DF (s) should be discovered by fault supervision in the SRNC. After establishment of common transport channel resources for a given UE in the DRNC, and before receiving the first DF, the DRNC doesn't know, which common channels the SRNC will use. The supervision in the DRNC would trigger

sending of new FCFCs for all DRNC channels (e. g. 16 different channels). The SRNC will probably use only a limited number of common logical channels, i. e. FCCFs sent for unused channels are superfluous. Therefore the supervision for initial DFs should be implemented in the SRNC. Supervision in the DRNC will be used only as a backup supervision if there is no fault supervision in the SRNC.

After initial DFs have arrived in the DRNC, the primary fault supervision should be handled in the DRNC. The DRNC is aware of the number of users, their priorities and user buffer levels, and has control of transmission on common channels. It controls when and how many packets should be transmitted from different users. Supervision in the SRNC will be used only as a backup supervision if there is no fault supervision in the DRNC.

It will be appreciated by those of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention.

Claims

Claims 1. In a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FCCF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising: starting a timer at the SRNC when a data frame is sent from the SRNC to the DRNC; and in the event that the timer expires before a FCCF is received by the SRNC from the DRNC, either sending a further data frame or a credit request from the SRNC to the DRNC.
2. In a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FCCF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising: starting a timer at the DRNC when a FCCF is sent from the DRNC to the SRNC; and in the event that the timer expires before a data frame is received by the DRNC from the SRNC, sending a further FCCF from the DRNC to the SRNC.
3. A method according to claim 1 or 2, wherein said data frames are sent over the Iur interface using one of a FACH and DSCH traffic channel.
4. A method comprising in combination the methods of claim 1 and 2.
5. In a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the

loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FCCF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising :

detecting the loss or erroneous reception of initial DFs by starting a timer at the SRNC when a data frame is sent from the SRNC to the DRNC and, in the event that the timer expires before a FC-CF is received by the SRNC from the DRNC, either sending a further data frame or a credit request from the SRNC to the DRNC; after initial DFs have arrived in the DRNC, starting a timer at the DRNC when a FCCF is sent from the DRNC to the SRNC and, in the event that the timer expires before a data frame is received by the DRNC from the SRNC, sending a further FC CF from the DRNC to the SRNC.

5. In a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FCCF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising:

detecting the loss or erroneous reception of initial DFs by starting a timer at the SRNC when a data frame is sent from the SRNC to the DRNC and, in the event that the timer expires before a FCCF is received by the SRNC from the DRNC, either sending a further data frame or a credit request from the SRNC to the DRNC; after initial DFs have arrived in the DRNC, starting a timer at the DRNC when a FCCF is sent from the DRNC to the SRNC and, in the event that the timer expires before a data frame is received by the DRNC from the SRNC, sending a further FCCF from the DRNC to the SRNC.

6. A Radio Network Controller (RNC) for use in a UTRAN, the RNC having processing means for implementing the method of any one of the preceding claims.

Amendments to the claims have been filed as follows 1. In a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FCCF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising: starting a timer at the SRNC when a data frame is sent from the SRNC to the DRNC; and in the event that the timer expires before a FCCF is received by the SRNC from the DRNC, either sending a further data frame or a credit request from the SRNC to the DRNC.

2. In a UMTS Terrestrial Radio Access Network (UTRAN), a method of recovering from the loss of a data frame (DF) sent from a SRNC to a DRNC or from the loss of a Flow Control control frame (FCCF) sent from the DRNC to the SRNC, where the FC CF contains a credit identifying the number of Service Data Units (SDUs) which the SRNC may subsequently send to the DRNC, the method comprising: starting a timer at the DRNC when a FCCF is sent from the DRNC to the SRNC; and in the event that the timer expires before a data frame is received by the DRNC from the SRNC, sending a further FCCF from the DRNC to the SRNC.

3. A method according to claim 1 or 2, wherein said data frames are sent over the Iur interface using one of a FACH and DSCH traffic channel.

4. A method comprising in combination the methods of claim 1 and 2.