GB2424794A - Improving the use of pre-configuration in a wireless communication network - Google Patents

Abstract

A mobile communication device entering a new cell, keeps its last assigned radio resource configurations if it is not already pre-configured with radio resource parameters.

Description

IMPROVEMENTS IN THE USE OF PRE-CONFIGURATION

The present invention relates to improvements in the use of preconfiguration, and more particularly to a method, network or device wherein previously assigned configurations are maintained if not part of a pre- configured configuration.

A brief description of the UMTS radio network architecture as well as an introduction into the pre- configuration mechanism as used for the Radio Resource Control protocol is now provided.

Radio Network Architecture The typical architecture of a cellular radio system comprises mobile user equipments (UEs), a radio access network (RAN) and one or more core networks (CNs) as shown in Figure 1. For the Universal Mobile Telecommunications System (UMTS) case, see Radio Resource Control Specification (RRC), 3GPP TS 25.331. UMTS concerns a third generation radio network using wideband code division multiple access (W-CDMA) technology.

The typical architecture of a radio access network is shown in Figure 2 and comprises 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 and the use of pre- configuration 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. The UMTS radio protocols are generally considered to be very flexible protocol including a large number of protocol options. A large number of protocol parameters have been defined to accommodate the configuration of the different protocol options. Due to the high number of these protocol parameters, the RRC messages exchanged, e.g. upon establishment of a speech call, are quite large. Especially when common channels are used, the delay involved to transfer the RRC messages is considered to significantly contribute to the overall establishment delay.

In order to combat the above mentioned transfer delays, the use of preconfiguration has been adopted as a means to reduce the size of a number of messages. When using pre-configuration, the value of a majority of the parameters is not signalled anymore. Instead, UTRAN includes a reference to a pre-configuration, which can either be a default or a pre- defined configuration: fàult configurations: a set of parameters for which the values are specified in the standard (i.e. hard coded).

* pre-defined configurations: a set of parameters for which the UE acquires the values beforehand i.e. by reading the broadcast channel (System Information Block Type 16).

In summary, when using pre-configuratjon, a single reference replaces the signalling of a large number of parameter values. The existing preconfiguration mechanism can further be characterisecl by means of the following aspects: * General: While default configurations are intended to generally support robust configurations, the pre-defined configuration mechanism has been introduced to facilitate the use of more specific configurations, optimised for a specific configuration. The configuration that is optimal to use in a specific case may depend on a large number of factors e.g. the RNC and node B capabilities, the cell characteristics (macro, micro).

* Usage: UTRAN can apply pre-configuration upon handover from GSM, upon RRC connection establishment and in case of handover from GERAN lu (using the radio bearer reconfiguration procedure). In all these cases, the UE starts from scratch with a pre-configuration, which can include at most 1 RAB.

Identification and validity: A predefined configuration is identified by an identity (4 bits) and a value tag (4 bits). Pre-defined configurations are valid within the scope of an equivalent PLMN, for a limited duration (up to 6 hours).

* Acquisition: UTRAN can broadcast up to 16 different pre-defined configurations in a cell, each using a different occurrence of SIB 16.

When in GSM, the UE is required to receive this information from UTRA neighbouring cells. The UE shall be able to store 16 pre- defined configurations.

* Status reporting: The UE reports the pre- defined configurations it has stored in conjunction with reporting its capabilities, both in UTRA and in GSM. In addition, during RRC connection request the UE indicates if it has stored all pre- defined configurations broadcast in the cell. The UE does not indicate which default configurations it supports - this is implicit from the access stratum release indicator.

The problem with known systems is as follows: Currently pre- configuration is used upon handover from GSM/ GERAN lu and upon RRC connection establishment, which are all cases in which the UE enters CELL DCH without having a CELL_DCH configuration stored from a previous assignment. Furthermore, the currently defined default configurations include combinations of signalling radio bearers (SRBs) 1 through 3 with a single CS RAB (single and multi rate speech, some including transpasent DCCH for rate control, conversational CS data and streaming CS data).

It has been agreed to extend the use of pre- configuration by introducing the use of the existing default configuration mechanism in the radio bearer set-up message.

One of the scenario's the pre- configuration extension is intended to cover is the case a UE in CELL FACH for which a CS RAB is to be established. CELL_FACH is a transition state, in which the TilE has typically been assigned a CELL DCH configuration for SRB 1- 4 as well as for one or more PS RABs. In case the radio bearer establishment message would now assign one of the existing default configurations, this raises a number of questions: What happens with the SRBs (especially SRB4) and the PS RAB(s) the TiE had established? * What happens with the TrCh- and PhyCh configuration for CELL DCH that had been assigned to the UE? The above issue very much relates to the seemingly incompatible characteristics of reconfiguration messages and pre-configurations. In general reconfiguration messages specify the target configuration by indicating the changes to the current configuration i.e. which channels are released, changed and/or added. Pre- configurations however, are commonly used target configurations intended to be used irrespective of the details of the UE's current radio configuration.

