Patent Description:
Cellular communications networks are increasingly being used to support machine to machine (M2M) communication, in which a machine device (MD) communicates with an application server, allowing the server to receive information from the device and to configure the device. Cellular networks may enable such communication between device and application server, regardless of whether or not the server is comprised within the cellular network. It is envisaged that future development of cellular communications networks will include large numbers of such autonomous machine devices, often very small and associated with equipment or apparatus as opposed to a human user. Such devices will typically access the cellular network more or less infrequently, transmitting and receiving very small amounts of data, or being polled for data. In the Third Generation Partnership Project (3GPP) standardisation, machine to machine communication is referred to as Machine Type Communication (MTC), and machine devices are referred to as MTC devices, this being a subset within the larger category of User Equipment devices (UEs). For the purposes of clarity, the following text adopts the 3GPP terminology.

Supporting MTC over a cellular network involves changes to the network architecture, accommodating differences between MTC and user interaction with the network. <FIG> shows a reference network architecture <NUM> used to allow MTC devices to connect to a 3GPP network (UTRAN, E-UTRAN etc). <FIG> is reproduced from <NPL>. Additional shading of elements relating to MTC devices has been introduced to the Figure. Referring to <FIG>, the UE, in this case an MTC device, can be seen to include an MTC UE application <NUM>. The MTC device communicates over the radio access network (RAN) to access application servers via the core network of its home public land mobile network (HPLMN). Within the HPLMN various network entities may be introduced according to the particular model envisaged for MTC traffic. <FIG> illustrates a direct model, in which an application server (AS) <NUM> connects directly to a 3GPP operator network to perform direct communications with the MTC device. <FIG> also illustrates an indirect model, in which an application server (AS) <NUM> connects indirectly to an operator network via a Services Capability Server (SCS) <NUM>. An MTC Inter Working Function (MTC-IWF) <NUM>, acts as an interface enabling interworking of the 3GPP core network and the MTC service capability. A hybrid model may use both direct and indirect models simultaneously. The network architecture may also include an MTC Authentication, Authorisation and Accounting (AAA) function <NUM> within the HPLMN.

The nature of MTC devices and their envisaged use patterns mean that these devices are often required to be highly energy efficient. External power sources for MTC devices will often not be available, meaning the device must operate using energy harvesting or battery power, with frequent replacing or recharging of batteries being neither practical nor economically feasible. Efforts to increase the energy efficiency of MTC devices have generally focused on increasing the efficiency of operation of such devices within cellular networks such as Evolved Packet System (EPS) networks. Many such methods seek to enable and enhance the possibility for MTC devices to spend time in energy efficient low power modes between communication events. One way of achieving this is to extend the maximum possible DRX cycle length in both idle and connected modes for EPS/LTE (Evolved Packet System/Long Term Evolution) networks. Another possibility is to allow the MTC device to detach from the network after each communication event, and reattach when a need arises, for example when the device has uplink data to send or when it wants to poll a server for data or at predefined intervals agreed with the network. This "detach-reattach" method allows the MTC device to enter the "deepest sleep", or most low power state, with a large amount of the electrical circuitry in the device turned off. This deep sleep offers considerable advantages in energy saving. However, the network attach procedure is associated with a significant signalling overhead, and the need to perform such a procedure before each communication event reduces the overall energy efficiency of the detach-reattach method, owing both to the signalling overhead itself and to the time spent in non sleep modes while the attach or detach procedures are carried out.

<CIT> discloses a virtual mobility manager which stores context information for an offline communications terminal (<NUM>) A mobility manager <NUM> tracks a location of a communications terminal <NUM> within a mobile communications network for routing data to or receiving data from the communications terminal <NUM> via a radio network part <NUM> in accordance with context information of the communications terminal <NUM>. The communications terminal <NUM> transmits an indication that it is entering an offline state and, in response, a virtual mobility manager <NUM> stores at least part of the context information of the communications terminal <NUM>. Upon a triggering event occurring <NUM>, <NUM>, the offline communications terminal103 receives a paging message from the virtual mobility manager <NUM> and a communications bearer is established with the mobile communications network for communicating data after the communications terminal <NUM> has moved to an attached state.

