Method for multiplexing data streams onto a transport bearer between an originating network node and a receiving network node

Abstract

The area of the invention belongs to the transport technologies in UTRAN. This invention concerns a method for multiplexing a data stream onto a transport bearer between an originating network node and a receiving network node in a telecommunications network. This is done in order to ensure the effective usage of transport resources over the two interfaces, i.e. Iub/Iur. To accomplish this the RNC and/or Node B/RNC should check if the there already exists a transport bearer, which can be utilised for HS-DSCH transport over Iub/Iur interface. Because of this a transport bearer identification code or transport bearer id is needed to identify this bearer between RNC and Node B/RNC.

Description

FIELD OF THE INVENTION

[0002] The present invention relates to telecommunication systems. In particular, the present invention relates to a novel and improved method for multiplexing data streams onto a transport bearer between an originating network node and a receiving network node.

BACKGROUND OF THE INVENTION

[0003] In the current specifications of the third generation mobile networks (referred to as UMTS, Universal Mobile Telecommunication System), the system utilises the same well-known architecture that has been used by all main second generation systems. A block diagram of the system architecture of the current UMTS network is presented in FIG. 1. The UMTS network architecture includes the core network (CN), the UMTS terrestrial radio access network (UTRAN), and the user equipment (UE). The core network is further connected to the external networks, i.e. the Internet, PSTN (Public Switched Telephone Network) and/or ISDN (Integrated Digital Services Network).

[0004] The UTRAN architecture consists of several radio network subsystems (RNS). The RNS is further divided into the radio network controller (RNC) and several base stations (BTS, referred to as Node B in the 3GPP specifications). In this architecture there are several different connections between the network elements. The Iu interface connects CN to UTRAN. The Iur interface enables the exchange of signalling information and user plane information between two RNCs. There is no equivalent interface to Iur in the architectures of the second generation mobile networks. The radio network layer (RNL) signalling protocol across the Iur interface is called the radio network subsystem application part (RNSAP). The RNSAP is terminated at both ends of the Iur interface by an RNC. The Iub interface connects an RNC and a Node B. The Iub interface allows the RNC to indicate the required radio resources to the Node, for example, to add and delete cells controlled by Node B to support communication of dedicated connection between UE and C-RNC(Control RNC), information used to control the broadcast and paging channels, and information to be transported on the broadcast and paging channels. One Node B can serve one or multiple cells. UE is connected to Node B through the Uu radio interface. UE further consists of a subscriber identity module (USIM) and mobile equipment (ME). They are connected by the Cu interface. Connections to external networks are made through Gateway MSC (Mobile Services Switching centre) (towards circuit switched networks) or GGSN [Gateway GPRS (Group Packet Radio System) Support Node] (towards packet switched networks).

[0005] The general protocol model for UTRAN Interfaces is depicted in FIG. 2, and described in detail in the following. The structure described is based on the principle that the layers and planes are logically independent of each other.

[0006] The Protocol Structure consists of two main layers, Radio Network Layer and Transport Network Layer (TNL). These are presented in the horizontal planes of FIG. 2. All UTRAN related issues are visible only in the Radio Network Layer, and the Transport Network Layer represents the standard transport technology that is selected to be used for UTRAN. UTRAN has certain specific requirements for TNL. For instance, the real time requirement, i.e. the transmission delay has to be controlled and kept small.

[0007] In the HS-DSCH (HS-DSCH, High Speed Downlink Shared Channel; HSDPA High Speed Downlink Packet Access) specification work the basic assumption is that the same transport solution that has been used for DSCH will be used for HS-DSCH also. In this application the term HS-DSCH is used to describe the channel or data stream between CRNC and Node B on Iub interface and therefore it should not mixed up with the HSDPA related transport channel, which is an internal channel between MAC-hs (Medium Access Control) and L1 (Layer 1) in Node B. In this solution dedicated transport bearer is reserved separately for each DSCH data stream between SRNC (Serving RNC) and Node B. FIG. 3 shows the radio interface protocol architecture with termination points. In logical model MAC-hs, which is inserted in Node B, locates below MAC-c/sh, which further is implemented in CRNC. The HS-DSCH FP (frame protocol) will handle the data transport from SRNC to CRNC (if the Iur interface is involved) and between CRNC and the Node B. The architecture supports both FDD (Frequency Division Duplex) and TDD (Time Division Duplex) modes of operation, though in the case of TDD, some details of the associated signalling for HS-DSCH are different.