One could consider the pre-configuration used in case of radio bearer establishment to specify the complete target configuration. However, this would imply that SRBs and RABs that are not included in the default configurations are released and may need to be established again. Since this may involve loss of information, this approach does not seem to be very attractive.

Also, one could introduce additional default configurations including SRB4 and including PS RABs. From a specification point of view this approach is rather straightforward. However, the drawback is that the number of default configurations increases, which increases the required UE memory to store the default configuration details.

Further examples of configurations can be found at R2-050463 - Stored configurations during radio bearer set up, and R2-050547 - Extension of the use of default configurations.

The present invention aims to overcome, or at least alleviate, one or more of the afore-mentioned problems.

In one aspect the present invention provides a method of improving the use of pre-configuration in a cellular communication network including one or more mobile communication devices, the method comprising the steps of: the mobile communication device entering a new cell, and the mobile communication device keeping previously assigned radio resource configurations if not already configured in a pre-configured configuration specifying one or more radio resources.

In a further aspect the present invention provides a cellular communication network comprising one or more mobile communication devices wherein the cellular communication network is adapted to allow the mobile communication device, upon entering a new cell, to keep previously assigned radio resource configurations if not already configured in a preconfigured configuration specifying one or more radio resources.

In yet a further aspect the present invention provides a mobile communication device adapted to work in a cellular communication network wherein the mobile communication device is adapted to keep previously assigned radio resource configurations upon the mobile communication device entering a new cell if not already configured in a pre-configured configuration specifying one or more radio resources.

A specific embodiment 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 typical architecture cellular UIMTS network.

Figure 2 shows a typical UTRAN architecture.

EMBODIMENT

The following embodiment relates to the Radio Resource Control protocol as used on the UMTS radio interface, although applicability to other similar systems is not excluded. For LJMTS, it is expected to be applicable from release 6 onwards.

Pre-configurajo upon radio bearer establishment Instead of specifying additional default configurations, the invention defines a mechanism allowing the continuation of SRB4 and PS RABs in combination with the SRBs and the RABs included in the default configuration.

This approach implies that the details are specified of how the UE continues the SRBs and RABs for which it has a CELL_DCH configuration assigned in conjunction with the default configuration. It is important this is achieved without signalling many parameters, since that would defeat the signalling optimisation. The reference configurations defined in TS 34.108, illustrate that: * The SRBs are typically mapped together on a TrCh * The CS RAB is typically mapped on to one or more separate TrCh * The PS RAB(s), is! are typically mapped on to another, one or more, separate TrCh * For configurations including SRBs, CS and PS RABs, the TFCS typically includes all possible TF- combinations of the TrCh carrying the PS RAB(s). The configuration includes all these PS- combinations in combination with the defined TF combinations of the TrCh carrying signalling and the TrChs carrying CS RAB Considering the above typical use, it seems possible to specify how the UE shall continue SRB4 and PS RAB(s) in combination with the SRBs and the RABs included in the default configuration without signalling any additional parameters. One possible way to achieve as follows: The target configuration consists of the SRBs and RAB configuration that has previously been assigned with the SRB and RAB configuration included in the default configuration. In general, for the previously assigned SRBs/ RABs the following options could apply: Remapped: the SRB/ RAB is mapped to an SRB/ RAB configuration that is part of the default configuration. This option would normally apply for SRB13.

* Continued: the SRB/ RAB continues alongside the SRB/ RAB configuration included the default configuration. This option would normally apply for SRB 4 and the previously assigned PS RABs.

* Released: the SRB/ RAB is released i.e. it is not part of the target configuration.

Besides the previously assigned SRBs/ RABs, the default configuration would typically include one or more RABs that are newly established'.

The rules the UE shall apply upon radio bearer establishment using a default configuration should not only clarify what happens with the SRBs and RABs but also specify the details of the transport and physical channel configuration. The proposal is as follows: * For an SRB that continues (SRB4), the RB configuration continues unaltered, except that SRB4 will be re-mapped to the TrCh in the default configuration that carries the others SRBs (logical channel multiplexing).

* For the RABs that continue, both the radio bearer and the transport channel configuration continues unaltered.