It is an aim of the present invention to provide methods and apparatus which obviate or reduce at least one or more of the disadvantages mentioned above.

The scope of the invention is set out in the appended independent claims. Embodiments or examples disclosed herein which do not fall within the scope provide further understanding of the context of the invention.

For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example only, to the following drawings in which:.

The present invention provides methods, a computer program product and apparatus enabling the selective application by a network node of an energy saving process for a user equipment device (UE), according to an instruction received at the network node. The energy saving process comprises retaining a context for the UE after conducting a network detach procedure with the UE. The energy saving process is applied or not for the UE according to an apply instruction or withhold instruction for the UE received at the network node. The energy saving process may in some embodiments further comprise retaining, after conducting a network detach procedure with the user equipment device, at least some network resources reserved for the user equipment device, which resources may for example include bearer contexts.

Aspects of the invention are described below within the context of an EPS/LTE cellular network. However, it will be appreciated that the invention is equally applicable to Universal Mobile Telecommunications System (UMTS), Wideband Code Division Multiple Access (WCDMA), High Speed Packet Access (HSPA) and other cellular network systems.

In order to provide additional context for the present disclosure, a brief discussion of the signalling procedure for network attach and detach processes is given below, with reference to <FIG>, <FIG>, <FIG> and <FIG>.

<FIG> and <FIG> illustrate the message sequence for a network attach procedure in LTE. The attach procedure comprises the following stages:.

It will be appreciated that all Non-Access Stratum (NAS) messages indicated in <FIG> and <FIG> as being sent directly between the UE and the MME are in fact piggybacked as follows:.

Detach of a UE from the network may be initiated by the UE via a Detach Request (NAS) message, for example when the UE is switching off, or by the MME. <FIG> illustrates the message sequence for a UE initiated detach procedure in EPS/LTE, and <FIG> illustrates the message sequence for an MME initiated detach procedure. The MME initiated detach procedure illustrated in <FIG> may be implicit or explicit. An implicit detach procedure is triggered by a timeout, for example following absence of a Tracking Area Update Request NAS message or other contact from a UE for a predetermined period of time. During implicit detach procedures, messages <NUM>, <NUM> and <NUM> illustrated in <FIG> are omitted.

It can be seen from <FIG> and <FIG> that a large part of the signalling in the network attach procedure relates to the establishment of a context for the UE, and to some extent to the handling of remnants of previous contexts for the UE. The energy saving procedure of the present invention significantly reduces the signalling overhead of the attach procedure following a previous network detach, by retaining the UE context following network detach, so that the UE context is available for reuse, and a new UE context need not be established.

A UE context is a block of information associated with a UE attached to the network. The block of information contains the information required to maintain services towards the UE. This may for example include security information, UE capability information and connectivity information.

The possibility of retaining a UE context post detach is considered in <NPL>. This document indicates that an MME may keep for some time the MM context of a detached UE so that this data can be reused at a later attach. Whether or the MME retains contexts in this manner would be dependent upon a particular implementation. This approach, if applied, represents a blanket application of retention of UE context for all UEs, context retention forming part of the standard network detach procedure. The potential for context retention over longer time periods is therefore extremely limited. The time period for context retention is not specified in the standard and would be implementation dependent, but in order to be feasible for a blanket application to all UEs, it would need to be relatively short, targeting for example UEs subject to a detach and immediate reattach procedures. Such blanket application would be completely inappropriate for UEs having potentially very long time intervals between detach and subsequent reattach procedures. MTC devices for example, may connect to a network anywhere from once a minute to once a week or even less frequently. Consistently retaining contexts for all detached UEs over such extended time periods would be inefficient and would place an excessive burden on MME and network resources.

In contrast to the envisaged blanket retention of the 3GPP technical specification, the present invention applies a control mechanism in the form of an instruction received at the relevant network node, for example the MME, to apply or not apply the energy saving process of UE context retention. In this manner, context retention may be specifically targeted to those UEs for which it is appropriate, enabling context retention for much longer periods of time for certain UEs. These may include but are not limited to UEs in the form of MTC devices. Embodiments of the present invention provide further enhancements in the form of configuration of the energy saving process and possible additional energy saving steps. Configuration of the process may include instructing a time period over which the UE context should be retained. Additional steps may include retention of network resources reserved for the UE for example in the SGW and PGW, and where appropriate in MTC specific network entities such as an MTC-IWF and SCS. The configuration and additional steps may provide enhanced variation in how the energy saving process may be applied to individual UEs or categories of UEs. Details of the configuration and additional steps may be received at the network node in the form of configuration data, as discussed in further detail below.

