GB2443467A

GB2443467A - Utilising evolved HSPA technology with UMTS architecture to enable non-eHSPA user terminals access to network services

Info

Publication number: GB2443467A
Application number: GB0700221A
Authority: GB
Inventors: Tim Frost; David Fox; Gavin Wong
Original assignee: Vodafone Group PLC
Current assignee: Vodafone Group PLC
Priority date: 2006-11-03
Filing date: 2007-01-05
Publication date: 2008-05-07
Also published as: GB0621971D0; GB0700221D0

Abstract

A telecommunications network includes an evolved High Speed Packet Access (eHSPA) Node B 13 having a Node Controller, e.g. Controlling RNC (CRNC) 12, and a Serving Radio Network Controller (SRNC) 11 configured to communicate with a packet switched component 14 of a core network, but not with a circuit switched component 17. The telecommunications network further includes a UTRAN RNC 15 configured to communicate with the CRNC 12 and also to communicate with both the packet switched 14 and circuit switched 17 components of the core network. Communication is established between a given user terminal and the core network via the UTRAN RNC 15, when a given user terminal has at least a control plane connection with the eHSPA Node B 13, by tunnelling one or more communication set up messages over the control plane between the CRNC 12 and the core network via the UTRAN RNC 15, such that the UTRAN RNC 15 relays the messages, triggering or effecting SRNS Relocation over the Iub interface, tunnelling RRC messages over the Tub interface, and tunnelling the Initial Direct Transfer RRC message across the Iu-PS interfaces within SRNS Relocation messages.

Description

O UNITED KINGDOM PATENT APPLICATION

* APPLICANTS: VODAFONE GROUP PLC FORMAL TITLE: IMPROVEMENTS IN AN EHSPA ARCHITECTURE

IMPROVEMENTS IN AN EHSPA ARCHITECTURE

This invention relates to a system and method for use in a telecommunications * network employing High Speed Packet Access (HSPA) technology. More particularly, the invention relates to an evolved HSPA (eHSPA) collapsed architecture for utilising HSPA technology and utilising it with the existing UMTS radio access network architecture.

Background

Since its introduction, third-generation (3G) UMTS cellular technology has provided the ability to deliver more voice channels and higher-bandwidths to user equipment/terminals (UEs) such as mobile handsets. However, there is a desire for higher speed data.

In this regard High-Speed Packet Access (HSPA) was developed. HSPA is a protocol that provides a transitional platform for UMTS-based 3G networks to offer higher data transfer speeds, and so bridges the gap between 3G networks and the Internet. HSPA is made up of High Speed Downlink Packet Access (HSDPA) and High Speed Uplink Packet Access (HSUPA).

HSDPA provides impressive enhancements over WCDMA, including higher throughputs, and faster response times, particularly for web-browsing. More importantly, HSDPA offers three-to five-fold throughput increase, which translates into either much higher throughputs or significantly more data users on a single. frequency or carrier. The substantial increase in data rate and throughput is achieved by implementing a fast and complex channel control mechanism based upon short physical layer frames, Adaptive Modulation and Coding (AMC), fast Hybrid-ARQ (Automatic Repeat-reQuest) and fast scheduling. The exact implementation of HSDPA is known, and so will not be described further here.

HSPA can be implemented as an upgrade to and in co-existence with deployed * UMTSIWCDMA networks. The cost of deploying HSPA chiefly lies in base station and Radio Network Controller (RNC) software/hardware upgrades.

Most base stations (also known as Node Bs) will need upgrades to cope with the increased data throughput and the consequences of moving to a more complex protocol.

Advancements have also been made to HSPA, and the improved version has been termed evolved HSPA (eHSPA). In this regard, an evolved HSPA Node B architecture 10 has been proposed, which is shown in Figure 1. In addition to the standard Node B functionality 13, these nodes have the addition of RNC functionality (which, when in use, will provide the roles of serving RNC (SRNC) 11 and controlling RNC (CRNC) 12). The RNC functionality is provided alongside the Node B functionality within the base station/evolved Node B 10. Thus this eHSPA architecture can be described as "a collapsed RNCINode B" architecture. With this architecture the call set up delay can be reduced, as there is minimal latency associated with the communications between the RNC functionality 11, 12 and the Node B functionality 13. This eHSPA "collapsed RNC/Node B" architecture enables user terminals to connect to the eHSPA Node B without requiring any modifications.

It is to be appreciated that the evolved HSPA Node B architecture of Figure 1 has been designed so as to handle packet switched data communications more efficiently. In this regard, the SRNC 11 within the evolved HSPA Node B 10 is able to communicate directly with the Packet Switched (PS) Component of the Core Network. More specifically, the evolved HSPA Node B communicates directly with the GPRS Service Node (GSN) 14 via the lu-PS interface. The GSN 14 is made up of the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN) which connects to packet data networks such as the Internet.

While this evolved HSPA Node B is able to provide improved data rates through its architecture and use of HSPA, it is also imperative that the architecture is compatible with systems handling circuit switched (CS) voice communications. From an operator point of view, in order to maximise radio spectrum efficiency, it is also important that CS calls can be handled on the same cells as HSPA traffic. The same applies to PS calls using 3GPP Release 99 channels.

In this regard, the evolved HSPA Node B can be connected to the Core Network via legacy UTRAN. With reference to Figure 1 the Node B functionality 13 within the evolved HSPA Node B would communicate with the RNC 15 of the UTRAN network via interface lub. The RNC 15 in turn communicates with the Mobile Switching Centre (MSC) 17 of the CS component of the core network.

One difficulty with this approach, however, arises with the multi-RAB (Radio Access Bearer) scenario. More specifically, if a user terminal already has a PS connection with the GSN via the eHSPA Node B, and a CS connection is additionally required, then, since the SRNC of the evolved Node cannot provide a CS connection, SRNS relocation is required, at least in the control plane, to a legacy RNC before a circuit switched connection can be fully established.