* The TFCS will be a combination of the all TF combinations of the TrCh(s) carrying PS RAB(s) in combination with the TF combinations for the other TrCh as included in the TFCS of the indicated TFCS.

* Even if default configuration is used, the PhyCh configuration, which is considered to be limited in size, may be specified completely in the message in which case that part of the default configuration is not applied. If eg. no PS RABs are maintained, there should be no problem to apply the PhyCh configuration of the default configuration.

Note that a similar approach is used during RRC connection establishment.

One final issue is that the RB and TrCh identities used for the PS RAB could conflict with the RB identities used by the default configuration. This issue can either be solved by specify that UTRAN is responsible for avoiding such conflicts or by specifying an algorithm for resolving conflicts, involving a re- allocation of the identities of the PS RAB(s) or the CS RAB included in the default configured. In case UTRAN avoids the conflict, it should only apply the continue' option in case this will not result in any conflicts concerning the RB and TrCh identities.

The proposals discussed in the previous section concerned the case of using a default configuration upon radio bearer establishment. However, the same proposals apply equally well in case pre-defined configurations are used instead of default configurations.

One further generalisation would be to cover cases other than CS RAB establishment e.g. PS RAB establishment. In this respect it should be noted that a pre-configuration could include a PS RAB, i.e. the RAB to be established, while a similar PS RAB has been assigned previously. in this case one would like to end up with a configuration including both of the RABs. If the RABs are of similar nature, one may want to multiplex them on the same transport channel. To accommodate this, the proposal is to extend options for the previously assigned SRBs/ RABs indicated in the previous (re- map, continue, release) with the following option: Multiplex with: the SRB/ RAB is multiplexed on to the same TrCh as used by the indicated SRB/ RAB configuration that is part of the default configuration. This option would apply upon of a PS RAB establishment The proposals discussed so far, the UE action is indicated only at the level of the previously assigned SRBs/ RABs while the action for the TrCh and TFCS is derived implicitly from that. However, in some scenarios the rules defined for the implicit handling of the TrCh and TFCS may give the desired result. To accommodate such scenario's, the proposal is to include the option to provide additional signalling at the TrCh and! or TFCS level to explicitly indicate the desired UE action.

Example

The following shows for an example case the previously assigned configuration, the default configuration indicated in the radio bearer establishment message and the corresponding UE action. The following table shows the TilE action for the SRBs, RABs, TrChs and for the TFCS.

Eltem Existing config Default config UE action SRB 1-3 Assigned Included Remap SRB 4 Assigned Not included Continue PS RAB: Assigned Not included Continue RAB Not assigned Included Establish Table 1: UE action for SRBs and RABs Item Existing config Default config TiE action TrCh 1 Assigned Not included Release (carrying SRB I - 4) TrCh 2 Not assigned Included Establish and (carrying SRB I - map SRB4 to this 3): TFO, TFI TrCh TrCh 4 Not assigned Included Establish (carrying CS RAB subflow): TFO, TF 1, TF2 TrCh 5 Not assigned Included Establish (carrying CS RAB subflow): TFO, TF1 TrCh 6 Not assigned Included Establish I (carrying CS I RAB subflow): I TFO,TF1 TrCh 8 - Assigned: TFO, Not included Continue

L ___________

Table 2: UE action for TrCh Note 1 A UTRAN implementation may apply different TrCh identities in uplink and downlink. This is not shown since it would complicate the example. However, the same principles apply.

Note 2 In many networks the PS RABs use a lower TrCh identity than the SRBs. The example does not change a lot if e.g. TrCh identity 1 would be used for the PS RAB that is maintained.

The TFCS table would still include the same combinations, but possibly in a different order. Every TFC has its own CTFC value, which value is calculated taking into account the transport channel identities. Hence, an example with different TrCh identities would result in different CTFC values.

TFCS TrCh 2 TrCh 4 f TrCh 5 TrCh 6 TrCh 8 Comment 0 TFO TFO TFO TFO TFO 1 TFO TFI TFO TFO TFO 2 TFO TF2 TF1 TF1 TFO 3 t'i TFO TFO TFO TFO 4 TFI TF1 TFO TFO TFO TF1 TF2 TF1 TFI TFO 6 TF0 TFO TFO TFO TF1 7 - TFO TF 1 TFO TFO TF 1 8 TFO TF2 TF1 TF 1 TF 1 9 TF1 TFO TFO TFO TF1 TF1 TF1 TF0 TFO TF1 11 TF1 TF2 TFI TF1 TF1 12 - TFO TFO TFO TFO TF2 13 TFO TF1 TFO TFO TF2 14 TFO TF2 TF1 TF1 - TF2 TF1 TFO TFO TFO TF2 16 TF1 TF1 TFO TFO TF2 TF1 TF2 TF1 TF1 TF2 Table 3: UE action for TFCS Note: The bold marked part of the table corresponds with the TFCS specified for the indicated default configuration.

