WO2013091665A1

WO2013091665A1 - Ue wireless capability change indication

Info

Publication number: WO2013091665A1
Application number: PCT/EP2011/006437
Authority: WO
Inventors: Woonhee Hwang; Robert Zaus
Original assignee: Nokia Siemens Networks Oy
Priority date: 2011-12-20
Filing date: 2011-12-20
Publication date: 2013-06-27

Abstract

The present invention provides methods, apparatuses and a computer program product for UE capability change indication. The present invention includes determining, at a user equipment, whether the user equipment supports different sets of radio capabilities, determining, at the user equipment, whether the user equipment changes from a first cell using a first mode for which the user equipment reported its radio capabilities last time to a second cell using a second mode, the first mode and the second mode corresponding to different sets of radio capabilities that the user equipment supports, determining, at the user equipment, if it is determined that the user equipment changes from the first cell using the first mode to the second cell using the second mode, whether the user equipment changes to a connected mode, inserting, at the user equipment, if it is determined that the user equipment changes to a connected mode, an indicator indicating that an update of the radio capabilities of the user equipment is needed into a Service Request message or an Extended Service Request message, and sending the Service Request message or an Extended Service Request message to a network.

Description

DESCRIPTION

UE WIRELESS CAPABILITY CHANGE INDICATION

Field of the invention

The present invention relates to methods, apparatuses and a program for capability change indication. In particular, the present invention relates to user equipment (UE) radio capability handling in LTE (long term evolution).

The UE radio capability information element can contain radio capability information related to different radio access technologies (RATs), like e.g. LTE, GERAN (GSM EDGE Radio Access Network), and UTRAN (Universal Terrestrial Radio Access Network). The present invention relates to handling a change of the LTE specific UE radio capability while the UE is in IDLE mode.

Background of the invention

Currently, it has been decided by 3GPP (3^rd Generation Partnership Project) that, in LTE networks, UE radio capabilities will be stored in the mobility management entity (MME) while the UE is in IDLE mode, to reduce the amount of data that needs to be sent via the radio interface at connection setup, and thus to speed up the connection setup time. Therefore, if UE radio capabilities have been changed, while the UE is in IDLE mode, the UE needs to indicate such a change to the network, so that the network does not use a wrong set of UE radio capabilities, but retrieves the new UE radio capabilities from the UE directly.

As it was expected that the LTE-specific UE radio capabilities will not be changed often, it was agreed that the UE should perform a detach and (re-)attach procedure when it needs to change the LTE-specific UE radio capabilities. However, if capabilities for other RATs (e.g, GERAN or UTRAN radio capabilities) have been changed, the UE can indicate this via a TAU procedure (tracking area updating procedure).

Currently, there is a discussion on how the UE can indicate UE radio capability changes if the UE supports different sets of LTE radio capabilities for FDD (frequency division duplex) and TDD (time division duplex) mode. One motivation of having TDD and FDD cells in the same geographical area and supporting mobility between the two types of cells is for the network off-load scenario. For this off-load scenario, a source eNB may e.g. redirect the UE with RRC (radio resource control) Connection Release from the current cell using FDD mode to a cell using TDD mode or vice versa. The UE would then need to indicate to the network its new set of LTE-specific radio capabilities, as according to technical specification TS 36.331, the UE is using the same parameters in the information element to convey its FDD- or TDD-specific UE radio capability information, dependent on the mode of the cell on which it is currently camping.

The difference in the sets of LTE radio capabilities for FDD and TDD mode can be due to the fact that UE vendors may not able to implement and test exactly the same set of features for FDD and TDD, and still features implemented and tested in one mode should be usable in that mode of network.

According to the current 3GPP specification, the UE cannot change the FDD/TDD capabilities while the UE is attached.

The present invention has been made in order to address those issues.

The above mentioned existing solution which is relying on detach/attach is not very efficient. One motivation of having TDD mode and FDD mode cells in the same area and supporting mobility between the two types of cells is for the network off-load scenario. So changes between the two types of modes and thus a change of the LTE-specific UE radio capabilities may occur quite frequently, also within the same tracking area. Under these circumstances, if the UE is performing a detach and re-attach each time when it is redirected, this will increase the network signaling and delay the service availability in an unacceptable way.

Another obvious solution for the problem described above is re-using the TAU to indicate that LTE-specific UE radio capabilities have been changed, as proposed in document [1].

