WO2003030568A1

WO2003030568A1 - Cell updates in a umts terrestrial radio access network

Info

Publication number: WO2003030568A1
Application number: PCT/EP2002/009005
Authority: WO
Inventors: Björn EHRSTEDT
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2001-09-28
Filing date: 2002-08-12
Publication date: 2003-04-10
Also published as: GB0123308D0; GB2371179A; GB2371179B

Abstract

In a UMTS radio access network, a method of informing a serving RNC, SRNC, of the FACH transport channel configuration allocated by a drift RNC (DRNC) 5 to user equipment (UE) 7. When the UE 7 first moves into a cell of the DRNC 5, forwarding an RRC Cell Update message from the DRNC 5 to the SRNC 4, sending a RNSAP Common Transport Channel Resource Request message from the SRNC 4 to the DRNC 5, and sending a RNSAP Common Transport Channel Resource Response message from the DRNC 5 to the SRNC 4, said response containing an information element indicating whether FACH flow control information contained in the response is unique to the DRNC cell to which the procedure relates, or whether the information is common to all of the cells of the DRNC. If said information element indicates that the information is common to all of the cells of the DRNC 5, the SRNC 4 does not perform the RNSAP Common Transport Channel Resources Initialisation procedure for subsequent Cell Update messages received from the DRNC 5.

Description

Cell Updates in a UMTS Terrestrial Radio Access Network

Field of the Invention

The present invention relates to the handling of cell updates at the lur interface of a UMTS Terrestrial Radio Access Network (UTRAN), the lur interface being the interface between Radio Network Controllers (RNCs) of the UTRAN.

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). The architecture of a UMTS network is based upon a UMTS core network and a UMTS Terrestrial Radio Access Network (UTRAN). The UTRAN comprises a number of Radio Network Controllers (RNCs), each of which is coupled to a set of neighbouring Base Transceiver Stations (BTSs) or Node Bs. Each Node B is responsible for a given geographical area or cell, and the controlling RNC is responsible for routing user and signalling data between that Node B and the core network. The interface between an RNC and a Node B is referred to as the Iu interface. A general outline of the UTRAN is given in Technical Specification TS 25.401 (UTRAN overall description) of the 3rd Generation Partnership Project, 3 GPP.

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 Node B and a mobile terminal.

When a mobile terminal registers with an RNC, via a Node B, 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 1 illustrates the protocol model for the FACH transport channel when the serving and controlling RNCs are coincident and where Uu indicates the interface between the UTRAN and the mobile terminal (UE), and Iub indicates the interface between the RNC and a Node B. 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 Node B. 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 Node B 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 Node B. 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 2. It will be noted that a new interface lur is exposed between the serving and the controlling RNCs. The RNSAP protocol is used for control plane signalling on the lur interface. When a mobile terminal first moves into the coverage area of the (new) DRNC, the mobile terminal must send an RRC Cell Update message to the SRNC to inform the SRNC of its new location. The RRC Cell Update message (L3 information) is forwarded by the DRNC to the SRNC using the RNSAP UL Signalling Transfer message. Upon receipt of a Cell Update, the SRNC must determine the configuration (scheduling priority, MAC-c/sh SDU length(s), and initial window size) of the FACH transport channel used by the DRNC for the cell to which the update relates. According to the current standard, the SRNC responds to receipt of a Cell Update by sending a RNSAP Common Transport Channel Resource Request message to the DRNC over the lur interface. The DRNC responds with a RNSAP Common Transport Channel Resource Response message containing the configuration information.

In some network configurations, the FACH transport channel configuration may be the same for all cells of an RNC. In other network configurations, the configuration may differ from cell to cell. The current standard handles this situation by performing the RNSAP procedure (request and response sequence) each time a Cell Update is received at the SRNC over the lur interface, i.e. for the first and subsequent cell updates.

Summary of the Invention

The approach adopted by the current standard has two main disadvantages. Firstly, the RNSAP exchange procedure introduces a delay into the cell update procedure. This may cause an interruption in the service provided to a mobile terminal and results in a less than optimal use of radio resources. Secondly, the procedure increases the signalling load on the lur interface. In communications networks, a greater signalling load often results in higher infrastructure costs.