Introduction of prc-configurajon groups! packages

A pre-configuration is a set of parameter values, which currently is either specified in the standard (default configuration) or transferred to the UE through broadcast information (SIB 16). However, in principle there could be many other ways for the UE to acquire such information. Mechanisms that have been suggested include transfer via dedicated signalling, transfer via upper layers e.g. downloading from a web page.

With this in mind, it is considered beneficial to have as much as possible one commonlgeneral pre-configurafion mechanism that is independent of how the UE acquires the information. To achieve this, the proposal is to introduce a means to group/package pre-configurations.

Examples of packages are: default configurations, pre-defined configurations, a set of configurations downloaded from a website e.g. the optimal configurations for a specific liE class for use in a specific (part of a) network.

It is expected that the number of pre-configurations will increase e.g. to include more advanced TIE and network capabilities. However, the existing pre-configuration status reporting mechanism is not really optimised to handle this in an efficient manner even though this information is exchanged in size critical messages.

Pre-configuration groups! packages could help to limit the signalling overhead when reporting the status of pre-configurations; instead of indicating the status of each pre-configuration, the UE can report the status of the entire group. E.g. if the UE has stored a pre-configuration package, it would report the package's value tag rather than reporting the value tag of each stored pre- configuration.

It should be noted that some of the pre-configurations the UE has stored could be applicable only in a limited part of the network e.g. configurations for indoor or applicable for a specific UTRAN vendor. Hence, a further signalling optimisation could be achieved if UTRAN indicates for which groups/packages it would like the UE to report the status.

With the introduction of pre-configuratjon groups/packages, the preconfiguration mechanism is generalised, focussing on the preconfiguration mechanism elements that are really AS- specific: the usage, the identification, the validity (scope rather than duration) and the preconfiguration status reporting (and not on the acquisition and maintenance aspects, since these could be out of scope of the AS). Concerning these aspects, the introduction of general pre-configuration packages is considered to have little impact on

the specification:

* For configurations that are obtained outside the scope of the access stratum, it seems appropriate to re-use the concept of a value tag.

* For configurations that are obtained outside the scope of the access stratum, it seems appropriate to re- use the concept that configurations are valid within an equivalent PLMN. It is clearly undesirable that such configuration information is cleared upon power off7after 6 hours. It seems that no AS-specific clearing procedures are needed for such configurations.

* It seems easy to enhance the pre-configuration status reporting procedures in a manner that UEs does not indicate the status of each individual pre-configuration but instead may also report the status of entire pre-configuration package(s). As mentioned before, a further enhancement would be that UTRAN indicates for which packages it would like the UE to report the status.

It should be noted that, the acquisition of pre- defined configuration information outside the scope of the access stratum, still requires that the contents of the information is specified within RRC.

Pre-configuratjn upon radio bearer establishment The invention provides the following main advantages: * It introduces a means to continue previously assigned SRBs and RAB(s) that are not part of the default configuration * The invention provides a mechanism that allows continued use of such SRBs and RABs without introducing additional default configurations including these The increased UE complexity is considered to be relatively small and

hence acceptable.

Introduction of pre-configuratjon groups! packages

The solutions proposed in this application have the following main advantages: * Generalises the pre-configuration mechanism, making it independent of how the UE acquires pre-configurations. This allows the use of new kind of acquisition mechanism eg. downloading from a web page * Improves the signalling efficiency of the pre-configuration status reporting for the typical case a UEs has stored an entire preconfigurations group! package The increased UE complexity is considered to be relatively small and

hence acceptable.

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

Claims (3)

1. A method of improving the use of pre-configuration in a cellular communication network including one or more mobile communication devices, the method comprising the steps of: the mobile communication device entering a new cell, and the mobile communication device keeping previously assigned radio resource configurations if not already configured in a pre-configured configuration specifying one or more radio resources.

2. A cellular communication network comprising one or more mobile communication devices wherein the cellular communication network is adapted to allow the mobile communication device, upon entering a new cell, to keep previously assigned radio resource configurations if not already configured in a pre-configured configuration specifying one or more radio resources.

3. A mobile communication device adapted to work in a cellular communication network wherein the mobile communication device is adapted to keep previously assigned radio resource configurations upon the mobile communication device entering a new cell if not already configured in a pre- configured configuration specifying one or more radio resources.