<FIG> is a flow chart illustrating process steps in a method according to an aspect of the present invention. The method is appropriate for conducting in a network node, and in the present illustrative example of an EPS/LTE network, is appropriate for conducting in the MME.

Referring to <FIG>, in a first step <NUM>, the MME receives an instruction concerning an energy saving process for a particular UE. The instruction may be received from the UE itself or from another network node such as for example the Home Subscriber Server (HSS). The sending of the instruction is discussed in further detail below. The instruction may take various different forms depending upon the method by which the instruction is conveyed to the MME. For example the instruction may be in the form of a flag specific to the energy saving process, setting of the flag instructing application of the process and non setting of the flag instructing withholding of the process. Other instruction forms may also be envisaged.

On receipt of the instruction, the MME assesses the type of instruction received at step <NUM>. If the instruction is a withhold instruction, the MME withholds application of the energy saving process for the UE at step <NUM>, performing a normal detach procedure at an appropriate time without applying any steps of the energy saving process. If the instruction received is an apply instruction, the MME applies the energy saving process for the UE at step <NUM>. This may entail checking for configuration data and conducting various steps during and after detach of the UE. The steps involved in applying the energy saving process are discussed in further detail below with reference to <FIG> and <FIG>.

As discussed above, the energy saving process conducted at step <NUM> may be configured for application to suit individual UEs or classes of UEs, including for example specifying a time period for which the UE context for a particular UE should be retained. Configuration of the process may also include specifying additional steps to be included in the process. Details of the configuration, as well as information concerning any additional energy saving steps to be performed, may be received at the MME in the form of configuration data, allowing the MME to configure the energy saving process to the particular UE. This data may be received from the UE itself or from the HSS.

In some examples, the configuration data may comprise a time period over which the UE context is to be retained. This may comprise an explicit indication as to the length of time during which the context should be retained after detach, on expiry of which time period the context may be deleted. In other examples, a context retention time period may be preconfigured into both the MME and the UE. The time period may be included in the subscriber information for the UE, downloaded to the MME from the Home Subscriber Server (HSS) and preloaded onto the Universal Subscriber Identity Module (USIM) of the UE. The time period may alternatively be conveyed to the UE via the system information broadcast in the cell of the UE. In another alternative, a standardised value for the time period may be hardcoded into both the UE and the MME.

In further examples, the context retention time period may be condition based, its expiry being triggered by the first to occur of a series of conditions. Such conditions may for example include:.

According to various examples, the context retention time period may be configured such that occurrence of any one of the above events may trigger its expiry, and hence deletion of the retained UE context.

In further examples, the configuration data comprises information as to whether explicit or implicit detach procedures are to be employed for the UE. If implicit detach is to be used, the configuration data may also include a recommended or required timeout value for the MME to use for triggering the implicit detach.

In still further examples, the configuration data may comprise an indication concerning retention of additional network resources reserved for the UE. The indication may be a recommendation as to whether the additional network resources should be a retained, leaving the option for the MME to comply or not with the recommendation. In other examples, the indication may be an instruction with which the MME is obliged to comply. The resources may include bearer contexts in the SGW and PGW and the MME or contexts/resources in other entities, for example including an MTC-IWF or SCS or other proxy server associated with the UE.

Configuration data received at the MME may comprise some, all or any combination of the above discussed types of information, as appropriate for the particular UE and network operator requirements. Configuration data may be chosen for a particular UE or class of UEs by a network operator according to operational priorities, or UEs may be programmed to select appropriate configuration data for their own operation according to their current functioning and network conditions.