According to a first aspect of the present invention there is provided, in a UMTS radio access network, a method of informing a serving RNC, SRNC, of the FACH transport channel configuration allocated by a drift RNC, DRNC, to user equipment, UE, the method comprising: including in a RNSAP message sent from the DRNC to the SRNC, an information element indicating whether FACH flow control information contained in the response is unique to the DRNC cell, or whether the information is common to all of the cells of the DRNC, wherein if said information element indicates that the information is common to all of the cells of the DRNC, the SRNC does not perform the RNSAP Common Transport Channel Resources Initialisation procedure, request/response sequence, for Cell Update messages subsequently received from the DRNC.

In one embodiment of the invention, said RNSAP message is sent as part of a RNSAP Common Transport Channel Resources Initialisation procedure between the SRNC and the DRNC.

Only in the event that the RNSAP Common Transport Channel Resource Response message indicates that the FACH flow control information is not common to all cells will the RNSAP Common Transport Channel Resources Initialisation procedure be , repeated for subsequent cell updates corresponding to movement of the UE between two cells of the DRNC. Embodiments of the present invention both speed up the cell update procedure when a DRNC is involved and reduce the volume of signalling traffic over the lur interface.

In one embodiment of the present invention, the RNSAP procedure is performed when the UE first moves into a cell of the DRNC and following the forwarding of an RRC Cell Update message from the DRNC to the SRNC using the RNSAP Uplink Signalling Transfer procedure, the procedure comprising sending a RNSAP Common Transport Channel Resource Request message from the SRNC to the DRNC, and sending a RNSAP Common Transport Channel Resource Response message from the DRNC to the SRNC, one of said Cell Update message and said response containing said information element.

Brief Description of the Drawings Figure 1 illustrates a protocol model for a FACH transport channel when serving and controlling RNCs of the UTRAN are coincident;

Figure 2 illustrates a protocol model for a FACH transport channel when serving and controlling RNCs of the UTRAN are separate;

Figure 3 illustrates schematically a part of a UMTS network;

Figure 4 is a flow diagram illustrating a method of handling cell updates via lur in the

UMTS network of Figure 3; and

Figure 5 illustrates the flow of signalling information related to a cell update between a

DRNC and a SRNC.

Detailed Description of a Preferred Embodiment

Protocol models for the FACH transport channel of a UMTS network have been described with reference to Figures 1 and 2 for the cases where the serving RNC and controlling RNC are both coincident and separate. Figure 3 illustrates a part of a UMTS network comprising a core network 1 and a UMTS terrestrial radio access network (UTRAN) 2. Shown in the UTRAN 2 are a pair of Radio Network Controllers (RNCs) 4,5, each of which has control of a set of Node Bs 6. Each Node B 6 provides radio coverage of a particular geographic cell, with the cells of neighbouring Node Bs overlapping.

In the scenario illustrated in Figure 3, a UE 7 is shown communicating with one of the Node Bs of a first of the RNCs 4. The UE is assumed to move from the coverage area of the Node B of the first RNC 4 into the coverage area of a Node B of the second RNC 5. The effect of the UE 7 roaming in this way is to cause the UE to take advantage of common transport channels (RACH/FACH) of the second RNC 5, the drift RNC (DRNC). As described above, the RRC protocol remains terminated at the first RNC, the serving RNC (SRNC). The UE 7 will send an RRC Cell Update message to the SRNC 4 to inform the SRNC of its new location. This message is sent via the DRNC 5 across the lub and lur interfaces (and is the first connection between the UE and the DRNC). The Cell Update message contains the U-RNTI (SRNC Id + RNTI (Radio Network Temporary Identity)) which identifies the UE within UTRAN. At reception of the Cell Update message, the DRNC checks the U-RNTI. As the UE is not registered in the DRNC, the DRNC forwards the Cell Update message, using the RNSAP Uplink Signalling Transfer message, to the SRNC based on the SRNC Id in the U-RNTI.