If the UE indicates in the TAU Request message that the UE radio capabilities have been changed, the MME will mark the UE radio capabilities as "invalid" and will not provide them to the eNB when it provides the UE context with the S1AP (SI application part) Initial Context Setup Request message. When eNB receives the UE context but did not receive the UE radio capabilities, the eNB will acquire UE radio capabilities directly from the UE. If the FDD and TDD cell belongs to different tracking areas, then the UE has to initiate a TAU procedure anyway, so for this case the existing mechanism of including a "UE radio capability information update needed" indicator in the TAU Request message can be re^¬ used.

However, this solution also has a drawback because it means that even within a tracking area, if the UE finds both FDD and TDD cells, the UE may need to send a TAU Request each time it re-selects from an FDD to a TDD cell or vice versa just to invalidate the UE capabilities in MME. This may cause a lot of unnecessary network signaling. It is noted that a TAU Request message may have a length of more than 100 octets, and the only relevant information is 1 octet including the information element identifier (IEI) which indicates that a UE radio capability information update is needed.

It is also noted that such a change between FDD and TDD mode could occur quite frequently, whereas a change of the GERAN radio capability is expected to occur much less frequently. Typically, the GERAN radio capability is changed when the "power class" changes, e.g. when the UE is inserted in a device holder in a car. Therefore the solution suitable for GERAN is not necessarily suitable for LTE. 3) Another source of prior art is document [2] relating to 2G/3G GPRS, in particular section 6.13.1.3 "Selective Routing Area Update" of document [2] .

"6.13.1.3 Selective RA Update

The MS shall use the following procedures when in STANDBY or PMM-IDLE state.

Note that upon expiry of the periodic RA update timer, the MS shall carry out the periodic routing area update procedure.

6.13.1.3.1 Uplink Signalling or Data Transmission

In STANDBY or PMM-IDLE state the MS shall not perform an RA update procedure until uplink data or signalling information is to be sent from the MS.

If the MS is in the same mode (A/Gb mode or Iu mode) as when it last sent data or signalling, the procedures defined for that mode shall be followed. This shall be the sending of an LLC PDU in A/Gb mode, or for example sending of a Service Request message in Iu mode.

If the MS is in a different mode (A/Gb mode or Iu mode) as when it last sent data or signalling, the RA update procedure shall be performed before the sending of data or signalling. The RA update procedure needs not be performed if the signalling message is a power-off detach."

So one possible modification of the above described solution, which re-uses the TAU, would be to specify that when the UE enters a new cell using a different mode (FDD or TDD) than the previous cell, the UE does not send the TAU Request with "UE radio capability information update needed" indicator immediately, but only when it actually has to send user data or signaling. This would reduce the number of TAU procedures, because in some cases the UE would change back to a cell using the previous mode, before it has to send anything, but still the message would be unnecessarily long. Prior art documents:

Document [1] :

"Handling of UE Capabilities supporting both TDD&FDD in the Network", Nokia Siemens Networks, Nokia Corporation, R2-115947, 3GPP TSG-RAN WG2 Meeting #76, San Francisco, USA, 14 - 18 November 2011.

Document [2] :

General Packet Radio Service (GPRS), Service description, 3GPP TS 23.060, V10.5.0, September 2011

Summary of the Invention

According to the present invention, there are provided methods, apparatuses and a computer program product for capability change indication.

According to an aspect of the invention there is provided a method, comprising : determining, at a user equipment, whether the user equipment supports different sets of radio capabilities,

determining, at the user equipment, whether the user equipment changes from a first cell using a first mode for which the user equipment reported its radio capabilities last time to a second cell using a second mode, the first mode and the second mode corresponding to different sets of radio capabilities that the user equipment supports,

determining, at the user equipment, if it is determined that the user equipment changes from the first cell using the first mode to the second cell using the second mode, whether the user equipment changes to a connected mode,

inserting, at the user equipment, if it is determined that the user equipment changes to a connected mode, an indicator indicating that an update of the radio capabilities of the user equipment is needed into a Service Request message or an Extended Service Request message, and sending the Service Request message or an Extended Service Request message to a network.

According to further refinements as defined under the above aspect,

- the method further comprises

receiving, at the user equipment, an enquiry about radio capability information of the user equipment, and

sending, by the user equipment, radio capability information of the user equipment to the base station;

- the method further comprises

determining, at the user equipment, whether a mobility management entity supports the indicator in the Service Request message or extended Service Request message, and

if it is determined that the mobility management entity does not support the indicator in the Service Request message or extended Service Request message, inserting the indicator into a Tracking Area Update Request message and sending the Tracking Area Update Request to a network.

According to another aspect of the invention there is provided a method, comprising :