[0008] The basic structure of HS-DSCH is assumed to be based on two architectures: an RNC-based architecture consistent with Release '99 architecture and a Node B-based architecture for scheduling. Moving the scheduling to the Node B enables a more efficient implementation of scheduling by allowing the scheduler to work with the most recent channel information. The scheduler can adapt the modulation to better match the current channel conditions and fading environment. Moreover, the scheduler can exploit the multi-user diversity by scheduling only those users in constructive fades. Furthermore, the HSDPA proposal has the additional potential to improve on the RNC-based HARQ architecture in both UE memory requirements and transmission delay. The scheduler for the HS-DSCH is therefore located in the Node B, wherein the HS-DSCH refers to the transport channel, which locates between MAC-hs and L1 internally in Node B.

[0009] There is no identification IE in Iub/Iur FP (FP, Frame Protocol) to identify a certain UE. Therefore the dedicated transport bearers were needed to identify a particular UE to enable the efficient usage of power control function over the radio interface. This means that number of required transport bearers to be reserved between SRNC and Node B is the same as the number of DSCH data streams. One UE can have several data streams. To make the system work properly, capacity i.e. bandwidth for each transport bearer has to be reserved according the reserved DSCH capacity over the radio interface. E.g. if the DSCH capacity in the radio interface is 512 kbps and there are 10 data streams sharing the channel the maximum required transport capacity is 10 times 512 kbps over Iub interface to ensure the QoS. And as the scheduling is done by MAC-sh in CRNC only one transport bearer is used in certain time frame. As a result a lot of bandwidth is wasted. This increases the need of the bandwidth resources.

[0010] The invention is characterised by what is disclosed in the independent claims.

SUMMARY OF THE INVENTION

[0011] This invention concerns a method for multiplexing a data stream onto one transport bearer between an originating network node and a receiving network node in a telecommunications network. This is done in order to ensure the effective usage of transport resources over the two interfaces, i.e. Iub/Iur. To accomplish this the RNC and/or Node B/RNC should check if the there already exists a transport bearer, which can be utilised for HS-DSCH data stream over Iub/Iur interface. Because of this a transport bearer identification code or transport bearer id is needed to identify this bearer between RNC and Node B/RNC.

[0012] The scheduling to the radio interface for DSCH is done by MAC-sh function located in CRNC whereas in the HS-DSCH the scheduling, wherein the HS-DSCH refers to the transport channel, which locates between MAC-hs and L1 internally in Node, B, to the radio interface shall be done by MAC-hs, which is located in Node B. Therefore the identification of the transport bearer can be done by other means than using dedicated transport bearers between SRNC/CRNC and Node B. Enabling the multiplexing of HS-DSCH data streams to the same transport bearer the huge amount of transport resources can be saved.

[0013] Before sending any message to Node B/RNC to request a new transport bearer for HS-DSCH data stream RNC checks if there already exists a transport bearer between RNC and Node B/RNC, which can be used for this purpose. If there does not exist any transport bearer, identified by transport bearer id, that can be used to carry a new HS-DSCH data stream, RNC sends the request for a transport bearer for HS-DSCH data stream without transport bearer id to indicate to Node B/RNC that a new transport bearer is needed.

[0014] If the transport bearer that can be used exists, RNC includes the transport bearer id to the request message to indicate to Node B/RNC which existing transport bearer it likes to use for this new HS-DSCH data stream. If Node B/RNC accepts the request, no additional transport layer information shall be included to the response message. Otherwise Node B/RNC includes a new transport layer information to the reply message to indicate that the new transport bearer is needed.

[0015] There is also another possibility for Node B/RNC to decide the usage of the transport bearer. In this case RNC will send the HS-DSCH request/modification message to Node B/RNC without any further information. Then receiving Node B/RNC will decide whether it is to assign a new transport bearer or to use existing transport bearer. In case it decides to assign a new transport bearer, it will reply with new transport address and new transport bearer id. If it decides to use existing transport bearer it will reply with only the existing transport bearer id selected to be used as a shared transport bearer for the new HS-DSCH data stream by Node B/RNC, without new transport address.

[0016] In the present specification there is no Id that can be used as a transport bearer id to identify on the Radio Network Layer a certain already existing transport bearer out of a particular UE context between RNC and Node B. It is impossible to indicate to Node B/RNC by RNC that one of the existing transport bearers can be used to carry another data stream for different or for the same UE.

[0017] To enable the transport bearer selection functionality for HS-DSCH a new transport bearer id shall be introduced between RNC and Node B/RNC in NBAP/RNSAP messages. When a new transport bearer service instance is created, a transport bearer id is assigned to it by the RNL application. This transport bearer id needs to be unique at least per an interface, i.e. between the two UTRAN nodes terminating the corresponding RNL application protocol. The transport bearer ID is stored by both originating and receiving nodes (RNC, RNC/Node B) for the lifetime of the corresponding transport bearer service instance.

[0018] To ensure the uniqueness of the transport bearer id it could be allocated by either end point of the connection or it could be a combination so that each end allocates a certain part of the identifier:

[0019] In the present invention it is also assumed that the multiplexing of HS-DSCH data streams are provided above transport layer i.e. in FP/MAC layer.

[0020] The benefits of the invention can be summarised as follows: the available transport capacity (i.e., bandwidth) is better utilised due to the improved statistical sharing of the bandwidth. The number of transport bearers, e.g. AAL2 (ATM Adaptation Layer 2) connection is reduced as one bearer can be shared by several user streams. The frequency of transport bearer setups and tear-downs is significantly decreased as there is no need to have a dedicated bearer for each user stream.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are included to provide a further understanding of the invention and constitute a part of this specification, illustrate embodiments of the invention and together with the description help to explain the principles of the invention. In the drawings:

[0022] FIG. 1 is a block diagram illustrating an example of the state of the art scenario relating to the present mobile network;

[0023] FIG. 2 is a general protocol model for UTRAN interfaces of FIG. 1;

[0024] FIG. 3 describes a radio interface protocol architecture of HDSPA;

[0025] FIG. 4 is a signalling chart describing one embodiment of the present invention; and

[0026] FIG. 5 is a signalling chart describing another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0027] Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

[0028] In FIGS. 4 and 5 is disclosed five network elements. Two of these elements are named twice, i.e. Node B/DRNC and Node B/SRNC. This naming is done because these two figures are describing only two examples of the present invention and these same elements could represent also the other element in the labelling.

[0029] In FIG. 4 is disclosed a signalling chart describing an example case wherein Node B decides not to use an existing transport bearer resource. In FIG. 4 Serving Radio Network Controller SRNC decides to setup a HS-DSCH channel, item 1. After this decision it sends a Radio Network Subsystem Application Part (RNSAP,) message requesting Radio Link Setup, item 2. The parameter in this message is [Mux Indication IE]. This Mux Indication IE can have the following values: “may” or “shall not” in the request message. In case of “may”, receiver can decide whether it will multiplex or not. But in case of “shall not” receiver cannot use multiplex option. The message is sent to Drift Radio Network Controller DRNC.

[0030] After this Drift Radio Network Controller DRNC sends a Node B Application Part message (NBAP) requesting Radio Link Setup to Node B, item 3. The parameter also in this message is [Mux Indication IE]. Node B then checks if there is available transport bearer for a new Radio Link, item 4. In this case it detects that there exists no suitable transport bearer and a new transport bearer is needed. Then Node B sends a Radio Link Setup Response to DRNC to inform DRNC the parameters of the new transport bearers it has decided to establish. The parameters are [Transport Bearer Id IE, Binding ID IE, Transport Layer Address IE], item 5. Based on the information from Node B, DRNC decides to setup a new transport bearer, item 6. Finally DRNC sends a Radio Link Setup Response with parameters [Transport Bearer Id IE, Binding ID IE, Transport Layer Address IE] to SRNC.

[0031] In FIG. 5 is disclosed a signalling chart describing an example case wherein Node B decides to use an existing transport bearer resource. In FIG. 5 Serving Radio Network Controller SRNC decides to setup a HS-DSCH channel, item 1. After this decision it sends a Radio Network Subsystem Application Part (RNSAP,) message requesting Radio Link Setup, item 2. The message is sent to Drift Radio Network Controller DRNC. The parameter in this message is [Mux Indication IE]. This Mux Indication IE can have the following values: “may” or “shall not” in the request message. In case of “may”, receiver can decide whether it will multiplex or not. But in case of “shall not” receiver cannot use multiplex option. Drift Radio Network Controller DRNC sends a Node B Application Part message (NBAP) requesting Radio Link Setup to Node B, item 3. The parameter also in this message is [Mux Indication IE]. Node B then checks if there is available transport bearer for a new Radio Link, item 4. In this case it detects that there exists a suitable transport bearer and no new transport bearer is needed. Then Node B sends a Radio Link Setup Response to DRNC with parameter [Transport Bearer Id IE] informing the existing transport bearer that is to be used for this new data stream, item 5. Based on the information from Node B, DRNC decides not to setup a new transport bearer and instead of that uses an existing transport bearer that has been indicated with transport bearer id, item 6. Finally DRNC sends a Radio Link Setup Response with parameter [Transport Bearer Id IE] to SRNC. This is all what is needed because SRNC will use an existing transport bearer and it already has the necessary parameters for this bearer.

[0032] The allocating for the transport bearer identification code or transport bearer id can be done in three ways. An originating RNC allocates the transport bearer id when a new transport bearer for HS-DSCH is needed between RNC and RNC/Node B and includes the transport bearer id to the message requesting HS-DSCH establishment/modification. When receiving node (Node B or DRNC) gets the new transport bearer id it stores it (with other transport layer related information) and returns the transport bearer id back to the originating node with allocated transport layer information.