The steps of the above described method may be conducted in a network node, which may in some examples be an MME. <FIG> is a diagram illustrating functional units of a network node suitable for carrying out the above described method, for example in accordance with instructions received from a computer program stored on a computer readable medium. Referring to <FIG>, the node <NUM> comprises a receiving unit <NUM>, configured to receive an instruction concerning an energy saving process for a user equipment device, and an energy saving process unit <NUM>, configured to apply the energy saving process for the user equipment device in accordance with the received instruction. It will be appreciated that the units of the illustrated network node are functional units, and may be realised in any appropriate combination of hardware and/or software. Additional functional units may also be present in the node.

As discussed above, the instruction concerning application or withholding of the energy saving process, as well as possible configuration data, provide control mechanisms allowing for the selective application of the energy saving process for a particular UE, and the possible configuration of that process. The instruction and possible configuration data may be conveyed to the MME in different ways, as discussed in detail below.

According to one embodiment, the instruction and/or configuration data may be conveyed to the MME from the UE during a network attach procedure. During this procedure the UE may indicate to the MME that the energy saving procedure should or should not be applied. This indication may be included in the Attach Request (NAS) message for example in the form of a new Information Element (IE) or as a new value of the EPS attach type IE. The indication may comprise only the instruction to apply or withhold the energy saving process, or the indication may also contain or be accompanied by configuration data as discussed above. In some embodiments, a withhold instruction may comprise an absence of any indication concerning the energy saving procedure. In such embodiments, a UE may be assumed not to support the energy saving process and thus not to anticipate its use.

According to another embodiment, and if an explicit detach procedure is used for the UE, the instruction and/or configuration data may be conveyed to the MME from the UE during a network detach procedure. The UE may indicate in the Detach Request (NAS) message that that the energy saving procedure should or should not be applied. As in the case of the network attach procedure discussed above, a withhold instruction may comprise an absence of any indication concerning the energy saving procedure. As in the above discussed attach signalling, the indication may comprise only the instruction to apply or withhold the energy saving process, or the indication may also contain or be accompanied by configuration data as discussed above. If included with detach signalling, the configuration data would not include an instruction as to the type of detach procedure to be used or a time limit for implicit detach, as the instruction may only be included in detach signalling if explicit detach is used. Where energy saving is paramount, the use of detach signalling may therefore be less desirable than other alternatives for conveying the instruction, which alternatives could allow a UE to use implicit detach, and so avoid the sending of the Detach Request (NAS) message and save the energy associated with sending this message.

According to another embodiment, the instruction and/or configuration data may be associated with a category or capability of the UE, and may therefore be included in any of the lEs in the Attach Request (NAS) message that indicate the various properties of the UE. This may include the UE network capability IE, the MS network capability IE, the Mobile station classmark <NUM> IE or the Device properties IE. In some embodiments, the instruction and optional configuration data may be implicitly associated with UE category, such as a Mobile Station classmark, or a packet of capabilities with a certain label, including for example 'low-energy device'. If several such categories or capability packets are defined, each of them may be associated with a different set of configuration parameters, specifying a particular maximum context retention time period, whether bearer contexts and/or other allocated resources should be retained, whether explicit or implicit detach should be used, suitable timeout for implicit detach, etc..

In further embodiments, the instruction and/or configuration data may be associated with radio capability related parameters and the UE-EUTRA-Capability IE may be extended with the instruction concerning application of the energy saving process and if appropriate with additional configuration data. In the current RRC specification 3GPP <NPL>, the UE-EUTRA-Capability IE is included in the ue-CapabilityRAT-Container IE, which in turn is included in the ue-CapabilityRAT-ContainerList IE in the UECapabilitylnformation message.

During the attach procedure, the eNodeB requests capability information from the UE by sending the RRC message UECapabilityEnquiry to the UE (message <NUM> in <FIG>). The UE responds to the enquiry with the UECapabilitylnformation (RRC) message (message <NUM> in <FIG>), which includes the capability information described above. This message is then forwarded by the eNodeB to the MME. The eNodeB includes the UECapabilitylnformation (RRC) message in a ue-RadioAccessCapabilitylnfo IE, which is then included in a UERadioAccessCapabilitylnformation message (which is specified as an RRC message). The UERadioAccessCapabilitylnformation message is in turn included in a UE Radio Capability IE, which the eNodeB sends to the MME in the UE Capability Info Indication (S1AP) message (message <NUM> in <FIG>). The MME stores the UE capability information in its UE context and keeps it for as long as the UE remains attached to the network. According to aspects of the present invention, the UE context, including the capability information, is retained by the MME post detach as part of the energy saving process. The context including capability information is then available for future reattach or for transfer to a new MME in the case of MME relocation.

