GB2419064A

GB2419064A - Transmission of protocol version information in radio access networks

Info

Publication number: GB2419064A
Application number: GB0422204A
Authority: GB
Inventors: Himke Van Der Velde; Gert-Jan Van Lieshout
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2004-10-06
Filing date: 2004-10-06
Publication date: 2006-04-12
Anticipated expiration: 2024-10-06
Also published as: GB0422204D0; GB2419064B

Abstract

A method of enabling a radio access network to transmit information to one or more mobile communications devices located in a cell, the transmitted information being associated with the version of the protocol release supported by the radio access network and further being associated with features supported by the version of the protocol release. The transmitted information may be associated with a specific functionality and may further be associated with a new message version. The information may be transmitted as a plurality of individual bits b1-b6, with each bit identifying a functionality and/or message version supported by the radio access network. The transmitted information may be sent to the mobile communications device within a broadcast message and may be broadcast in the cell in which the mobile device established network connection.

Description

24 1 9064

IMPROVEMENTS IN PROTOCOL EXTENSIONS

The present invention relates to protocol extensions, and in particular to an improved method or system of transmitting information associated with the protocol supported by a radio access network.

When specifying how systems are to operate, protocols are laid down to allow operators or suppliers of different parts of the system to introduce and provide their products in such a way that their operations are compatible with the rest of the system.

In order to accommodate changes to functionality in a current protocol release version an extension mechanism is provided to allow, for example, existing parameters to be modified or deleted from a message, new parameters to be added to a message, old messages to be deleted or new messages to be created. Any combination of these may occur to change the currently implemented protocol and produce either a new version or a new release of the protocol.

Usually, when corrections or small enhancements are made to certain functionality available in a particular protocol release, a new version of that protocol release is made available. When adding a substantial amount of new functionality, a whole new protocol release is usually provided. For example, in the Radio Resource Control (RRC) protocol release 99, many versions were released that included additions and modifications in order to correct that functionality. The next release, Release 4, introduced new functionality (i.e. a new mode: 1.28 Mcps Time Division Duplex (TDD), a new header compression algorithm: Robust header compression (ROHC)) and also several versions with corrections. Then Release 5 introduced new functionality - High Speed Downlink Packet Access (HSDPA).

Taking one particular example of a communications network, it is possible to see an example of how protocol extensions are implemented.

A basic structure of a Universal Mobile Telecommunications System (UMTS) network is shown in Figure 1 A. UMTS concerns a 3G (A generation) radio network that uses wideband code division multiple access (W-CDMA) technology. One or more core networks 101 are connected to a Universal Terrestrial Radio Access Network (UTRAN) 103 via an Iu interface. The UTRAN 103 is connected to User Equipment (UK) via a radio interface Uu. The UEs are mobile communication devices, for example, mobile telephones, personal digital assistants (PDAs), or the like.

A more detailed view of UTRAN architecture is shown in Figure 1B.

UTRAN 103 is made up of a number of Radio Network Systems (RNS) 107.

The RNS is connected to the core network 101 via the Iu interface, as described above. Within each RNS 107 are a number of Radio Network Controllers (RNC) 109 and a number of base stations 111. In the case of UTRAN, the base station is called a Node B. Each base station 111 connects to the RNC 109 via an tub interface. Each RNC 109 may be interconnected to one or more other RNCs 109 using an fur interface.

The RRC protocol is used across the radio interface (Uu), between the UE 105 and UTRAN 103. The protocol endpoints (UK 105 and UTRAN 103) interact by exchanging protocol parameters. Protocol parameters are exchanged by sending messages that comprise one or more information elements (IE).

When updating the current RRC protocol, prior to releasing a newer version of the protocol, extensions to current RRC protocol messages are provided through the incorporation of new IE values or choices, and/or new IEs, within the current RRC protocol messages.

Two distinct kinds of protocol extensions are used, non-critical extensions (NCE) and critical extensions (CE). Figure 2 shows a representation of the structure of an RRC message that has critical and non critical extensions included. Non-critical extensions 201 are shown at the end of a message that is extended in a later protocol version. The message further includes the message type 207, the message version 205 and a basic message tail 203. In the case where a message is critically extended, a new version of that message is introduced. Furthermore, the contents, structure and encoding of the message can be completely different.

A methodology is set up to decide how a receiver of the message should react if it cannot comprehend the extensions (CE or NCE) of the message.

In the example given in Figure 2, the message has three non-critical extensions 201. If the receiver of this message cannot comprehend the non critical extensions 201, it shall process the message as if the noncritical extensions 201 were not there. The receiver is able to separate the non critical extensions 201 from the rest of the message (203, 205, 207). This is implemented in RRC by adding the NCE 201 at the end of the message. The receiver then decodes the message up to the first NCE 201 that it does not comprehend. In this example, this could be NCE-1, NCE-2 or NCE-3.