[0033] When receiving Node B/RNC gets a Radio Link Setup Request for a HS-DSCH channel from RNC without the transport bearer id, it allocates the id and includes it with the transport layer information to reply message and stores the transport bearer id with correct transport layer information.

[0034] In the third option both originating and receiving network node allocates a part of the transport bearer id. In this case RNC allocates the first part of the transport bearer id when a new transport bearer for HS-DSCH is needed between RNC and RNC/Node B and includes the part of the transport bearer id to the message requesting HS-DSCH establishment/modification. After receiving the first part of the transport bearer id the receiving node allocates the other part of the id and stores the whole transport bearer id (with other transport layer related information) and returns the transport bearer id back to originating node with allocated transport layer information.

[0035] The transport bearer id is stored in both nodes as long as the transport bearer it identifies exists.

[0036] It is obvious to a person skilled in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways and in various network environments The invention and its embodiments are thus not limited to the examples described above, instead they may vary within the scope of the claims.

Claims

1. A method for multiplexing a data stream onto a transport bearer between an originating network node and a receiving network node in a telecommunications network, the method comprising the steps of mapping a transport bearer resource for a data stream, characterised in that the method further comprises the following steps: checking if there is available transport bearer resources in the group of existing transport bearers, and if there exists a transport bearer resource that can be used for said data stream, reserving said existing transport bearer resource for said data stream, or requesting a new transport bearer resource, and reserving said new transport bearer resource for said data stream.

2. The method according to claim 1, characterised in that identifying said new transport bearer resource with a transport bearer identification code.

3. The method according to claim 2, characterised in that in said requesting step, indicating an existing transport bearer resource for said data stream by including said transport identification code in a request message.

4. The method according to claim 1, characterised in that in said requesting step, indicating a need for a new transport bearer resource by sending a request message in which no transport identification code is included.

5. The method according to claim 2, characterised in that in using a unique transport bearer identification code, said transport bearer identification code being unique at least between said originating network node and said receiving network node.

6. The method according to claim 2, characterised in that recording said transport bearer identification code at least for a lifetime of said transport bearer resource in both said originating network node and said receiving network node.

7. The method according to claim 2, characterised in that allocating said transport identification code in said originating network node.

8. The method according to claim 2, characterised in that allocating said transport identification code in said receiving network node.

9. The method according to claim 2, characterised in that allocating a first part of said transport identification code in said originating network node and a second part in said receiving network node, said first and second part constituting a whole transport bearer identification code.

10. The method according to claim 1, characterised in that in said requesting step indicating if the multiplexing of said data stream is allowed or not.

11. A method for multiplexing a data stream onto a transport bearer over the Iur and Iub interfaces between Serving Radio Network Controller (SRNC) and Drift Radio Network Controller (D-RNC) or Node B in an IP Radio Access Network mapping a transport bearer resource for a data stream, characterised in that the method further comprises the following steps: checking if there is available transport bearer resources in the group of existing transport bearers, and if there exists a transport bearer resource that can be used for said data stream, reserving said existing transport bearer resource for said data stream, or requesting a new transport bearer resource, and reserving said new transport bearer resource for said data stream.

12. The method according to claim 11, characterised in that identifying said new transport bearer resource with a transport bearer identification code by introducing a new transport bearer id information element (IE) in NBAP/RNSAP messages.

13. The method according to claim 12, characterised in that in said requesting step, indicating an existing transport bearer resource for said data stream by including said transport identification code in a request message from Radio Network Controller or Node B.

14. The method according to claim 11, characterised in that in said requesting step, indicating a need for a new transport bearer resource by sending a request message in which no transport identification code is included.

15. The method according to claim 12, characterised in that in using a unique transport bearer identification code, said transport bearer identification code being unique at least between said Serving Radio Network Controller (SRNC) and said Drift Radio Network Controller (D-RNC) or said Node B

16. The method according to claim 12, characterised in that recording said transport bearer identification code at least for a lifetime of said transport bearer resource in both said Serving Radio Network Controller (SRNC) and said Drift Radio Network Controller (D-RNC) or said Node B.

17. The method according to claim 12, characterised in that allocating said transport identification code in said Serving Radio Network Controller (SRNC).

18. The method according to claim 12, characterised in that allocating said transport identification code in said Drift Radio Network Controller (D-RNC) or said Node B.

19. The method according to claim 12, characterised in that allocating a first part of said transport identification code in said Serving Radio Network Controller (SRNC) said Drift Radio Network Controller (D-RNC) or said Node B.

20. The method according to claim 1, characterised in that in said requesting step indicating if the multiplexing of said data stream is allowed or not.