This is not a straightforward matter, however, in view of the architectural difference of the evolved HSPA Node B to standard Node Bs.

A further requirement of the Figure 1 architecture is that legacy terminals are able to obtain a full service from the evolved Node B, such that they can gain access to packet switched data networks as well as circuit switched data networks. The difficulty here is that in order for legacy terminals (such as ATM-compatible terminals), which are not compatible with HSPA, to access data networks via the evolved HSPA Node B, the RNC 11 within the evolved HSPA Node B would need to support the legacy protocols, in addition to HSPA. This would be extremely burdensome, and so it is again preferable for data communications for such legacy terminals to be routed to the PS * component of the Core Network 14 via the UTRAN RNC 15. A difficulty with this is that the evolved Node B is not able to determine that the terminal with which it is communicating is a legacy terminal nor is it able to determine the service required by the terminal until after a Radio Resource Control (RRC) connection has been set up with the terminal. Therefore, upon receiving an RRC Connection Request from such a terminal, the evolved Node B commences setting up the connection, and establishing its internal RNC as the SRNC. Accordingly, once the shortcomings of the user terminal are determined, it becomes necessary to transfer the requested communication to the legacy UTRAN. Again, this is not a straightforward matter in view of the architectural differences between the evolved Node B and standard Node Bs.

Summary of the Invention

According to a first aspect the present invention provides, in a telecommunications network, including a base station node having a node controller component and a first radio network controller (RNC) component, the first radio network controller component configured to communicate with a packet switched component of a core network, but not with a circuit switched (CS) component, the telecommunications network further including a second RNC configured to communicate with the node controller and also to communicate with the packet switched component of the core network and the circuit switched component; a method of establishing a communication between a given user terminal and the core network via the second RNC, when a given user terminal has at least a control plane connection with the base station node, such that the first RNC is the serving RNC (SRNC), the method comprising: transmitting at least one message over the control plane between the node controller and the core network via the second RNC, such that the * message is tunnelled between the node controller and the second RNC.

According to a second aspect, the present invention provides a base station node having a node controller component and a first radio network controller (RNC) component, the first radio network controller configured to communicate with a packet switched component of a core network using HSPA, but not with a circuit switched component, the node controller further configured to transmit at least one communication set up message over the control plane between the node controller and the core network via a second RNC, such that the at least one message relates to a first protocol and the base station node is configured to encapsulate the message in a control plane container according to a second protocol.

According to a third aspect, the present invention provides in a telecommunications network, including a base station node having a node controller component and a first radio network controller (RNC) component, the first radio network controller configured to communicate with a packet switched component of a core network, but not with a circuit switched component, the telecommunications network further including a second RNC configured to communicate with the node controller and also to communicate with the packet switched component of the core network and the circuit switched component; a method of initiating SRNS relocation from the first RNC to the second RNC, when a given user terminal has at least a control plane connection with the base station node, such that the first RNC is the serving RNC (SRNC), the method comprising: transmitting an SRNS relocation message as well as the SRNS context, in the case where the terminal does not already have an existing Packet switched connection, from the node controller to the second RNC across the lub interface.

Preferably, an SRNS context is transmitted with the SRNS relocation message.

This is necessary where the user terminal does not already have an existing packet switched connection.

* These aspects of the invention therefore enable the integration of evolved HSPA Node Bs into legacy UTRAN networks. They also provide improved and more efficient arrangements for user terminals to make use of the benefits of eHSPA Node Bs whilst still being able to access network services which are not compatible with such Node Bs.

Brief Description of the Figures

Figure 1 illustrates an evolved Node B connected to a legacy UTRAN, an architecture in which the present invention can be implemented.

Figure 2 illustrates a signalling diagram of a user terminal establishing a CS connection via the eHSPA Node B, from idle, or when a PS connection already exists, according to a first embodiment of the invention; Figure 3 illustrates an example of a signalling diagram for an SRNS Relocation; Figure 4 illustrates a signalling diagram of a user terminal establishing a CS connection via the eHSPA Node B, from idle, or when a PS connection already exists, according to a further embodiment of the invention; and Figure 5 illustrates a signalling diagram of a user terminal establishing a CS connection via the eHSPA Node B, from idle, or optionally when a PS connection already exists, according to a still further embodiment of the invention.

Detailed Description of Embodiments of the Invention A first embodiment of the invention will now be described in relation to a user terminal, seeking a connection to a circuit switched component of a core network via the evolved node B 10. This embodiment will be described in relation to the user terminal seeking a connection from idle, although it is also I applicable to the situation of the user terminal already having a PS connection.

With reference to Figure 2, showing an example of an appropriate signalling diagram, the user terminal (UE) initiates communication by sending a "Radio Resource Control (RRC) Connection Request" 20 to the nearest Node B, which in this instance is the eHSPA Node B 10. Upon receiving this request, the Node B, at this point in the communication being generally unable to determine whether the user terminal requires access to the circuit switched component or the packet switched component of the core network, particularly where the terminal is a legacy terminal, proceeds with registering its internal RNC 11 as the serving RNC (SRNC).

Once the RRC connection has been set up, the Node B notifies the user terminal via an "RRC Connection Setup" message 21. The user terminal acknowledges this with an "RRC connection complete" message 22. Next the user terminal sends an "Initial Direct Transfer" message 23 to the evolved HSPA Node B 10. This message includes a service request, and so it is from this message that the evolved HSPA Node B can now determine whether the legacy terminal requires a circuit switched connection to the core network or a packet switched connection. In this instance, the terminal requires a circuit switched connection, with which the Node B's internal RNC is not compatible.