receiving, at a base station, a Service Request message or an Extended Service Request message from a user equipment including an indicator indicating that an update of the radio capabilities of the user equipment is needed,

forwarding, by the base station, the Service Request message or the Extended Service Request message including an indicator indicating that an update of the radio capabilities of the user equipment is needed to a mobility management entity,

determining, upon receiving of a message from the mobility management entity, whether the message contains radio capability information of the user equipment, and

sending, by the base station, if the message does not contain radio capability information of the user equipment, an enquiry about radio capability information of the user equipment to the user equipment. According to further refinements as defined under the above aspect

- the method further comprises

receiving, at the base station, radio capability information from the user equipment, and

forwarding the radio capability information to the mobility management entity.

receiving, at a mobility management entity, a Service Request message or an Extended Service Request message including an indicator indicating that an update of the radio capabilities of a user equipment is needed,

invalidating, at the mobility management entity, information about radio capabilities of a user equipment, from which the Service Request message or an Extended Service Request message originates,

inhibiting, at the mobility management entity, inserting radio capability information into a message to be sent to a base station, and

receiving radio capability information about the user equipment from the base station.

According to further refinements as defined under the above aspect

- the method further comprises

sending, by the mobility management entity, an information element indicating support of the indicator in the Service Request message or extended Service Request message to the user equipment;

- the information element is sent during an attach procedure or tracking area update procedure;

- the information element is inserted into an attach accept message or a tracking area update accept message;

- the Service Request message and the Extended Service Request message are messages conforming to the 3GPP Non-Access Stratum protocol for LTE.

According to another aspect of the invention there is provided user equipment, comprising : a determining unit configured to determine whether the user equipment supports different sets of radio capabilities,

the determining unit being further configured to determine whether the user equipment changes from a first cell using a first mode for which the user equipment reported its radio capabilities last time to a second cell using a second mode, the first mode and the second mode corresponding to different sets of radio capabilities that the user equipment supports,

the determining unit being further configured to determine, if it is determined that the user equipment changes from the first cell using the first mode to the second cell using the second mode, whether the user equipment changes to a connected mode,

an inserting unit configured to insert, if it is determined that the user equipment changes to a connected mode, an indicator indicating that an update of the radio capabilities of the user equipment is needed into a Service Request message or an Extended Service Request message, and

a sender configured to send the Service Request message or an Extended Service Request message to a network.

According to further refinements as defined under the above aspect

- the user equipment further comprises

a receiver configured to receive an enquiry about radio capability information of the user equipment, and

the sender being configured to send radio capability information of the user equipment to the base station;

- the determining unit is further configured to determine whether a mobilty management entity supports the indicator in the Service Request message or extended Service Request message, and

if it is determined that the mobility management entity does not support the indicator in the Service Request message or extended Service Request message, the inserting unit is configured to insert the indicator into a Tracking Area Update Request message,

the sender is further configured to send the Tracking Are Update Request message to a network. - the Service Request message and the Extended Service Request message are messages conforming to the 3GPP Non-Access Stratum protocol for LTE.

According to another aspect of the invention there is provided a base station, comprising :

a receiver configured to receive a Service Request message or an Extended Service Request message from a user equipment including an indicator indicating that an update of the radio capabilities of the user equipment is needed,

a forwarding unit configured to forward, the Service Request message or the Extended Service Request message including an indicator indicating that an update of the radio capabilities of the user equipment is needed to a mobility management entity, and

a determining unit configured to determine, upon receipt of a message from the mobility management entity by the receiver, whether the message contains radio capability information of the user equipment, and

a sender configured to send, if the message does not contain radio capability information of the user equipment, an enquiry about radio capability information of the user equipment to the user equipment.

According to further refinements as defined under the above aspect

- the receiver is configured to receive radio capability information from the user equipment, and

the forwarding unit is configured to forward the radio capability information to the mobility management entity;

- the Service Request message and the Extended Service Request message are messages conforming to 3GPP Non-Access Stratum protocol for LTE.

According to another aspect of the invention there is provided a mobility management entity, comprising :

a receiver configured to receive a Service Request message or an Extended Service Request message including an indicator indicating that an update of the radio capabilities of a user equipment is needed, an invalidating unit configured to invalidate information about radio capabilities of a user equipment, from which the Service Request message or an Extended Service Request message originates,

an inhibiting unit configured to inhibit inserting radio capability information into a message to be sent to a base station, and

a receiver configured to receive radio capability information about the user equipment from the base station.

