GB2423215A

GB2423215A - A method of communicating using an extension of the radio protocol

Info

Publication number: GB2423215A
Application number: GB0503023A
Authority: GB
Inventors: Gerardus Johannes Pet Lieshout; Himke Van Der Velde
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2005-02-14
Filing date: 2005-02-14
Publication date: 2006-08-16
Anticipated expiration: 2025-02-14
Also published as: GB2423215B; GB0503023D0

Abstract

A method of communicating via a cellular communications network, the method comprising: communicating between a mobile terminal and one or more network elements via radio messages according to a radio protocol, wherein the format of said radio messages includes a basic message portion corresponding to a first version of the radio protocol, and an extension container portion, wherein said extension container portion is adapted to include one or more extension blocks relating to one or more subsequent versions of the radio protocol.

Description

Mobile Communications

Technical Field

This invention relates to the field of mobile communications. More particularly, but not exclusively, it relates to extending radio messages according to a radio protocol for communicating between a mobile user equipment and a radio access network, such as the UMTS Terrestrial Radio Access Network (UTRAN).

In a UIMTS network, the Radio Resource Control (RRC) protocol is used across the radio interface, i.e. between the user equipment and the radio access network. These protocol end points interact by exchanging protocol parameters, and by sending radio messages comprising of one or more information elements.

This IPR proposal is mainly applicable to the Radio Resouce Control protocol as used on the UMTS radio interface, although applicability to other similar systems is not excluded. For UMTS, it is expected to be applicable to all releases.

Background information

A brief description of the UMTS radio network architecture as well as an introduction into the general protocol extension mechanism used for the Radio Resource Control protocol are provided in an annex at the end of this document.

Background Art

UTRAN may comprise of RNCs conforming to different protocol releases! versions. Although the UTRAN protocols are designed to handle this, there is a limitation that has been discussed a number of times in 3GPP working group RAN 2: upon SRNC relocation, the UE capability information provided to the target RNC is restricted to a subset of the capability information originally signalled by the UE to the source SRNC. The source SRNC only forwards the part of the capability information up to the protocol version it supports. As a result of this, UE capability information that is not comprehended by the source SRNC is not available to the target SRNC. As a result of this, the target SRNC may have to postpone invoking functionality introduced in later releases even though both the RNC and the UE support it.

Although the issue has been raised a number of times, no solution has been proposed so far; so far the limitation has been accepted.

It should be noted that the problem does not exist upon handover from another RAT to UTRAN, the so called handover to UTRAN. The reason is that in this case the UE capability information is packaged in a container that is forwarded transparently from the source RAT to the target RNC.

The reason for using a transparent container is that the information contained is transparent to the source RAT ie. the source RAT need not process nor act on this information, which is UTRAN specific. In the case of SRNC relocation however, the information is not transparent to the source SRNC ie. the source RNC should process and act on all the received information, as far as it comprehends this. This is probably the main reason why so far the use of a (transparent) container has not been considered for the SRNC relocation case.

Disclosure of the Invention

Rather than using the regular non- critical extension mechanism, the proposal is to include the relevant protocol extensions in a Variable Length Extensions Container (VLEC). The use of the VLEC allows an RNC to forward the entire container even though it does not comprehend part of the information contained. On the other hand, the VLEC still enables the RNC to process and act upon the extensions included in the container up to the protocol version it supports.

This approach is considered especially suitable for protocol extensions concerning new UE capabilities, especially the capabilities relevant to immediately activate upon SRNC relocation. However, the use of the transparent container for other information is not excluded.

The solutions proposed in this document have the following main advantages: Upon SRNC relocation, the information received by target RNC is not limited by the protocol version supported by the source RNC. As a result, upon SRNC relocation the target RNC is able to immediately invoke newly introduced functionality irrespective of the support of this by the source

SRNC

The proposed solution involves a slight increase in the size of the messages used to transfer the corresponding information. However, this not considered to be a severe drawback.

Note While in UTRAN, the UE signals its capability information upon RRC connection establishment, whenever its capabilities change or upon receiving a capability request from UTRAN.

Backiround information (Annex) Radio Network Architecture As illustrated in Figs. I and 2, the typical architecture of a cellular radio system comprises of mobile user equipments (UEs), a radio access network (RAN) and one or more core networks (CNs) as shown in Figs. I and 2 for the Universal Mobile Telecommunications System (UMTS) case, see UTRAN Overall Description, 3GPP TS 25.401. UMTS concerns a third generation radio network using wideband code division multiple access (W- CDMA) technology.