From here, once the eHSPA Node B has received the "Initial Direct Transfer" message 23, it is clear that the eHSPA Node B's internal SRNC II cannot be used to communicate directly with the CS Core Network. This is a consequence of the architecture of the evolved HSPA Node B, which has the internal SRNC 11 only in direct communication with the PS component 14 of the Core Network.

Therefore, according to this embodiment of the invention, the SRNC * functionality 11 of eHSPA Node B 10 must communicate with the CS core network via the legacy UTRAN RNC 15 in order to establish the CS call. The eHSPA node achieves this by communicating RANAP messages 24, 25 to the MSC of the CS Core Network 12, which are tunnelled via the lub interface using a container (from here on called "direct information transfer" container), between eHSPA Node B 10 and UTRAN RNC 15.

In Figure 2, no specific detail of the actual RANAP messages sent in the "Direct Information Transfer" container messages has been given, as their actual content and order is not important to this embodiment of the invention. It is enough merely to appreciate that the messages communicated between the evolved HSPA Node B and the MSC of the CS Core network are for the purpose of call set up and would typically include the initial UE message, as well as security mode commands.

As the initial message 24 from the evolved HSPA Node B is intended for communication to the CS component 17 of the Core Network, the message needs to be a RANAP message, since this is the protocol that the Core Network is expecting to receive. RANAP is the signalling protocol carried over the lu interface between the Core Network and the UTRAN.

Therefore, according to the present embodiment of the invention, the Node B encapsulates this RANAP message into a "Direct Information Transfer" container, which is an NBAP container, for transmission over the lub interface towards the UTRAN RNC 15. NBAP is a standard protocol for the lub interface for control communications between an RNC and a Node B. The UTRAN RNC 15 is the RNC to which the SRNC functionality is to be reallocated.

At this stage in the procedure the UTRAN RNC is not directly involved in the communications between the CS component of the Core Network (i.e. the MSC), and the Node B, and so, upon receiving the NBAP "Direct Information Transfer" container, the RNC merely unpacks the RANAP message 25 and transmits it to the MSC 17 of the CS core network using an SCCP connection.

SCCP is the routing protocol of the Transport layer of the lu interface control plane, and serves to route messages to a specified destination address.

From this it is apparent that the RNC has no involvement in acting on the details of the RANAP message at this stage -it merely acts as a concliit for the message towards the Core Network. It is also to be appreciated that the core network need not be aware that it is communicating with the evolved Node B, rather than an SRNC.

Upon receiving the "Direct Information Transfer" message from the evolved Node B, the Core Network responds, such as with a "Common ID" RANAP message (not shown). In the downlink direction, the opposite of what has just been described occurs. That is, the Core Network transmits the RANAP message towards the UTRAN RNC. The RNC packs the RANAP message into an NBAP "Direct Information Transfer" container and relays the message to the evolved Node B, which reads the message and acts accordingly. In this instance, the message is intended for the user terminal, and so the Node B would forward the message to the user terminal for it to provide the requested authentication.

A further RANAP message that would subsequently be transmitted by the Core Network, once the initial RANAP message has been received, is the "RAB Assignment Request" message, to establish the Radio Access Bearer (RAB) for the communication. This RANAP message would again be transmitted to the * UTRAN RNC.

In this embodiment of the invention, upon receiving the "RAB Assignment Request" message, the UTRAN RNC stores a copy of the request, encapsulates the message in a NBAP "Direct Information Transfer" container and forwards it on to the Node B over the lub interface. Upon receiving the "RAB Assignment Request", the Node B sets up the Radio Link configuration, and then responds with a "RAB Assignment Response" RANAP message, which is again encapsulated in a "Direct Information Transfer" container and transmitted towards the UTRAN RNC over the lub interface. The Node B then commences performing the SRNS Relocation 26 towards the UTRAN RNC. In this embodiment of the invention, when the UTRAN RNC receives the "RAB Assignment Response" message, it buffers the message and waits for the SRNS Relocation to be triggered by the Node B and for the SRNS context to be subsequently received.