When the SRNC 4 receives the first Cell Update message from the DRNC, the SRNC 4 updates its cell location register, and initiates the RNSAP Common Transport Channel Resources Initialisation procedure. This involves the sending of a RNSAP Common Transport Channel Resource Request to the DRNC. This message is a request to establish the user plane towards the DRNC 5 and for the DRNC to return to the SRNC 4 the FACH transport channel configuration for the cell in which the UE 7 is now located. As already stated above this configuration information includes the scheduling priority, MAC-c/sh SDU length(s), and initial window size.

The DRNC 5 responds to receipt of the RNSAP request message by generating and returning to the SRNC 4 a RNSAP Common Transport Channel Resource Response. This message has the following structure:

where the presence field indicates whether or not the information elements of the message are mandatory (M) or optional (O). The RNSAP response message includes an additional information element (IE) referred to as "Cell Unique FACH Flow Control Info". This element contains a flag which can be set to yes to indicate that the FACH transport channel configurations for all of the cells of the DRNC 5 are the same, or no to indicate that the configuration differs from cell to cell. The flag is set by the DRNC 5. It is noted that whilst in the above table, the additional IE is indicated as being mandatory, this need not be so and it may be included as an optional feature.

When the RNSAP response is received by the SRNC 4, the Cell Unique FACH Flow Control Info IE is analysed. If the IE is set to yes, the SRNC 4 records the fact that it must execute the RNSAP Common Transport Channel Resource Initialisation procedure for every subsequent cell update in the DRNC 5. If the IE is set to no, the SRNC 4 records the fact that the procedure is not needed for subsequent cell updates within the DRNC 5.

Figure 4 is a flow diagram further illustrating the method described above. Figure 5 illustrates the flow of signalling information over the lur interface.

It will be appreciated by the person 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. For example, it is possible that a connection between the UE and the

DRNC may exist prior to the first cell update. If the UE is using dedicated channels

(DCHs) via the DRNC, the SRNC may decide to perform a channel switch from DCH to FACH (e.g. if the UE has only a best effort packet data RAB and the traffic activity is low). In this case the SRNC may: a) select the target cell for the UE when switching to

FACH; or b) force the UE to perform a cell update (in this case the target cell is selected by the UE) before switching to FACH. The SRNC indicates in RRC signalling to the

UE whether the UE shall use a cell selected by the SRNC (alternative a) or perform a cell update (alternative b). In alternative a, the SRNC will perform the RNSAP Common Transport Channel Resource Initiation procedure without first having received a cell update from the UE via the DRNC. In alternative b, the RNSAP Common

Transport Channel Resource Initialisation procedure follows a cell update.

Claims

1. In a UMTS radio access network, a method of informing a serving RNC, SRNC, of the FACH transport channel configuration allocated by a drift RNC, DRNC, to user equipment, UE, the method comprising: including in a RNSAP message sent from the DRNC to the SRNC, an information element indicating whether FACH flow control information contained in the response is unique to the DRNC cell, or whether the information is common to all of the cells of the DRNC, wherein if said information element indicates that the information is common to all of the cells of the DRNC, the SRNC does not perform the RNSAP Common Transport Channel Resources Initialisation procedure, request/response sequence, for Cell Update messages subsequently received from the DRNC.

2. A method according to claim 1, wherein said RNSAP message is sent as part of a RNSAP Common Transport Channel Resources Initialisation procedure between the SRNC and the DRNC.

3. A method according to claim 2 and comprising performing the RNSAP procedure when the UE first moves into a cell of the DRNC and following the forwarding of an RRC Cell Update message from the DRNC to the SRNC using the RNSAP Uplink Signalling Transfer procedure, the procedure comprising sending a RNSAP Common Transport Channel Resource Request message from the SRNC to the DRNC, and sending a RNSAP Common Transport Channel Resource Response message from the DRNC to the SRNC, one of said Cell Update message and said response containing said information element.

4. A method according to claim 1, wherein said RNSAP procedure is carried out as part of a channel switch, from a DCH to a FACH.

5. A method according to claim 1, wherein said RNSAP procedure follows receipt of a cell update message from the UE at the SRNC.

6. A Radio Network Controller for use in a UTRAN and comprising processing means for implementing the method of any one of the preceding claims.