When a UE transits from idle to connected mode during an attach session, the MME transfers the UE capability information to the eNodeB in the UE Radio Capability IE in the Initial Context Setup Request (S1AP) message (message <NUM> in <FIG>). The UE Radio Capability IE is optional in the Initial Context Setup Request message and during the Attach procedure it is absent. This absence triggers the eNodeB to request the information from the UE and forward it to the MME, as described above. However, according to aspects of the present invention, when the energy saving process has been applied and a UE later reattaches to the network, the UE capability information will still be stored in the MME as part of the UE context, and the UE Radio Capability IE will not therefore be absent in the Initial Context Setup Request message during the Attach procedure. The eNodeB will not therefore be prompted to request the capability information from the UE.

According to another embodiment, the instruction and/or configuration information may be included with subscriber data associated with the UE. The instruction and/or configuration data are therefore stored as part of the subscriber data in the HSS and in the USIM of the UE. The instruction and/or configuration data is then downloaded from the HSS to the MME together with other subscriber data when the UE registers in the MME.

According to another embodiment, the instruction and/or configuration data may be included in another NAS message. This may for example be a Tracking Area Update Request (NAS) message or any other uplink NAS message, and may for example be a new NAS message specified for this purpose.

Different combinations of the above discussed embodiments may be employed for the delivery of the instruction and configuration data. In one example arrangement, the configuration data containing details of the process and any additional steps to be conducted may be stored in the user subscription information, while the instruction concerning application of the process is received directly from the user equipment device in attach signalling, detach signalling or in a message received during an attach session. If the instruction is sent during attach signalling it may be included in the Attach Request (NAS) message, for instance in the UE network capability IE, the MS network capability IE or as a new value of the EPS attach type IE. According to this arrangement all the information required to apply the process may be preconfigured and received at the MME from the HSS, with the UE only required to instruct the MME to apply or withhold the process.

In some instances, it may be that the UE changes its mind about the application or not of the energy saving process. This may occur for example as a result of events in the UE that are specific to its usage or to applications running on the UE. In such cases, the UE may override a previous instruction sent by the UE or received as a default instruction in UE subscriber data. For example, if the UE has already instructed application of the process in the Attach Request (NAS) message, it may override this with a withhold instruction sent in a Detach Request (NAS) message (when using explicit detach) or in another NAS message, including for example a Tracking Area Update Request (NAS) message or other uplink NAS message. Such an override message may also be sent in the case that instruction and configuration data are received from the HSS in the subscriber data but the UE decides to override this instruction for some reason. This "override" possibility may also be used to change some of the configuration data previously supplied to the MME including for example the time period for UE context retention or details of resources to be retained etc..

It will be appreciated that many of the above embodiments involve the MME receiving the instruction concerning application or withholding of the energy saving process from the UE. Another aspect of the present invention provides a method in a UE involving sending such an instruction to a network node. <FIG> illustrates steps in an example of such a method. According to the method of <FIG>, on occurrence of a trigger at step <NUM>, the UE sends an instruction concerning the energy saving process for the UE to the network node at step <NUM>. The sending of the instruction by the UE may be preceded by different triggers, depending upon when and how the UE sends the instruction. For example in the case of an instruction sent as part of attach signalling, the sending may be triggered by the appropriate preceding step in the attach message sequence. Similarly, in the case of an instruction sent as part of detach signalling, the sending may be triggered by the appropriate preceding step in the detach message sequence or the event that triggered the detach, for example the expiry of a timer. In the case of an override instruction, the sending may be triggered by occurrence of an event changing the operating situation for the UE and so rendering the previously sent or default instruction obsolete.

The method of <FIG> may further comprise sending configuration data concerning the energy saving process to the network node in a step <NUM>. As previously discussed, this configuration data may include a time period for UE context retention, recommendations for retention of network resources or recommendations concerning detach procedures. The instruction and configuration data may be sent using any of the signalling options discussed above, including but not limited to attach signalling, detach signalling, UE capability and or category signalling or uplink (NAS) messages.