According to further refinements as defined under the above aspect

- the mobility management entity further comprises

a sender configured to send an information element indicating support of the indicator in the Service Request message or extended Service Request message to the user equipment;

- the information element is inserted into an attach accept message or a tracking area update accept message.

According to another aspect of the present invention there is provided a computer program product comprising code means adapted to produce steps of any of the methods as described above when loaded into the memory of a computer.

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored.

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the program is directly loadable into an internal memory of the processing device.

Brief Description of the Drawings These and other objects, features, details and advantages will become more apparent from the following detailed description of embodiments of the present invention which is to be taken in conjunction with the appended drawings, in which :

Fig. 1 is a signaling diagram showing a message flow for a service request procedure according to an embodiment of the present invention.

Fig. 2 is a flow chart showing a procedure performed by the user equipment according to an embodiment of the present invention.

Fig. 3 is a block diagram showing user equipment according to certain embodiments of the present invention.

Fig. 4 is a flowchart illustrating processing of the user equipment according to certain embodiments of the present invention.

Fig. 5 is a block diagram showing a base station according to certain embodiments of the present invention.

Fig. 6 is a flowchart illustrating processing of the base station according to certain embodiments of the present invention.

Fig. 7 is a block diagram showing a mobility management entity according to certain embodiments of the present invention.

Fig. 8 is a flowchart illustrating processing of the mobility management entity according to certain embodiments of the present invention.

Detailed Description

In the following, embodiments of the present invention are described by referring to general and specific examples of the embodiments. It is to be understood, however, that the description is given by way of example only, and that the described embodiments are by no means to be understood as limiting the present invention thereto.

Generally, it is noted that UE radio capabilities stored in MME are not used in the network while UE is in RRC IDLE mode. Only when UE is in RRC Connected mode, eNB has to have a correct set of UE radio capabilities.

For the TAU based solution, as described above, the UE includes an indicator in the TAU Request to mark the UE radio capabilities in MME as invalid, and in this case, eNB has to retrieve the UE capabilities from UE as MME will not provide UE radio capabilities to eNB during the initial UE context setup.

In contrast to the above, according to an aspect of the present invention, it is proposed, when the LTE-specific UE radio capabilities change while the UE remains within the same tracking area, that the UE includes the "UE radio capability update needed" indication in the Service Request or Extended Service Request message next time it changes to RRC Connected mode. Sending the (Extended) Service Request means that UE wants to set up bearer(s) to receive packet services or to exchange signaling messages with the MME or to initiate a "CS fallback" (circuit switched fallback) to GERAN or UTRAN for a CS call. Thus only for this case, eNB needs to have the correct set of UE radio capabilities.

In order to introduce such a mechanism in a 3GPP network in a backwards compatible way, it is required that the MME supports the new indicator in the Service Request or Extended Service Request message, and that the UE knows whether the MME is supporting the new indicator. That is, an "old" MME not supporting the indicator would just ignore it and forward the stored UE radio capability to the eNB such that the eNB would work with the wrong UE radio capabilities.

The MME can provide the UE with the information about support of the new indicator during the attach procedure and TAU procedure (i.e., when the UE registers with the MME). In the response message Attach Accept or TAU Accept, the MME can include an information element called "EPS network feature support" which informs the UE about support or non-support of the new indicator. This is a well-established mechanism which has already been used in 3GPP TS 24.301 for a number of other features, as described, for example, in subclause 9.9.3.12A for the definition of the EPS network feature support information element, subclause 8.2.1, especially 8.2.1.1 and 8.2.1.10, for the definition of the Attach Accept message, and subclause 8.2.26, especially 8.2.26.1 and 8.2.26.13, for the definition of the TAU Accept message.

If during the attach or TAU procedure the MME does not indicate support of the new indicator, the UE sends a TAU Request with "UE radio capability update needed" indication instead of a Service Request or Extended Service Request. That is, the UE follows the solution relating to the TAU procedure described above and sends the TAU Request only when it has uplink data or signaling to send. The UE sets the "active" flag in the TAU Request to indicate to the network that it has to setup the bearers.

Figure 1 shows an example message flow for the service request procedure. Steps 1 to 4 and 8 to 15 in Fig. 1 are based on subclause 5.3.4.1 of document TS 23.401.

In step 1, the UE sends a non-access stratum (NAS) message Service Request or Extended Service Request (see 3GPP TS 24.301) towards the MME encapsulated in an RRC message to the eNB.

According to an embodiment of the present invention, the message has been modified to include an "UE radio capability update needed" indication.