For CE in the RRC protocol, when the receiver does not comprehend a critically extended message it is a requirement that the message is entirely rejected because the receiver does not know how to interpret the new information after the message type and version. The receiver notifies the sender of the message that the message was rejected.

In the case of critical extensions, the basic message tail may be modified in a backwards incompatible manner because the receiver is able to detect the message and version. That is, the receiver will be able to see from the message type and version that it cannot comprehend the critically extended message, because it has not implemented the latest changes associated with those critical extensions, and so be able to respond in a well defined manner by rejecting the message and notifying the sender.

The non-critical extension mechanism as used in the RRC protocol has a number of limitations. Firstly, it is not possible to remove obsolete parameters. This is because an old receiver trying to decode a message wherein an old parameter has been replaced with a new parameter will misinterpret this information and may consider the message to be invalid.

Secondly, each non-critical extension added to the end of a message introduces an additional signalling overhead. Thirdly, the non-critical extension of certain parameters, for example, lists, choices, enumerated, is not efficient due to the duplication of information in the extension.

Critical extensions have a number of different limitations. A new version of a message, which includes a critical extension within the basic message tail, can only be sent a) if the sender knows beforehand that the receiver supports the new version of the message, or b) if the receiver can determine the message version and so provide a suitable response to the sender informing them that it cannot handle the sent version.

The UE informs the network of the protocol version it supports. In addition to this, the current RRC protocol specifies that a UE shall implement the entire transfer syntax of a given protocol version. That is, if a UE supports a new version of a message associated with a new protocol version, it must support all messages defined in that new protocol version. As a result of this, the network knows which message versions it can send to the UE when it knows the protocol version supported by the UK.

Further, although the UE only supports one protocol version, a later protocol is a superset of earlier protocols such that the UE also supports all earlier protocol versions. This ensures the UE is able to interact with earlier networks.

The current RRC protocol does not enable UTRAN to notify the UE of the protocol version it supports.

In line with this, the current RRC protocol does not support the use of the critical extension mechanism for uplink messages.

Therefore, the UE is limited to the number of new uplink functionalities and message versions it is able to implement.

The current principle is that UTRANis not required to support all parts of a specific version of a protocol. For example, if protocol version X includes version N of message B and version N+1 of message A,UTRANis allowed to send protocol version N of message B. while sending a version of message A earlier than version N+1. This allows UTRAN to implement new features independently.

In one known method, it is suggested that UTRAN signals the protocol release version over the Broadcast Control Channel (BCCH) so UEs can send uplink messages to UTRAN safe in the knowledge that UTRANis capable of supporting these messages. However, this method suggests that a UTRAN indicating support of a given protocol release will be required to support all critical extensions defined in that protocol release. This means that UTRAN is not able to support individual new functionalities and/or version messages, thus removing the choice of the vendor as to which parts of a new protocol release to implement, i.e. the vendor has to implement the entire new protocol and incorporate all the new features and all new message versions defined in the release.

3GPP (3rd Generation Partnership Project) technical specifications provide information on the relevant technical aspects of 3G networks. The technical specifications can be found at http://www.3gpp.oru/specs/specs. htm.

Some relevant examples are 3GPP TR 25.921 - Guidelines and principles for protocol description and error handling, 3GPP TS 25.331 - Radio Resource Control Specification and 3GPP TS 25.401 - UTRAN overall Description.

The present invention aims to overcome or at least alleviate some or all of the aforementioned problems.

In one aspect, the present invention provides, in a cellular communication network comprising a radio access network and a number of cells, a method of enabling the radio access network to transmit information to one or more mobile communication devices located in a cell, the transmitted information being associated with the version of the protocol release supported by the radio access network, and further being associated with features supported by the version of the protocol release.

In a further aspect, the present invention provides, in a terrestrial mobile cellular network comprising a core network and a radio access network, the radio access network comprising a radio network controller connected to at least one base station, said base station arranged to be connected via a radio interface to one or more mobile communication devices located in a cell, a method of transmitting information to one or more mobile communication devices over the radio interface, the transmitted information being associated with the version of the protocol release supported by the radio access network, and further being associated with features supported by the version of the protocol release.

In yet a further aspect, the present invention provides a system with a transmitter and a receiver, wherein the receiver can support a plurality of different versions of a protocol release and the transmitter can select which functions of a version of a protocol release to implement, the system comprising a signalling means arranged to transmit information to the receiver, said information being associated with the functions the transmitter can implement.

The present invention provides the advantage of enabling the use of backwards incompatible changes in uplink messages while maintaining the network freedom to implement a selected set of the new elements defined in a new protocol release.

The present invention also provides an advantage of allowing UEs to implement new or improved features and/or message versions that it supports without having to wait for the entire protocol release in which it is defined to be finalized.