The method of <FIG> may further comprise, if the instruction sent is an apply instruction, retaining a UE identifier, which may contain a network node identifier, after performing network detach in step <NUM>. In the present example of an EPS/LTE network, this UE identifier may be a Globally Unique Temporary Identifier (GUTI) which includes a Globally Unique MME Identifier (GUMMEI) and an MME Temporary Mobile Subscriber Identifier (M-TMSI). The UE may then use this GUTI when reattaching to the network. As the GUTI contains the GUMMEI and is an identifier used by the MME, the GUTI will point to the correct MME and the correct UE context within the correct MME and will allow that MME to locate the retained UE context for use with the reattached UE. The UE may be configured to delete its GUTI after the maximum time period for retention of the UE context in the MME, as after this time the GUTI will not serve any useful purpose, the UE context in the MME having been deleted. Deleting the GUTI after this time period will also avoid any potential useless attempts to retrieve the deleted UE context from the old MME by a new MME in the event that the UE has moved to the coverage area of a new MME or MME pool.

If the instruction sent is an apply instruction, the method of <FIG> may also comprise retaining the EPS bearer identity of bearers for which contexts have been retained in the SGW, PGW and MME, if the energy saving process is configured such that these contexts are retained. The UE may retain the EPS bearer identity for each bearer retained in the relevant network nodes and may also retain other bearer related information including Quality of Service parameters. The EPS bearer identity and other bearer related information may be retained for as long as the GUTI is retained. Retention of this information allows matching of the bearer contexts in the SGW, PGW and MME so that for example no EPS bearer identity has to be changed in the bearer contexts in the network.

<FIG> illustrates a functional unit of a UE <NUM> which may perform the above described method for example in accordance with instruction received from a computer program stored on a computer readable medium. The functional unit comprises an energy saving instruction unit <NUM>, configured to instruct a network node concerning an energy saving process for the UE. It will be appreciated that the functional unit <NUM> may be realised in any appropriate combination of hardware and/or software. Additional functional units may also be present in the UE.

<FIG> is a flow chart illustrating one example way in which a network node such as an MME may manage the receipt and application of instructions according to aspects of the present invention. The flow chart of <FIG> illustrates in further detail how the steps of <FIG> may be broken down to achieve the desired functionality.

With reference to <FIG>, in a first step <NUM> the MME receives an instruction concerning an energy saving process for a UE. As discussed above, the instruction may be received from the UE or from another network entity such as the HSS. In step <NUM>, the MME assesses the type of the instruction, i.e. whether the instruction is a withhold instruction or an apply instruction. If the instruction is a withhold instruction, the MME marks the UE at step <NUM> to indicate that the energy saving process should not be applied. The MME then proceeds to check, at step <NUM>, whether or not an override instruction has been received, indicating that the energy saving process should be applied for the UE. If such an instruction has been received (Yes at step <NUM>), the MME proceeds to step <NUM> as discussed below. If an override instruction has not been received (No at step <NUM>), the MME proceeds to check, at step <NUM>, whether or not detach procedure has been initiated (either by the MME itself or by the UE). If detach procedure has not been initiated (No at step <NUM>), the MME continues to check for receipt of an override instruction at step <NUM>. If detach has been initiated (Yes at step <NUM>), the MME proceeds with the detach procedure without applying any steps of the energy saving process, i.e. without retention of the UE context or of any network resources reserved for the UE.