Upon receipt of the Service Request message or Extended Service Request message including the "UE radio capability update needed" indication in step 2, the MME marks any stored UE radio capability information as invalid.

In step 3, NAS authentication/security procedures may be performed. In step 4, the MME sends a Sl-AP Initial Context Setup Request message to the eNB and provides the eNB with the UE context. Since the UE radio capability information has been marked as invalid after receipt of the Service Request message or Extended Service Request message including the "UE radio capability update needed" indication in step 2, the MME does not include this parameter in the Sl-AP Initial Context Setup Request message.

In step 5, the eNB requests the UE to provide its UE radio capability information, and in step 6, the UE responds thereto with its UE radio capability information.

In step 7, the eNB forwards the UE radio capability information in a Sl-AP message to the MME, where it is stored for future use.

Then, in step 8, the eNodeB performs the radio bearer establishment procedure, and in step 9, the uplink data from the UE is forwarded by eNB to the Serving Gateway (GW) and the PDN (packet data network) GW. In step 10, the eNB sends an Sl-AP message Initial Context Setup Complete to the MME, and in step 11, the MME sends a Modify Bearer Request message per PDN connection to the Serving GW, which is forwarded to the PDN GW in step 12.

In step 13, the PDN GW interacts with the PCRF (policy charging and rules function) to get the PCC (policy and charging control) rule(s) according to the RAT Type by means of a PCEF (policy charging enforcement function) initiated IP-CAN Session Modification procedure. Then, in step 14, a Modify Bearer Response message is sent to the Serving GW and forwarded to the MME in step 15.

In the following, examples for implementing the "UE radio capability update needed" indication according to embodiments of the present invention are described.

According to a first example, the indication is included in a Service Request message. For performance reasons, the Service Request message as defined in TS 24.301 is limited to a length of 4 octets and cannot be made longer. There are only two spare bits left in this message, in the Security Header Type IE. According to the first example, it is proposed that one of these two bits is to be defined to signal the "UE radio capability update needed" indication.

This message is sent by the UE to the network to request the establishment of a NAS signaling connection and of the radio and SI bearers. Its structure does not follow the structure of a standard layer 3 message. According to document TS 24.301, section 8.2.25, the message content is defined in table 1 below (cf. table 8.2.25.1 in section 8.2.25 in TS 24.301).

Message type: SERVICE REQUEST

Significance: dual

Direction: UE to network

Table 1 : SERVICE REQUEST message content

As defined in section, 9.3.1 of TS 24.301, bits 5 to 8 of the first octet of every EPS Mobility Management (EMM) message contain the Security header type IE. This IE includes control information related to the security protection of a NAS message. The total size of the Security header type IE is 4 bits.

The Security header type IE can take the values shown in table 2 below (cf. table 9.3.1 of TS 24.301). Security header type (octet 1 )

8 7 6 s

0 0 0 0 Plain NAS message, not security protected

Security protected NAS message:

0 0 0 1 Integrity protected

0 0 1 0 Integrity protected and ciphered

0 0 1 1 Integrity protected with new EPS security context (NOTE 1 )

0 1 0 0 Integrity protected and ciphered with new EPS security context (NOTE 2)

Non-standard L3 message:

1 1 0 0 Security header for the SERVICE REQUEST message

1 1 0 1 These values are not used in this version of the protocol.

to If received they shall be interpreted as Ί 100'. (NOTE 3)

1 1 1 1

All other values are reserved.

NOTE 1 : This codepoint may be used only for a SECURITY MODE COMMAND

message.

NOTE 2: This codepoint may be used only for a SECURITY MODE COMPLETE

message.

NOTE 3: When bits 7 and 8 are set to '11 ', bits 5 and 6 can be used for future

extensions of the SERVICE REQUEST message.

Table 2 : Security Header Type

According to the present example for implementing the UE radio capability update needed indication, the following amendments are proposed, as shown in table 3 below. Amendments with respect to table 2 are shown in italic.

Security header type (octet 1)

8 7 6 5

0 0 0 0 Plain NAS message, not security protected

Security protected NAS message:

0 0 0 1 Integrity protected

0 0 1 0 Integrity protected and ciphered

0 0 1 1 Integrity protected with new EPS security context (NOTE 1 )

0 1 0 0 Integrity protected and ciphered with new EPS security context (NOTE 2)

Non-standard L3 message:

1 1 0 0 Security header for the SERVICE REQUEST message;

UE radio capability information update not needed

1 1 0 1 Security header for the SERVICE REQUEST message;