The present invention also provides an advantage of enabling UEs to initiate new or improved uplink functionality so UEs can implement new features and/or new version messages depending on the support provided by a radio network.

The present invention also provides an advantage of enabling a radio network the freedom of supporting a subset of enhancements and/or extensions that are to be released in a later protocol release.

The UE may implement new functionality and/or message versions in the parts of the whole network for which support of the new functionality is indicated.

Specific embodiments of the present invention will now be described by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows a basic structure for a known UMTS; Figure 2 shows a detailed view of known UTRAN architecture; Figure 3 shows a summary of the UTRAN item support bit-set allocation according to an embodiment of the present invention;

FIRST EMBODIMENT

In the first embodiment of the present invention, UTRAN signals a set of bits, each of which can be set independently. Each bit within the signalled bit-set indicates that UTRAN can support a specific functionality.

For example, a bit can indicate support of a specific version of a message. A bit could also indicate support of a number of specific messages/ message versions. Also, a bit could indicate support of certain functionality associated with the network, for example, improved encoding of messages.

In this embodiment, the number of bits allocated in the standard is six, although the invention is not limited to this number of bits.

Figure 3 shows a summary of the bit allocation according to this embodiment. During a given protocol release N. functionalities P and Q are introduced. A network conforming to protocol release N optionally supports the associated functionality. Functionality P is implemented by making changes to message A, resulting in version 2 of message A. Functionality Q is implemented by making changes to messages D, E and F. resulting in version 2 of each of these messages.

In protocol release N+l, functionalities R and S are introduced.

Functionality R is implemented without affecting any existing messages, or creating any new messages. Functionality S is implemented by making further changes to message D, resulting in version 3 of that message.

The bit-set of the present embodiment is then deemed as follows. Bit number one indicates that functionality P is supported by UTRAN, through the implementation of version 2 of message A. Bit number two indicates that functionality Q is supported by UTRAN through the implementation of version 2 of messages D, E and F. Bit number three indicates that functionality R is supported by UTRAN without requiring any message changes. Bit number four indicates that functionality S is supported by UTRAN through the implementation of version 3 of message D. Bit number five indicates that version 3 of message C is supported by UTRAN, but does not result in any new functionality. Bit number six is reserved for further new functionalities to be defined in the future.

In this embodiment, in order for UEs on the network to receive the UTRAN item support bit-set, UTRAN broadcasts the bit-set over the radio interface within a broadcast message using the Broadcast Control Channel (BCCH).

If the UE is in idle mode, it will always consider the information being broadcast by the cell the UE has selected.

If the UE is in CELL_DCH mode, the UE will consider the information within the UTRAN item support bit-set received in the cell where its connection was established.

If the UE is in a connected mode state other than CELL_DCH, for example, CELL_PCH, URA_PCH, CELL_FACH, there are a number of different options available for the UE to consider the information in the UTRAN item support bit-set.

Firstly, the UE may consider information in the UTRAN item support bitset that is broadcast in the cell in which the UE performed connection establishment.

Secondly, the UE may consider the information in the UTRAN item support bit-set that is broadcast in the currently selected cell.

Thirdly, the UE can consider the information in the UTRAN item support bit-set that is broadcast in the cell in which the connection was established, and also consider the information in the UTRAN item support bit-set that is broadcast in the currently selected cell.

A decision as to which of the scenarios above is used is made for each individual bit the UE considers in the UTRAN item support bit-set. I.e. the UE may consider bit number one for the currently selected cell, but may consider bit number two for the cell in which the connection was established.

Once the UE has determined which bits to consider in which cells, it can then apply the associated functionality and/or new version messages if it is capable of supporting them, since it knows the associated part of the UTRAN has the support capability for the functionality andlor new version message.

This embodiment of the present invention enables the UE to selectively use certain functionalities and/or new version messages.

SECOND EMBODIMENT

As well as including the UTRAN item support bit-set as described in the above embodiment, this embodiment concerns itself with additionally indicating the current version of the protocol being supported by UTRAN.

The item support bit-set of the previous embodiment is combined with a release indicator. In this case, the release indicator would indicate that the network supports all functionality that is defined as mandatory for a network conforming to the indicated release. Table 1 below indicates how the implementation of the invention according to this embodiment would be beneficial for each protocol version released.

UTRAN release UTRAN item Bit Mandatory in release b1 N+1 Q b2 N+2 N+1 R b1 N+2 b3 N+3 N+2 T b1 - (never) b2 N+3

TABLET

The above table shows that, for protocol release N. bit number one would indicate functionality P is supported by UTRAN even though it is not mandatory for UTRAN to support this functionality until protocol release N+1. Also, bit number two would be used to indicate functionality Q is also supported by UTRAN running protocol release N. although functionality Q is not mandatory until protocol release N+2.