If the instruction received at step <NUM> is an apply instruction, the MME proceeds to step <NUM>, in which the MME checks whether or not configuration data concerning the energy saving process for the UE has been received with the instruction at step <NUM>. If such configuration data has been received (Yes at step <NUM>), the MME proceeds to mark the UE to indicate that the energy saving procedure should be applied in step <NUM>. If such configuration data has not been received with the instruction at step <NUM> (No at step <NUM>), the MME proceeds to retrieve this data at step <NUM>. This may for example involve retrieving configuration data including instructions about the correct detach procedure (explicit or implicit with suitable time limit). Retrieving configuration data in step <NUM> may involve retrieving preconfigured default configuration data from an internal memory in the MME or from subscriber data held in the HSS and conveyed to the MME. Following retrieval of configuration data at step <NUM> the MME proceeds to mark the UE as subject to application of the energy saving process in step <NUM>. After marking the UE to indicate that the energy saving procedure should be applied in step <NUM>, irrespective of whether the MME arrived at this step directly following the Yes branch from step <NUM> or indirectly following the No branch from step <NUM> via step <NUM>, the MME then checks at step <NUM> whether or not an override instruction has been received, indicating that the energy saving procedure should not be applied for the UE. If such an instruction has been received (Yes at step <NUM>), the MME proceeds to step <NUM> and follows the subsequent process as described above. If no override instruction has been received, the MME then checks at step <NUM> whether or not detach procedure with the UE has been initiated, either by the UE or by the MME. If detach procedure has not been initiated (No at step <NUM>), the MME continues to check for receipt of an override instruction at step <NUM>. If detach procedure has been initiated (Yes at step <NUM>), the MME proceeds to step <NUM>, performing the detach procedure with application of the energy saving process as configured by the configuration data, either received with the instruction in step <NUM> or retrieved in step <NUM>. Details of what this may involve are discussed further below with reference to <FIG>.

Following detach of the UE at step <NUM>, the MME starts a timer at step <NUM> and checks for expiration of the time limit for UE context retention at step <NUM>. The time limit may be preconfigured in the MME or may have been received or retrieved with the configuration data. The time limit may be an explicit limit or may be condition based, as discussed above. On expiration of the time limit (Yes at step <NUM>), the MME proceeds to delete the UE context at step <NUM>. If the UE attempts to reattach before expiry of the time limit, the stored UE context, as well as other network resources if retained, will be available to reduce the signalling required for the reattach procedure.

<FIG> illustrates in further detail steps that may be comprised within the step <NUM> of performing the detach procedure with application of the energy saving process as configured by the configuration data. Depending upon the nature of the configuration data, step <NUM> may involve:.

<FIG> illustrates the signalling flow in a streamlined attach procedure that may be followed on reattach of a UE whose context has been retained by the MME in accordance with aspects of the present invention. When compared with the standard procedure illustrated in <FIG> and <FIG> it can be seen that a significant portion of the messages in the attach procedure have been eliminated, greatly reducing the signalling overhead of the procedure. By retaining the UE context in the MME, and if instructed also retaining bearer contexts in the SGW and PGW, message exchanges associated with the Attach and Authentication and Default Radio Bearer Setup stages of the standard attach process may be eliminated. Thus reduction in signalling reduces the energy associated with the process both through the reduction in number of messages to be transmitted and in the reduction in the amount of time during which the UE must be in a non sleep state.

By reducing the energy cost of an attach procedure, aspects of the present invention increase the efficiency of the detach-reattach method of energy saving. In allowing for the targeted application of UE context retention, much longer context retention may be supported for particular UEs or classes of UEs, enabling the reduced attach procedure of <FIG> to be performed before communication events. This streamlined attach procedure improves the efficiency of the detach-reattach method. In addition, this method may become energy efficient even for devices having shorter time periods between communication events. The reduced signalling overhead on reattach moves the breakeven point for detach-reattach in terms of the length of time a device must spend in deepest sleep in order to compensate in terms of energy requirements for the need to perform network reattach before each communication event. While such benefits may be particularly applicable to MTC devices, the present invention is not limited to such devices, being applicable to all forms of User Equipment. Similarly, while the invention has been described with reference to operation in an EPS/LTE network, the invention is equally applicable to other cellular network systems including UMTS, WCDMA and HSPA.

The methods of the present invention may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present invention also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer-readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, which is defined by the appended claims.

Claim 1:
A method performed by a network node for supporting an energy saving process in a user equipment, UE, the method comprising:
receiving (<NUM>) from the UE, during an attach procedure in which the UE registers with a core network, an instruction to apply an energy saving process, comprising indicating that an implicit detach is to be employed for the UE when a detach procedure is initiated by the network node;
initiating the implicit detach procedure based on the received request; and
retaining, a context of the UE for a period of time after initiating the detach procedure.