An example of an applicable SRNS Relocation procedure, where no connection to the core network current exists, is shown in Figure 3, commencing below the dotted line 30. (The procedure above the dotted line 30 relates to the procedure for moving an lu-PS connection from an enhanced Node B's SRNC to a legacy RNC, where an lu-PS connection already exists.) The procedure below the dotted line in Figure 3 is mainly performed by the UTRAN RNC, and its functionality is as detailed in UTRAN 3GPP Release 7 specifications, from the stage when the UTRAN RNC receives the message "Relocation Commit" triggering SRNS Relocation if there is no existing core network connection. According to the present embodiment of the invention, instead of this message being forwarded between legacy RNCs over the lur interface using the RNSAP protocol, an equivalent message 31 is forwarded by the evolved Node B to the UTRAN RNC over the lub interface using the NBAP protocol. In addition, the full SRNS context may be transmitted across the lub interface within this message. Particularly this is needed if there is no existing core network connection. If there is an existing PS core network connection, then the message may be used to inform the UTRAN RNC that it may consider itself the new Serving RNC once the SRNS context has been transferred over the lu-PS interfaces.

Once SRNS Relocation has been triggered by the eHSPA node, subsequent steps below the dotted line 30 in Figure 3 are standard steps currently used in the UTRAN SRNS Relocation procedure and will not be described further here.

After the SRNS Relocation is successfully completed, the UTRAN RNC becomes the SRNC and from that point stops relaying RANAP messages to the eHSPA node B, and starts to function as the SRNC for the user. The eHSPA Node B also again starts to function as a normal Node B. It is to be appreciated, however, that in this embodiment, the user plane resources have not yet been fully allocated to the new SRNC, since the eHSPA Node B did not have the lub user plane resources established towards it before performing the SRNC Relocation.

Therefore, again referring to Figure 2, once SRNS Relocation 26 has been effected, and the UTRAN RNC has become the SRNC, it establishes the lub user plane towards the Node B, then sends the user terminal the "RRC: RB setup" message 27. The user terminal replies to with a "RRC: RB setup response" message 28.

Once SRNS Relocation has been completed, the new SRNC also commences communicating with the MSC of the circuit switched component of the Core Network, by forwarding the "RAB assignment response" message 29, that it had previously received from the Node B and buffered. In this regard, in this embodiment of the invention, the RAB assignment response is only forwarded to the MSC once the allocation of radio resources had been completed.

Once the MSC receives the RAB assignment response, the MSC begins to establish the link to the called party, by transmitting the Initial Address Message (1AM) 29. The JAM is the first message sent to inform the partner switch that a connection is to be established. The lAM contains the called and calling number and an indication of the type of service (i.e. speech or data).

It is to be appreciated that this arrangement is likely to take slightly longer than a normal RAB establishment -due to the SRNS Relocation being involved.

Therefore, it may be necessary to configure the MSC to wait a longer period of time to receive the RAB Assignment Response message 28.

Nevertheless, overall, on a per message basis, this embodiment of the invention will generally allow CS call setup messages to be passed quickly through the UTRAN, particularly since the CS messages also get the benefit of Radio Resource Control (RRC) and Radio Link Control (RLC) occurring within the Evolved Node B. In a further embodiment of the invention, the procedure is as per the embodiment just described, however a variation relates to the UTRAN RNC' s treatment of the "RAB Assignment Request" message received from the CS Core Network. In the Figure 2 embodiment, the UTRAN RNC stores a copy of the RAB Assignment Request message before forwarding it onto the evolved Node B. In this further embodiment of the invention, however, rather than storing this message and forwarding it on, the UTRAN RNC instead rejects the message with cause "Relocation triggered", which is transmitted back to the Core Network. The UTRAN RNC also notifies the eHSPA Node B of this via the lub interface. SRNS Relocation then occurs, as described in relation to the embodiment above, but with the RAB Assignment yet to occur. It is then the * responsibility of the Core Network to attempt the RAB Assignment again once the SRNS Relocation has been successfully completed.

A still further embodiment of the invention is shown in relation to Figure 4, where the CS call lub radio link is established before SRNS Relocation occurs.

As with the Figure 2 embodiment of the invention, the user terminal (UE) initiates communication from idle, by sending a "Radio Resource Request (RRC) Connection Request" 20 to the nearest Node B, which in this instance is the eHSPA Node B 10. Upon receiving this request, the Node B proceeds with registering its internal RNC 11 as the serving RNC, since at this point in the communication it is unable to determine whether the user terminal requires access to the circuit switched component or the packet switched component of the core network.

Once the RRC connection has been set up, it notifies the user terminal via an "RRC Connection Setup" message 21. The user terminal acknowledges this with an "RRC connection complete" message 22. Next the user terminal, either connecting from idle or already having a PS connection established, sends an "Initial Direct Transfer" message 23 to the Node B 10. It is from this message that the Node B can now determine the type of communication required by the user terminal: that is whether the terminal requires a circuit switched connection to the core network or a packet switched connection. In this embodiment, the terminal requires a circuit switched connection, to which the Node B's inbuilt RNC is not compatible. Therefore, an SRNS Relocation needs to occur to a more appropriate RNC so that the required CS connection can be established.

Communications to effect a CS connection normally occur between the SRNC and the CS component 17 of the Core Network over the Lu interface using RANAP. This is not possible in the present instance, since the SRNC 11 is only in direct communication with the PS component 14 of the Core Network.

Therefore, according to this embodiment of the invention, the Node B * functionality 13 of evolved Node B 10 takes the responsibility for communicating the Direct Information Transfer messages 24, 25 required to set up the CS core network connection.

In Figure 4, no specific detail of the Direct Information Transfer messages 24, has been given, as their actual content is not important to this embodiment of the invention. It is enough to merely appreciate that the messages communicated between the evolved Node B and the MSC of the CS Core network at this stage of the call set "p would typically include the initial RANAP call setup message as well as security mode commands.

The first of the RANAP messages to be transferred is typically the "Initial UE" message from the evolved Node B to the CS component 17 of the Core Network.

Therefore, according the present embodiment of the invention, the Node B encapsulates this RANAP message into an NBAP "Direct Information Transfer" container for transmission over the lub interface towards the UTRAN RNC 15. The UTRAN RNC is the RNC to which the SRNC functionality is to be reallocated.

As was the case for the Figure 2 implementation, at this stage in the procedure the UTRAN RNC is not directly involved in the communications between the CS component of the Core Network (i.e. the MSC), and the Node B, and so, upon receiving the "Direct Information Transfer" container, the RNC merely unpacks the RANAP message, and transmits it to the MSC 17 of the CS core network using an SCCP connection. In other words, the RNC has no involvement in the processing of the RANAP message at this stage -it merely acts as a conduit for the message towards the Core Network.

Upon handling the initial RANAP call set up message transfer, the Core Network will eventually send the "RAB Assignment Request" message, to establish the Radio Access Bearer (RAB) for the communication. This RANAP message would again be transmitted to the UTRAN RNC across the lu-CS interface. In this embodiment of the invention, upon receiving this message, the UTRAN RNC encapsulates the message in a NBAP "Direct Information Transfer" container before relaying it on to the Node B over the lub interface.

Upon receiving the "RAB Assignment Request", the Node B performs admission control and sets up the Radio Link configuration in the eHSPA Node B, and then responds with a "RAB Assignment Response" RANAP message.

which is transmitted towards the UTRAN RNC over the lub interface, again in an NBAP "Direct Information Transfer" container. When the UTRAN RNC receives the "RAB assignment Response" RANAP message, it unpacks the message and relays it to the MSC of the CS Core Network. The MSC responds by sending an "Initial Address Message" (1AM) 29, to inform the partner switch that a connection is to be established between the user terminal and the called party.

At this stage, the Node B's RNC is still the SRNC, and so SRNS Relocation still needs to occur before the CS connection between the user terminal and the called party can be fully established. Therefore, after sending the RAB Assignment Response message towards the UTRAN RNC, the eHSPA Node B triggers the SRNS Relocation by forwarding the "Relocation Commit" message to the UTRAN RNC in NBAP across the lub interface. Alternatively, in the situation of a PS connection already existing, it may perform the SRNS Relocation via the SGSN, and then send the Relocation Commit message to inform the UTRAN RNC that it shall consider itself the new Serving RNC.

As per the Figure 2 embodiment, an example of an applicable SRNS Relocation procedure, where no connection to the core network current exists, is shown in Figure 3, commencing below the dotted line 30. (The procedure above the dotted line 30 relates to the procedure for moving an lu-PS connection from an enhanced Node B's SRNC to a legacy RNC, where an lu-PS connection already exists.) The procedure below the dotted line inFigure 3 is mainly performed by the UTRAN RNC, and its functionality is as detailed in UTRAN 3GPP Release 7 specifications, from the stage when the UTRAN RNC receives the message "Relocation Commit" triggering SRNS Relocation if there is no existing core network connection. According to the present embodiment of the invention, nctir1 rf ihw hpino fnrunrded hetween lev RNCc nvpr th Iiir .----.t, .. -.-----.--.-.. --S --interface using the RNSAP protocol, an equivalent message 31 is forwarded by the evolved Node B to the UTRAN RNC over the lub interface using the NBAP protocol. In addition, the full SRNS context including the radio bearer or signalling radio bearer (on which to transmit the RRC signalling) information intended to be used by the UTRAN RNC may be transmitted across the lub interface within this message. Particularly this is needed if there is no existing core network connection, If there is an existing PS core network connection, then the message may be used to inform the UTRAN RNC that it may consider itself the new Serving RNC once the SRNS context has been transferred over the lu-PS interfaces. Although not shown in figure 3, in both cases there may also be a preparation phase on which to prepare the UTRAN RNC for the pending SRNS Relocation, which may involve interaction where the node controller is required to inform the terminal of the configuration to be used following the SRNS Relocation. There may also be some additional signalling between UTRAN RNC and node controller to allow the UTRAN RNC to inform the node controller whether the requested actions related to the SRNS Relocation can be carried out. In addition, such interaction may involve the UTRAN RNC tunnelling an RRC message to the node controller to allow it to inform the user terminal of the radio bearer configuration that shall be used * following the SRNS Relocation.

Once SRNS Relocation has been triggered by the eHSPA node in this way, I subsequent steps below the dotted line 30 in Figure 3 are standard steps currently used in the UTRAN SRNS Relocation procedure and will not be described further here.

Therefore, again referring to Figure 4, once SRNS Relocation 26 has been effected, and the UTRAN RNC has become the SRNC, it establishes the lub user plane towards the Node B, then sends the user terminal the "RRC: RB setup" message 27. The user terminal replies to with a "RRC: RB setup response" message 28.

In figure 3 it does not show the lub resources being setup to be able to transmit the RRC messages following the SRNS Relocation. However this would be needed to be done prior to the UTRAN RNC sending the UTRAN Mobility Information to the UE.] A benefit of this solution is that there is less additional delay to the call set up, because configuration of the radio link and admission control are performed before SRNS Relocation, allowing the called party's connection to be * established concurrently with the SRNS Relocation. In other words, the set up delay is reduced, due to an overlap in the set up procedures, rather than waiting for the SRNS relation to occur before finalising the communication link to the called party, as occurs in the Figure 2 embodiment of the invention.

A further embodiment of the invention relates to a variation of the embodiment just described. In this further embodiment, the CS call radio link is again established before SRNS Relocation occurs, and the user terminal (UE) initiates communication from idle. Therefore, the communications 20, 21, 22, 23 between the UE and the evolved Node B occur as per Figure 4 and the previously described embodiment, and the Node B proceeds with registering its internal RNC 1 1 as the serving RNC.

Once the Node B receives the "Initial Direct Transfer" message 23 from the user terminal (either connecting from idle or already having a PS connection), the Node B is then able to determine whether the terminal requires a circuit switched connection to the core network or a packet switched connection. In this embodiment, the terminal requires a circuit switched connection, with which the Node B's inbuilt RNC is not compatible. Therefore, an SRNS Relocation needs to occur to a more appropriate RNC so that the required CS connection can be established.

Hence, the Node B functionality 13 of evolved Node B 10 takes the responsibility for communicating the initial RANAP messages 24 to the CS component 17 of the Core Network.

As per the previous embodiment of the invention, the Node B encapsulates this RANAP message into an NBAP "Direct Information Transfer" container for transmission over the lub interface towards the UTRAN RNC 15. The UTRAN RNC is the RNC to which the SRNC functionality is to be reallocated.

At this stage in the procedure the UTRAN RNC is not directly involved in the communications between the CS component of the Core Network (i.e. the MSC), and the Node B, and so, upon receiving the "Direct Information Transfer" container, the RNC merely unpacks the RANAP message, and transmits it to the MSC 17 of the CS core network using an SCCP connection.

Upon receiving the initial RANAP message, the Core Network responds.

The UTRAN RNC will relay all RANAP messages between the Core Network and the evolved Node B in this way, until the Core Network sends the "RAB Assignment Request" message, to establish the Radio Access Bearer (RAB) for the conimunication. In this embodiment of the invention, upon receiving the RAR Achynmpnt reniit me.ssiap the IJTRAN RNC cicts s the RNC nd sets -----.---.----.-, ----------.----. -about establishing the radio link configuration towards the Node B using NBAP.

At this stage, the Node B's RNC is still the SRNC, and so SRNS Relocation still needs to occur before the CS connection between the user terminal and the called party can be fully established. Therefore, after sending the Radio Link Setup/Reconfiguration Response message towards the UTRAN RNC, the eHSPA Node B triggers the SRNS Relocation by forwarding the "Relocation Commit" message to the UTRAN RNC in NBAP across the lub interface.

The evolved Node B triggers relocation in this way in view of the behaviour of the UTRAN RNC in establishing the user plane resources towards the Node B. That is the Node B recognises that the UTRAN RNC is performing some of the functions of the SRNC, and so then performs an SRNS relocation so that the UTRAN RNC is able to perform fully as the SRNC.

Once SRNS Relocation has been triggered by the eHSPA node, subsequent steps proceed as per those illustrated below the dotted line 30 in Figure 3, which are standard steps currently used in the UTRAN SRNS Relocation.

* Once the admission control has been successfully completed and the SRNS Relocation has been completed towards the UTRAN RNC, the evolved Node B notifies the UTRAN of such, and the UTRAN RNC then transmits the "RAB Assignment Response" RANAP message to the Core network. The MSC responds by sending an "Initial Address Message" (1AM) 29, to inform the partner switch that a connection is to be established between the user terminal and the called party.

A still further embodiment of the invention will now be described in relation to Figure 5. In this embodiment, the user terminal (UE) requests a CS connection from idle. The user terminal first sends a "Radio Resource Request (RRC) Connection Request" 20 to the eHSPA Node B 10. The Node B notifies the user terminal that the connection is set up via an "RRC Connection Setup" message 21. The user terminal acknowledges this with an "RRC connection complete" message 22. Next the user terminal sends an "Initial Direct Transfer" message 23 to the Node B 10. It is from this message that the Node B determines the type of connection required by the terminal (either connecting from idle or already having a PS connection). In this embodiment, in addition to its existing PS connection, the terminal requires a circuit switched connection, with which the Node B's internal RNC is not compatible.

Therefore, an SRNS Relocation needs to occur to a more appropriate RNC before the user terminal can communicate via its requested CS connection.

According to this embodiment of the invention, the Node B functionality 13 of evolved Node B 10 takes the responsibility for triggering access to the CS domain, as well as triggering SRNS relocation from its internal RNC to the UTRAN RNC. In this regard, the evolved Node B tunnels the Initial Direct Transfer message (triggering access to the CS domain) within an NBAP message (which in the figure is the "Relocation Commit" message 54 -(used during SRNS relocation and potentially carrying the SRNS context)) through to the UTRAN RNC. In this regard, the Initial Direct Transfer message is encapsulated in the lub control signalling (NBAP) and tunnelled through to the UTRAN RNC.

Once received, the RNC buffers the "Initial Direct Transfer" message until the SRNS relocation has been effected. Further, in response to the SRNS Relocation Commit message, the UTRAN RNC (with an existing PS connection effects the SRNS Relocation by first sending a "Relocation Detect" message 55 to the SGSN of the PS component of the core network, and) then sends a "UTRAN Mobility Information" request message 56 to the UE The UE replies with a "UTRAN Mobility Information Confirmation" message 57, (and the UTRAN RNC with an existing PS connection in turn notifies the SGSN of such with a "Relocation Complete" message 58).

With SRNS Relocation completed, the UTRAN RNC, now the SRNC, forwards the "Initial Direct Transfer" message 59, previously buffered, to the MSC to set up the CS connection. The MSC replies with a "RAB Assignment Request" 60. The RNC then forwards a "Radio Link Setup" message 61 to the eHSPA Node B over the lub interface. Since SRNS Relocation has occurred, the eHSPA Node B acts as a normal Node B and sets up the Radio Link before transmitting a "Radio Link Setup Response" 62 to the RNC once the link has been set up. The RNC then notifies the UE that the Radio Bearer has been set up, via the "RRC: RB Setup" message 63. The UE responds with a "RRC: RB Setup Response" message 64. The RNC then confirms the RAB Assignment with the MSC 65, so that the call connection with Party B can be effected.

This embodiment of the invention therefore uses the UTRAN RNC to effect * SRNS Relocation before the CS Core Network is notified of the CS Connection Request.

The embodiments of the invention so far described, relate different procedures for setting up a CS call for a user terminal from idle or when already PS connected, be it a legacy terminal or otherwise. The inventive concept can similarly be applied to the situation of a legacy terminal that is not HSPA compatible, such as a Release 99 (or earlier) compatible terminal, requesting a PS call set up. In this regard, since the legacy terminal is not HSPA compatible, the PS connection cannot be established via the eHSPA' s internal RNC, but must be via a UTRAN RNC.

The embodiments of the invention so far described may also be applied to the situation of a user terminal requesting a CS connection, where a PS connection has already been established with the eHSPA Node B's inbuilt SRNC.

In this regard, where the user terminal has an existing PS connection to the core network, via the evolved Node B's internal SRNC 11, and the user terminal requests a CS connection. Since the SRNC of the evolved Node B cannot provide such a CS connection, and it is desirable to have the same SRNC to provide both the PS and the CS connection, it is necessary in this situation for the evolved Node B to initiate an SRNS transfer to a UTRAN RNC.

This SRNS Relocation procedure is shown in Figure 3. Above the dotted line the necessary steps to move the lu connection from the Node B's internal SRNC to the UTRAN SRNC are detailed. The eHSPA node first transmits a "Relocation Required" message 31 to the SGSN of the PS core network. This message can be transmitted to the SGSN via the Node B's SRNC since a PS connection with the SGSN has already been established. Alternatively, the message could be routed via the UTRAN SRNC.

* When the SGSN receives the "Relocation Required" message, the SGSN notifies the UTRAN RNC of the lu-PS Relocation requirement by sending it a "Relocation Request" message. Based upon this message, the UTRAN RNC sets about establishing its appropriate RABs. Once complete, it notifies the SGSN via the "Relocation Request Acknowledgement". The SGSN then sends a "Relocation Command" to the SRNC of the eHSPA Node to effect the lu-PS transfer from its own SRNC to the UTRAN SRNC.

Once the eHSPA Node B has arranged the relocation of the lu-PS connection with the core network to the UTRAN RNC, the SRNS Relocation needs to be effected from the Node B's internal SRNC to the UTRAN RNC. According to this further embodiment of the invention, the evolved Node B initiates this transfer by forwarding a "Relocation Commit" message 36 to the UTRAN RNC over the lur interface using NBAP.

Once SRNS Relocation has been triggered by the eHSPA node, the steps outlined below the dotted line in Figure 3 are performed. This stage of the procedure may also be used for a UE that does not have an existing PS connection. This procedure is mainly performed by the UTRAN RNC, and its functionality is as detailed in UTRAN 3GPP Release 7 specifications, once it receives the message "Relocation Commit" triggering SRNS Relocation, or informing the RNC that it may consider itself the new Serving RNC for the connection. According to the present embodiment of the invention, instead of this message being forwarded between RNCs over the lur interface using the RNSAP protocol, an equivalent message is forwarded by the evolved Node B to the UTRAN RNC over the lub interface using the NBAP protocol. This message may also contain the full SRNS context.

Once SRNS Relocation has been triggered by the eHSPA node, subsequent steps below the dotted line in Figure 3 are standard steps currently used in the UTRAN SRNS Relocation procedure and will not be described further here.

* Once the SRNC functionality has been transferred to the UTRAN RNC in this way, the eHSPA Node B begins to function as a standard Node B. It is to be appreciated that the embodiments of the invention just described are for illustrative purposes only and the exact procedures are not to be interpreted as limiting. For example, once the SRNS relocation procedure has been initiated, it is within the scope of the invention that other RANAP procedures, such as procedures initiated by the Core Network or the enhanced HSPA Node B itself, may require the SRNS relocation procedure to be terminated or delayed in order to allow the particular RANAP procedure to be undertaken.

Claims

1. In a telecommunications network, including a base station node having a node controller component and a first radio network controller (RNC) component, the first radio network controller component configured to communicate with a packet switched component of a core network, but not with a circuit switched (CS) component, the telecommunications network further including a second RNC configured to communicate with the node controller and also to communicate with the packet switched component of the core network and the circuit switched component; a method of establishing a communication between a given user terminal and the core network via the second RNC, when a given user terminal has at least a control plane connection with the base station node, such that the first RNC is the serving RNC (SRNC), the method comprising: transmitting at least one message over the control plane between the node controller and the core network via the second RNC, such that the message is tunnelled between the node controller and the second RNC.

2. The method of claim 1, wherein the second RNC relays the at least one message, by placing the message in a control plane container for transmission over the control plane interface to the node controller, and/or removing the message from a control plane container for transmission over the control plane interface to the core network.

3. The method of claim I, wherein the at least one message corresponds to a first protocol, and the message is tunnelled between the node controller and the second RNC in a control plane container corresponding to a second protocol.

4. The method of claim 3, wherein the first protocol is the Radio Access Network Application Protocol (RANAP) and the second protocol is the Node B Application Protocol (NBAP).

*

5. The method of any one preceding claim further including: tunnelling the at least one message in a control plane container between the node controller and the second RNC over the lub interface; and upon receiving the control plane container, the second RNC removing the message therefrom and relaying the message on the control plane of the lu interface to the core network.

6. The method of any one preceding claim further including: transmitting the at least one message from the core network to the second RNC over the lu interface; and the second RNC receiving the message from the lu interface and relaying the message in a control plane container over the lub interface to the node controller.

7. The method of any one preceding claim wherein the at least one message is tunnelled over the control plane once the node controller determines that the given user terminal requires access to the circuit switched component of the core network.

8. The method of any one of claims 1 to 6 wherein the at least one message is tunnelled over the control plane once the node controller determines that the given user terminal requires a type of call that cannot be setup directly from the base station node towards the packet switched component of the core network.

9. The method of claim 8 wherein the node controller determines that the given user terminal requires a packet switched connection using 3GPP Release 99 channels, where this is a type of connection that cannot be set up directly towards the packet switched core network from the base station node.

10. The method of claim 8 wherein the node controller determines that the given user terminal requires a circuit switched connection, which is a type of connection that cannot be set up directly from the base station node.

11. The method of any one of claims 1 to 6 wherein the at least one message is tunnelled over the control plane once the first node controller determines that the given user terminal with which it is communicating is not HSPA-compatible.

12. The method of any one preceding claim further including the node controller transmitting a relocation message to the second RNC,.

13. The method of claim 12 wherein the relocation message serves to trigger SRNS Relocation to the second RNC in the control plane.

14. The method of claim 12 or 13 wherein the relocation message serves to trigger SRNS Relocation to the second RNC in the user plane.

15. The method of claim 12, 13, or 14, where the relocation message contains the SRNS context of the user terminal.

16. The method of claim 12, wherein the relocation message to the second RNC serves to inform the second RNC that it should consider itself the new serving RNC.

17. The method of claim 12 wherein the message contains radio bearer configuration information to be used by the second RNC once it considers itself to be the serving RNC.

18. The method in claim 12 wherein the second RNC returns a message to the node controller to indicate that the actions requested in the received SRNS Relocation message could not be carried out.

19. The method in claim 12 wherein the second RNC returns a message to the node controller to indicate that the actions requested in the received SRNS Relocation message could not be earned out.

20. The method in claim 18 wherein the returned message from the second RNC tunnels an RRC message to be passed on to the user terminal from the node controller.

21. The method in claim 20 whereby the RRC message contains a radio bearer configuration to be used by the user terminal following the SRNS Relocation.

22. The method in claims 12, 18 and 19 wherein the SRNS Relocation message is transmitted using the NBAP protocol.

23. The method of any one preceding claim wherein the at least one message tunnelled includes a Radio Resource Control (RRC) "Initial Direct Transfer" message to the second RNC, which is terminated and read by the second RNC once it has become the new SRNS for the user connection.

24. The method of any one preceding claim wherein the at least one message tunnelled includes a Radio Access Bearer (RAB) Assignment Request message from the CS component of the Core Network to the node controller.

25. The method of claim 23 wherein the second RNC stores a copy of the RAB request message before tunnelling the message to the Node Controller; the node controller, upon receiving the RAB Assignment Request * message, configuring the requested RAB resources and tunnelling the RAB assignment response message towards the second RNC, the node controller also initiating SRNS Relocation toward the second RNC; upon receiving the tunnelled RAB assignment response message, the second RNC buffering the message, while SRNS Relocation is effected; and the second RNC forwarding the RAB assignment response message towards the core network upon being established as the SRNC.

26. The method of any one of claims 1 to 23, further including: the core network transmitting a RAB assignment request message towards the second RNC; the second RNC rejecting the RAB assignment request message and notifying the core network of such; the node controller initiating SRNS Relocation from the first RNC to the second RNC; when a timer expires in the Core network, and once SRNS relocation has been effected, the Core Network retransmitting a RAB assignment message towards the second RNC in order to initiate a RAB establishment.

27. The method of any one of claims I to 14, further including: the Core Network transmitting a RAB assignment request message towards the second RNC; the second RNC tunnelling the received RAB assignment request message to the node controller; upon receiving the RAB assignment request message, the node controller establishing a radio bearer configuration and tunnelling a message to the core network, via the second RNC, notifying it of such; the node controller subsequently effecting SRNS Relocation from the first RNC to the second RNC.

28. The method of any one of claims 1 to 23 further including: the core network transmitting a RAB assignment request message towards the second RNC; the second RNC, upon receiving the RAB assignment request message establishing a radio link configuration towards the base station node, and notifying the core network once the configuration has been established; and subsequently the node controller effecting SRNS Relocation from the first RNC to the second RNC.

29. The method of claim 27 or 28, wherein the core network takes steps to establish a connection between the given user terminal and a third party while SRNS Relocation is occurring.

30. The method of any one of claims 1 to 15, further including: the node controller tunnelling a domain access request (RRC: INITIAL DIRECT TRANSFER message) message within an SRNS Relocation request message towards the second RNC; the second RNC buffering the received domain access request message; the second RNC effecting the SRNS Relocation; upon completion of the SRNS relocation, the second RNC acting on the domain access request message, continuing the CS connection setup towards the MSC via RANAP.

31. The method of claim 30, where the user terminal already has an existing packet switched connection, and the domain access request message is tunnelled through RANAP, via the PS Core network to the second RNC, within the lu-PS SRNS Relocation messages.

32. The method of any one preceding claim, wherein the at least one message is a communication set up message.

33. In a telecommunications network, including a base station node having a * node controller component and a first radio network controller (RNC) component, the first radio network controller configured to communicate with a packet switched component of a core network, but not with a circuit switched component, the telecommunications network further including a second RNC configured to communicate with the node controller and also to communicate with the packet switched component of the core network and the circuit switched component; a method of initiating SRNS relocation from the first RNC to the second RNC, when a given user terminal has at least a control plane connection with the base station node, such that the first RNC is the serving RNC (SRNC), the method comprising: tiansmittirtg an SRNS relocticn message from the node controller to the second RNC across the lub interlace.

34. The method of claim 33 wherein the SRNS relocation message is intended to trigger SRNS relocation.

35. The method of claim 33 wherein the SRNS relocation message is intended to inform the second RNC that it should consider itself the serving RNC for the user connection.

36. The method in claim 33 wherein the SRNS Relocation message contains a radio bearer configuration intended to be used by the second RNC when it considers itself to be the serving RNC.

37. The method in claim 33 wherein the second RNC returns a message to the node controller to indicate that the actions requested in the received SRNS Relocation message could not be carried out.

38. The method in claim 33 wherein the second RNC returns a message to the node controller to indicate that the actions requested in the received SRNS Relocation message could not be carried out.

39. The method in claim 37 wherein the returned message from the second RNC tunnels an RRC message to be passed on to the user terminal from the node controller.

40. The method in claim 39 whereby the RRC message contains a radio bearer configuration to be used by the user terminal following the SRNS Relocation.

41. The method of claim 33, 39 and 40 ftirther comprising transmitting the relocation message using the NBAP protocol.

42. The method of claim 3, 33 or 41 further comprising the first protocol being Radio Resource Control (RRC) and the second protocol being NBAP, whereby the NBAP SRNS relocation message tunnels an RRC message.

43. The method of claim 33, 41 or 42 whereby the relocation message contains a full SRNS context.

44. A telecommunications system configured to implement the method of any one preceding claim.

45. A base station node having a node controller component and a first radio network controller (RNC) component, the first radio network controller configured to communicate with a packet switched component of a core network using HSPA, but not with a circuit switched component, the node controller further configured to transmit at least one communication set up message over the control plane between the node controller and the core network via a second RNC, such that the at least one message relates to a first protocol and the base station node is configured to encapsulate the message in a control plane container according to a second protocol.

46. The base station node of claim 45, wherein the node controller is configured to transmit at least one RANAP message and encapsulate the message in an NBAP container for transmission across the Lub interface towards the core network via the second RNC.