UE radio capability information update needed

1 1 1 0 This value is not used in this version of the protocol. If received it shall

be interpreted as '1100'. (NOTE 3)

1 1 1 1 This value is not used in this version of the protocol. If received it shall

be interpreted as '1101 '. (NOTE 3)

All other values are reserved.

NOTE 1 : This codepoint may be used only for a SECURITY MODE COMMAND

message.

NOTE 2: This codepoint may be used only for a SECURITY MODE COMPLETE

message.

NOTE 3: When bits 7 and 8 are set to '11 ', bit 6 can be used for future extensions of

the SERVICE REQUEST message.

Table 3: Proposed Security header type

According to a second example, the indication is included in an Extended Service Request message.

The Extended Service Request message can be used to initiate a CS fallback, but also "to request the establishment of a NAS signaling connection and of the radio and SI bearers for packet services, if the UE needs to provide additional information that cannot be provided via a SERVICE REQUEST message", as defined in section 8.2.15.1 of TS 24.301.

The Extended service request message is sent by the UE to the network

- to initiate a CS fallback or lxCS fallback call or respond to a mobile terminated CS fallback or lxCS fallback request from the network; or

- to request the establishment of a NAS signaling connection and of the radio and SI bearers for packet services, if the UE needs to provide additional information that cannot be provided via a SERVICE REQUEST message. The Extended Service Request message content is shown in table 4 below (cf. table 8.2.15.1 in TS 24.301).

Message type: EXTENDED SERVICE REQUEST

Significance: dual

Direction: UE to network

Table 4: Extended Service Request message content

The message can be extended by the usual extension mechanisms defined for "standard layer 3 messages" in TS 24.301. According to the present example, it is proposed to add an optional type 1 information element to the message.

This information element is already defined in TS 24.301, subclause 9.9.3.35. The UE can include the information element in the TAU Request message (subclause 8.2.29 in TS 24.301), if the UE wants to indicate during the TAU procedure a change of the UE radio capabilities.

According to the second example for implementing the UE radio capability update needed indication, the following amendments are proposed, as shown in table 5 below. Amendments with respect to table 4 are shown in italic.

Table 5 : Modified Extended Service Request message content

Fig. 2 is a flow chart showing a procedure performed by the user equipment according to an embodiment of the present invention

An example according to an embodiment of the present invention, on how to use this indicator to solve the FDD and TDD capability disparity is shown in Fig. 2.

As shown in Fig. 2, in a step S21, it is determined whether the UE supports both FDD and TDD mode. If it is determined in step S21 that the UE does not support both the FDD and TDD mode (NO in step S21), the procedure proceeds further to step S25 where the procedure is ended.

If the determination is positive (YES in step S21), i.e. if it is determined that the UE supports both FDD and TDD mode, the procedure proceeds further to step S22.

In step S22, it is determined whether the UE is camping on a cell with a different mode than the mode of the cell where it reported the UE radio capabilities last time. In case of YES in step S22, it is further determined in step S23, whether the UE makes a Service Request or an Extended Service Request. If this determination is also positive (YES in step S23), the UE indicates in step S24 that an update of its radio capability information is needed by including the radio capability info update needed indication in the Service Request message or the Extended Service Request message, as described above. Then the procedure is ended in step S25.

If any of the determination in step S22 or step S23 is negative (NO in step S22 or step S23), the procedure is ended in step S25.

In Fig. 2, it is noted that the order of step S22 and step S23 can be reversed.

The solution according to embodiments of the present invention is proposed to solve the FDD/TDD capability disparity handling. However, it is noted that the invention is not limited thereto and that the proposed solutions can be used for any UE radio capability modification in the future.

It is an advantage of the present invention, that the signaling load will be reduced.

This will also result in a faster "CS fallback" to GERAN or UTRAN for a CS call, because the UE can omit the TAU procedure before sending the Extended Service Request message.

Further, it reduces the number of TAU procedures due to UE radio capability modification (because change of LTE-specific UE radio capabilities without tracking area change does not require a TAU).

Furthermore, it reduces the amount of data to be sent, because the Service Request / Extended Service Request message is shorter than a TAU Request message. Moreover, it reduces the number of signaling connection request from UE point of view, as the Service Request / Extended Service Request will only be sent when the UE has uplink data or signalling to send.