The typical architecture of a radio access network comprises of base stations and radio network! base station controllers (RNC/ BSC). The base stations handle the actual communication across the radio interface, covering a specific geographical area also referred to as a cell. Besides controlling the base stations connected to it the RNCs includes functionality like the allocation of radio resources, local mobility. An RNC connects: * to one or more core networks via the lu interface, * to a number of base stations (node B's for the case of UTRAN) via the lub interface and * possibly to one or more other RNCs via the lur interface.

RRC protocol extension The Radio Resource Control (RRC) protocol is used across the radio interface, between the UE and UTRAN. These protocol end points interact by exchanging protocol parameters, by sending messages comprising of one or more information elements. In order to accommodate different (future) versions of this protocol, a mechanism has been defined for extending these RRC messages with new information element values andl or new information elements.

Two kinds of protocol extensions are distinguished: non-critical extensions (NCE) and critical extensions (CE). In general, a receiver shall entirely reject a message including not comprehended critical extensions (and notify the sender). This property means that a critically extended message need not build from the previous version. Instead, a critical extension of a message basically allows for defining a completely new version of the message. Since the message version is indicated at the start of the message, a receiver immediately knows whether or not to reject the message.

In contrast, a receiver shall process a message including not comprehended NCEs- as if the extensions were absent. This means that the receiver shall be able to separate the non- critical extensions, which in the case of RRC is achieved by adding the non- critical extensions at the end of the message. This means that a receiver decodes a message up to the first NCE that it does not comprehend.

Fig. 3 illustrates the overall message structure which comprises of a header consisting of a message type and a version, followed by a message tail and a number of NCEs. Fig. 3 also illustrates that when a new version of a message is defined, the tail of the message can be changed in a backwards incompatible manner. As long as the receiver is able to detect the message type and version, it will respond in a well defined manner that is reject the message and notify the sender.

Note Further details about the RRC protocol extension mechanisms are provided in "Radio Resource Control Specification (RRC)", 3GPP TS 25.33 1, "Guidelines And Principles For Protocol Description And Error Handling", 3GPP TS 25.92 1 and "Signalling of UTRAN Release on BCCH", R2- 04 1655, Qualcomm.

Claims

CLAIMS: 1. A method of communicating via a cellular communications

network, the method comprising: communicating between a mobile terminal and one or more network elements via radio messages according to a radio protocol, wherein the format of said radio messages includes a basic message portion corresponding to a first version of the radio protocol, and an extension container portion, wherein said extension container portion is adapted to include one or more extension blocks relating to one or more subsequent versions of the radio protocol.
2. A method according to claim 1, wherein said extension container portion is transparent.
3. A method according to claim 1 or 2, wherein said extension container portion includes late extensions.
4. A method according to claim 1, 2 or 3, wherein said extension container portion is of variable length.
5. A method according to any of claims 1 to 4, wherein the extensions in said extension container are ordered according to the date of

introduction of the extensions.
6. A method of extending radio messages according to a radio protocol in a cellular communications network, wherein said messages are adapted for the use in the communication between a mobile terminal and network elements via radio messages, and wherein the format of said radio messages includes a basic message corresponding to a first version of the radio protocol, and an extension container including one or more extensions relating to one or more different versions of the radio protocol.
7. A method according to any of claims I to 6, wherein all extension blocks relating to subsequent versions of the radio protocol are included in said extensional container portion.
8. A method according to any of claims 1 to 7, wherein said radio message is transmitted from a first to a second network element.
9. A method according to claim 8, wherein said first network element does not comprehend the information included in one or more of said extension blocks of the extension container portion.
10. A method of communicating via a cellular communications network, the method comprising: a mobile terminal communicating with network elements via radio messages according to a radio protocol, wherein the formal of said radio messages include a basic message and a extension block container, wherein said extension block is of variable length and includes more than one extensions.
11. A method according to any of claims 1 to 10, wherein said radio protocol is the RRC protocol according to the IJMTS standards.
12. A network element for communicating via a cellular communications network, adapted to communicate according to the method as claimed in any of claims 1 to 10.
13. A mobile terminal for communicating via a cellular communications network, adapted to communicate according to the method as claimed in any of claims ito 10.
14. A radio message for conmiunicating via a cellular communications network using a radio protocol wherein the radio message includes a basic message portion corresponding to a first version of the radio protocol, and an extension container portion, wherein said extension container is adapted to include one or more extensions relating to one or more different releases of the radio protocol.
15. A mobile terminal for communicating via a cellular communications network, the terminal being adapted to process a radio message according to a radio protocol received from a network element, wherein the format of said radio messages includes a basic message portion corresponding to a first version of the radio protocol, and an extension container portion adapted to include one or more extensions relating to one or more subsequent versions of the radio protocol.