If UTRAN indicates that it supports protocol release N+1, then this implies that UTRAN supports all the mandatory functionality defined for this release. In this case, support of release N+1 implies that UTRAN supports functionality P (see above table). This means in release N+1, bit one need not indicate support of functionality P anymore. In fact this means that the very same bit can be re-used to indicate support of another functionality R. This embodiment allows certain bits in the UTRAN item support bit set to be redefined.

In this embodiment, the protocol release version in which a certain function is to be included is agreed at the same time as defining the bit that indicates that function is supported by UTRAN.

This embodiment enables a UE to derive whether support for certain functionality is available either based on the protocol release UTRAN indicates it supports or based on the corresponding UTRAN item support bit.

Also, with reference to bit number one of the UTRAN support bit set for a UTRAN that supports release N+2, shown in table 1 above, it can be seen that a certain functionality, T in the example, will not be part of the baseline of any protocol version release. However, the corresponding bit indicates support of that functionality in all protocol releases following the release that was current at the time the functionality was introduced.

Further, if a feature becomes mandatory after a certain protocol release, UTRAN support of that functionality is implied by the protocol release version and so a bit does not need to be allocated for that functionality in the UTRAN item support bit-set. This frees up the bit for it to be used to indicate support for other functionalities, when available.

FURTHER EMBODIMENTS

It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.

Although in the above embodiments, the number of bits allocated in the UTRAN support bit-set is set to six, it will be understood that any number of bits may be allocated depending upon the new functionalities and new versions of messages that become available.

Although in the above embodiments, the UTRAN item support bit-set or protocol release is broadcast over the network, it is also understood that these may be transmitted by alternative means. For example, UTRAN may provide the information within a dedicated message, for example, the UTRAN MOBILITY INFORMATION, the CELL_UPDATE CONFIRM or a reconfiguration message. This option enables the UE to be informed of the capabilities of a new RNC and so determine if the new RNC capabilities are different, for example, when a UE in CELL_DCH mode moves to another RNC (i.e. a serving RNC (SRNC) relocation).

Alternatively, if the UE is in CELL_DCH mode and the item bit-set is transmitted using a dedicated message, the UTRAN item support bit-set may be received by the UE through the dedicated message.

Although in the second embodiment the protocol release version in which a certain function is to be included is agreed at the same time as defining the bit that indicates that function is supported by UTRAN, it will be understood that the allocation of the bit to a certain function may take place at a different time to the agreement of that function being released in a certain protocol release version.

Although the invention has been described in the embodiments in relation to UMTS and the RRC protocol, it will be understood that the invention may be applied to any form of communications system wherein information on the enhancements of the protocol release version would usefully be transmitted to receiving equipment in the communications system.

Claims

1. In a cellular communication network comprising a radio access network and a number of cells, a method of enabling the radio access network to transmit information to one or more mobile communication devices located in a cell, the transmitted information being associated with the version of the protocol release supported by the radio access network, and further being associated with features supported by the version of the protocol release.

2. The method according to claim 1, wherein the transmitted information is associated with a specific functionality.

3. The method according to claim 2 or claim 1, wherein the transmitted information is associated with a new message version.

4. The method according to claim 2 or claim 1, wherein the information is transmitted as a plurality of individual bits, with each bit identifying a functionality and/or message version supported by the radio access network.

5. The method according to claim 1, wherein the method farther comprises sending further information identifying the current radio interface protocol that the radio access network has implemented.

6. The method according to any previous claim, wherein the information transmitted is sent to the mobile communication device within a broadcast message.

7. The method according to claim 6, wherein the information is broadcast in the cell in which the mobile communication device performed connection establishment.

8. The method according to claim 6, wherein the information is broadcast in the currently selected cell.

9. The method according to claim 6 wherein the information is broadcast in the currently selected cell and also broadcast in the cell in which the mobile communication device performed connection establishment.

10. The method according to any of claims 1 to 5, wherein the information is transmitted to the mobile communication device within a dedicated message.

11. In a terrestrial mobile cellular network comprising a core network and a radio access network, the radio access network comprising a radio network controller connected to at least one base station, said base station arranged to be connected via a radio interface to one or more mobile communication devices located in a cell, a method of transmitting information to one or more mobile communication devices over the radio interface, the transmitted information being associated with the version of the protocol release supported by the radio access network, and further being associated with features supported by the version of the protocol release.

12. A terrestrial mode cellular system arranged to carry out the method according to any preceding claim.

13. A radio network controller adapted to transmit the information by the method according to any of claims 1 to 10.

14. A mobile communication device specifically adapted to receive the information transmitted by the method according to any of claims 1 to 10.

15. A system with a transmitter and a receiver, wherein the receiver can support a plurality of different versions of a protocol release and the transmitter can select which functions of a version of a protocol release to implement, the system comprising a signalling means arranged to transmit information to the receiver, said information being associated with the functions the transmitter can implement.