As shown in Fig. 3, according to an embodiment of the present invention, the user equipment 30 comprises a determining unit 31 configured to determine whether the user equipment supports different sets of radio capabilities. The determining unit 31 is further configured to determine whether the user equipment changes from a first cell using a first mode, for which the user equipment reported its radio capabilities last time, to a second cell using a second mode, the first mode and the second mode corresponding to different sets of radio capabilities that the user equipment supports. The determining unit 31 is further configured to determine, if the user equipment changes from the first cell using the first mode to the second cell using the second mode, whether the user equipment changes to a connected mode.

Further, the user equipment 30 comprises an inserting unit 32 configured to insert, if it is determined that the user equipment changes to a connected mode, an indicator indicating that an update of the radio capabilities of the user equipment is needed into a Service Request message or an Extended Service Request message. Moreover, the user equipment has a sender 33 configured to send the Service Request message or an Extended Service Request message to a network, for example, to an MME via a base station.

According to an embodiment of the present invention, first, in a step S41, the user equipment determines whether the user equipment supports different sets of radio capabilities, and then determines at a step S42, whether the user equipment changes from a first cell using a first mode, for which the user equipment reported its radio capabilities last time, to a second cell using a second mode, the first mode and the second mode corresponding to different sets of radio capabilities that the user equipment supports. Then, in a step S43, the determining unit 31 further determines, if it is determined in step S42, that the user equipment changes from a first cell using a first mode to a second cell using a second mode, whether the user equipment changes to a connected mode.

In a step S44, if it is determined that the user equipment changes to a connected mode, the user equipment inserts an indicator indicating that an update of the radio capabilities of the user equipment is needed into a Service Request message or an Extended Service Request message, and sends the Service Request message or an Extended Service Request message to an MME via a base station in a step S45.

As shown in Fig. 5, according to an embodiment of the present invention, the base station 50 comprises a receiver/sender 51 configured to receive a NAS message, e.g. a Service Request message or an Extended Service Request message, from a user equipment including an indicator indicating that an update of the radio capabilities of the user equipment is needed. The receiver/sender 51 further serves as a forwarding unit configured to forward a NAS message, e.g. the Service Request message or the Extended Service Request message including the indicator indicating that an update of the radio capabilities of the user equipment is needed to a mobility management entity.

The receiver/sender 51 further receives a message from the mobility management entity and a determining unit 52 determines upon receipt of the message whether the message contains radio capability information of the user equipment. Then, if it is determined that the message does not contain radio capability information, the receiver/sender 51 is configured to send an enquiry about radio capability information of the user equipment to the user equipment. Fig. 6 is a flowchart illustrating processing of the base station according to certain embodiments of the present invention.

According to an embodiment of the present invention, first, in a step S61, the base station receives a NAS message, e.g. a Service Request message or an Extended Service Request message, from a user equipment including an indicator indicating that an update of the radio capabilities of the user equipment is needed. Further, in a step S62, the receiver/sender 51 forwards a NAS message, e.g. the Service Request message or the Extended Service Request message including an indicator indicating that an update of the radio capabilities of the user equipment is needed to a mobility management entity.

Then, the receiver/sender 51 receives message from the mobility management entity and determines, whether the message contains radio capability information of the user equipment in step S63.

Then, in a step S64, if it is determined that the message does not contain radio capability information of the user equipment, the base station sends an enquiry about radio capability information of the user equipment to the user equipment.

As shown in Fig. 7, according to an embodiment of the present invention, the mobility management entity 70 comprises a receiver/sender 71 configured to receive a Service Request message or an Extended Service Request message including an indicator indicating that an update of the radio capabilities of a user equipment is needed. The mobility management entity may further comprise a storing unit 72 for storing information about radio capabilities of a user equipment. The mobility management entity further comprises an invalidating unit 73 configured to invalidate information about radio capabilities of a user equipment, from which the Service Request message or an Extended Service Request message originates. Invalidating the radio capabilities means, for example, to mark the radio capabilities stored in the storage unit 72 as invalid. The mobility management entity further comprises an inhibiting unit 74 configured to inhibit inserting the radio capability information into a message to be sent to the base station if it is marked as "invalid" in the storage unit 72. The receiver/sender 71 is then configured to receive radio capability information about the user equipment from the base station. The mobility management entity then stores the received radio capability information in the storing unit 72.

According to an embodiment of the present invention, first, in a step S61, the mobility management entity receives, in a step S81, a Service Request message or an Extended Service Request message including an indicator indicating that an update of the radio capabilities of a user equipment is needed. Then, in a step S82, the mobility management entity invalidates information about radio capabilities of a user equipment, from which the Service Request message or an Extended Service Request message originates. In a step S83, the mobility management entity inhibits inserting radio capability information into a message to be sent to a base station if the radio capability information is marked as "invalid", and then receives, in a step S84, radio capability information about the user equipment from the base station.

In the foregoing exemplary description of the user equipment, the base station and the network entity, only the units that are relevant for understanding the principles of the invention have been described using functional blocks. The user equipment, the base station and the network entity may comprise further units that are necessary for its respective operation. However, a description of these units is omitted in this specification. The arrangement of the functional blocks of the devices is not construed to limit the invention, and the functions may be performed by one block or further split into sub-blocks.

For the purpose of the present invention as described herein above, it should be noted that - method steps likely to be implemented as software code portions and being run using a processor at a user equipment, base station or network entity (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefore), are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the embodiments and its modification in terms of the functionality implemented;

- method steps and/or devices, units or means likely to be implemented as hardware components at the above-defined apparatuses, or any module(s) thereof, (e.g., devices carrying out the functions of the apparatuses according to the embodiments as described above) are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components;

- devices, units or means (e.g. the above-defined base station, or any one of their respective units/means) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved;

- an apparatus like the user equipment, the base station or the network entity may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor; - a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person.

Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code means/portions or embodied in a signal or in a chip, potentially during processing thereof.

It is noted that the embodiments and general and specific examples described above are provided for illustrative purposes only and are in no way intended that the present invention is restricted thereto. Rather, it is the intention that all variations and modifications which fall within the scope of the appended claims are covered.

Claims

1. A method, comprising :

determining, at a user equipment, whether the user equipment supports different sets of radio capabilities,

inserting, at the user equipment, if it is determined that the user equipment changes to a connected mode, an indicator indicating that an update of the radio capabilities of the user equipment is needed into a Service Request message or an Extended Service Request message, and

sending the Service Request message or an Extended Service Request message to a network.

2. The method according to claim 1, further comprising

sending, by the user equipment, radio capability information of the user equipment to the base station.

3. The method according to any one of claims 1 to 2, further comprising

4. A method, comprising :

sending, by the base station, if the message does not contain radio capability information of the user equipment, an enquiry about radio capability information of the user equipment to the user equipment.

5. The method according to claim 4, further comprising

forwarding the radio capability information to the mobility management entity.

6. A method, comprising :

inhibiting, at the mobility management entity, inserting radio capability information into a message to be sent to a base station, and receiving radio capability information about the user equipment from the base station.

7. The method according to claim 6, further comprising

sending, by the mobility management entity, an information element indicating support of the indicator in the Service Request message or extended Service Request message to the user equipment.

8. The method according to claim 7, wherein

the information element is sent during an attach procedure or tracking area update procedure.

9. The method according to claim 8, wherein

the information element is inserted into an attach accept message or a tracking area update accept message.

10. The method according to any one of claims 1 to 9, wherein

the Service Request message and the Extended Service Request message are messages conforming to the 3GPP Non-Access Stratum protocol for LTE.

11. A user equipment, comprising :

a determining unit configured to determine whether the user equipment supports different sets of radio capabilities,

12. The user equipment according to claim 11, further comprising

the sender being configured to send radio capability information of the user equipment to the base station.

13. The user equipment according to any one of claims 11 to 12,

the determining unit being further configured to determine whether a mobilty management entity supports the indicator in the Service Request message or extended Service Request message, and

if it is determined that the mobility management entity does not support the indicator in the Service Request message or extended Service Request message, the inserting unit being configured to insert the indicator into a Tracking Area Update Request message,

the sender being further configured to send the Tracking Are Update Request message to a network.

14. The user equipment according to any one of claims 11 to 13, wherein

15. A base station, comprising :

16. The base station according to claim 15,

the receiver being configured to receive radio capability information from the user equipment, and

the forwarding unit being configured to forward the radio capability information to the mobility management entity.

17. The base station according to any one of claims 15 to 16, wherein

the Service Request message and the Extended Service Request message are messages conforming to 3GPP Non-Access Stratum protocol for LTE.

18. A mobility management entity, comprising :

19. The mobility management entity according to claim 18, further comprising a sender configured to send an information element indicating support of the indicator in the Service Request message or extended Service Request message to the user equipment.

20. The mobility management entity according to claim 19, wherein

21. The mobility management entity according to claim 20, wherein

22. A computer program product including a program for a processing device, comprising software code portions for performing the steps of any one of claims 1 to 10 when the program is run on the processing device.

23. The computer program product according to claim 22, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored.

24. The computer program product according to claim 22, wherein the program is directly loadable into an internal memory of the processing device.