Description Title

High latency communication

Field of the Invention The present invention relates to an apparatus, a method and a computer program product for performing a high latency communication.

Related background Art

The following meanings for the abbreviations used in this specification apply:

3GPP 3rd generation partnership project

AS Application server

CN Core network

CS Circuit switched DRX Discontinuous transmission

DT Device trigger

GPRS General packet radio service

GW Gateway

HSS Home subscriber server IMS IP multimedia subsystem loT Internet of things

IP Internet protocol

ISR Idle mode signaling reduction

IWF Interworking function LTE Long term evolution M2M Machine-to-machine

Mobility management entity

MTC Machine type communications

NAS Non-access stratum

Packet data network gateway

PLMN Public land mobile network

PSM Power saving mode

RAU Routing area update

SCS Services capability server

SGSN Serving GPRS support node

S-CSCF Serving call server control function

SMS Short message service

TAU Tracking area update

TR Technical report

Technical specification

User data repository User equipment

3GPP has started a new Rel-13 stage 2 study item Optimizations to Support High Latency Communications". The following text is an excerpt from the 3GPP work item description:

Due to potential high latency (e.g. power saving mode is used) when accessing 3GPP constrained devices using the 3GPP access, communicating with very large number of constrained devices may cause high packet losses, and large system load on the 3GPP system. Examples of constrained devices are sensors, meters and actuators that have specific low-cost, low-energy and low-bitrate requirements.

The Internet-of-Things (loT) is a concept where many things (e.g., devices) can be uniquely identified and communicated with. One study forecasted that the number of devices representing the loT will grow to 26 Billion units by 2020. Many of these devices will be constrained in terms of low-cost, low-energy and low-bitrate. The very large number makes it especially important that the 3GPP access is efficient when accessing these constrained devices. In this context, the term 3GPP Constrained device is used and means UEs using UE battery saving techniques, UE sleep functions making UEs unreachable for long periods of time, UEs using low throughput bearers, etc, hence resulting in e.g. high latency for accessing the devices from network side.

The objective of this study item is to study possible enhancements that facilitate for applications to use 3GPP constrained devices over the 3GPP IP connectivity and being able to support large number of devices in the system without negatively affecting the system performance.

In addressing the above, the following problem will be studied: - Downlink access for 3GPP constrained devices and the problems associated with such devices (e.g. packet discard when the UE sleeps, frequent retransmissions, load on the CN network, waste of radio resources and UE power when the network unnecessarily conveys retransmit packets, etc). This study may propose and evaluate enhancements to the 3GPP system. Depending on conclusions, the study may also propose 3GPP enablers to be used by the service layer e.g. defined by other SDOs for downlink access to constrained devices. It is noted that different application layer protocols used within the M2M ecosystem have different requirements and characteristics with respect to acceptable end-to-end delay, round trip time, persistence in retransmissions, etc. The result of this study may include general recommendations for application layers how to use the 3GPP accesses for better application performance and optimal core and radio network efficiency thereof. 3GPP has already defined an architecture model and concepts for communications with packet data networks and applications to which the new study item is related. In the following, excerpts from the 3GPP TS 23.682 (V12.2.9 (2014-06)) are summarized:

First, the general concept is described. Regarding MTC, a part of the MTC application is located in the UE, whereas another part thereof is located in an external network. The end-to-end communications between the MTC Application in the UE and the MTC Application in the external network use services provided by the 3GPP system, and optionally services provided by a Services Capability Server (SCS).

The MTC Application in the external network is typically hosted by an Application Server (AS) and may make use of an SCS for additional value added services. The 3GPP system provides transport, subscriber management and other communication services including various architectural enhancements motivated by, but not restricted to, MTC (e.g. control plane device triggering).

Different models are foreseen for machine type of traffic in what relates to the communication between the AS and the 3GPP system and based on the provider of the SCS. The different architectural models that are supported by the Architectural Reference Model described in the following by referring to Fig. 3 include the following:

Direct Model: The AS connects directly to the operator network in order to perform direct user plane communications with the UE without the use of any external SCS. The Application in the external network may make use of services offered by the 3GPP system;

Indirect Model: The AS connects indirectly to the operator network through the services of a SCS in order to utilize additional value added services for MTC (e.g. control plane device triggering). The SCS is either MTC Service Provider controlled, wherein the SCS is an entity that may include value added services for MTC, performing user plane and/or control plane communication with the UE. Tsp is regarded as an inter-domain interface for control plane communication; or is 3GPP network operator controlled, wherein the SCS is a mobile operator entity that may include value added services for MTC and performs user plane and/or control plane communication with the UE, making Tsp a control plane interface internal to the PLMN;

Hybrid Model: The AS uses the direct model and indirect model simultaneously in order to connect directly to the operator's network to perform direct user plane communications with the UE while also using a SCS. From the 3GPP network perspective, the direct user plane communication from the AS and any value added control plane related communications from the SCS are independent and have no correlation to each other even though they may be servicing the same MTC Application hosted by the AS.

When using the hybrid model, the MTC Service provider controlled SCS, and the 3GPP operator controlled SCS may offer different capabilities to the MTC Applications.

Since the different models are not mutually exclusive, but just complementary, it is possible for a 3GPP operator to combine them for different applications. This may include a combination of both MTC Service Provider and 3GPP network operator controlled SCSs communicating with the same PLMN.

Fig. 3, which reproduces Fig. 4.2-1 of 3GPP TS 23.682, shows the architecture for a UE used for MTC connecting to the 3GPP network (UTRAN, E-UTRAN, GERAN, etc.) via the Um/Uu/LTE-Uu interfaces. The architecture covers the various architectural models described above.

Annex D of 3GPP TS 23.682 further illustrates device triggering using direct model over user plane. This is described in the following by referring to Fig. 4, which reproduces Fig.

D-1 of 3GPP TS 23.682 and shows an example flow of device triggering using direct model over user plane. In this example, an application in the UE explicitly registers with a DT-AS/SCS (Device Trigger Application Server) in the home operator's network using an existing PDN connection (e.g., default PDN connection). The DT-AS uses the information from the application registration (such as IP address, port, protocol, etc.) to deliver the incoming device triggers, forwarded by another AS (e.g., third party AS) or itself, to the UE through the user plane. Once the UE receives the trigger, the UE either uses the existing PDN connection or the UE sets up a new PDN connection to the appropriate APN to contact the third-party Application Server.

In particular, the following procedures are carried out:

1 . The UE/MTC application registers with the DT-AS in an operator's network using an existing PDN connection (for e.g., default PDN). The registration information, for example, could include the IPv4/IPv6 address and the port number where the application is reachable. 2. The DT-AS receives a trigger from a third-party AS to reach the UE.

3. The DT-AS delivers the trigger to the UE over the user plane.

4. The UE either uses the existing PDN connection or sets up a new PDN connection using the appropriate APN to contact the third-party AS.

In the following, high level functions as defined under subclause 4.5 of 3GPP TS 23.682 are summarized.

First, a device triggering function is described. Device triggering is the means by which a SCS sends information to the UE via the 3GPP network to trigger the UE to perform application specific actions that include initiating communication with the SCS for the indirect model or an AS in the network for the hybrid model. Device Triggering is required when an IP address for the UE is not available or reachable by the SCS/AS.

Device trigger message contains information that allows the network to route the message to the appropriate UE and the UE to route the message to the appropriate application. The information destined to the application, along with the information to route it, is referred to as the Trigger payload. The UE needs to be able to distinguish an MT message carrying device triggering information from any other type of messages. It is noted that the Trigger payload, for example, upon the reception by the UE possibly provides information to the application that may trigger application related actions. The application in the UE may perform indicated actions, such as for example to initiate immediate or later communication to the SCS/AS, based on the information contained in the Trigger payload.

Device Triggering is subscription based. The subscription provides the information whether a UE is allowed to be triggered by a specific SCS. When device triggers are delivered via MT-SMS, the serving nodes MME, SGSN and MSC provide the service towards a specific UE based on the UE's subscription for MT-SMS and other subscription parameters affecting MT-SMS service provision.

Device triggering recall/replace functionality allows a SCS to recall or replace previously submitted trigger messages which are not yet delivered to the UE.

Charging data are collected for the device triggering. The MTC-IWF generates CDRs for the service requester. When device triggers are delivered via MT-SMS, then network entities, like MME, SGSN, MSC or SMS-SC, generate CDRs for SMS services provided for the mobile subscriber.

A further high level function is PS-only Service Provision. PS-only service provision is providing a UE with all subscribed services via PS domain. PS-only service provision implies a subscription that allows only for services exclusively provided by the PS domain, i.e. packet bearer services and SMS services. The support of SMS services via PS domain NAS is a network deployment option and may also depend on roaming agreements. Therefore, a subscription intended for PS-only service provision may also allow for SMS services via CS domain to provide a UE with SMS services in situations when serving node or network do not support SMS via PS domain NAS. Another high level function is Core Network assisted RAN parameters tuning. Core Network assisted RAN parameters tuning aids the RAN in optimizing the setting of RAN parameters.

A further high level function is a UE Power Saving Mode. A UE may adopt the PSM for reducing its power consumption. That mode is similar to power-off, but the UE remains registered with the network and there is no need to re-attach or re-establish PDN connections. A UE in PSM is not immediately reachable for mobile terminating services. A UE using PSM is available for mobile terminating services only for the period of an Active Time after a mobile originated event like data transfer or signalling, e.g. after a periodic TAU/RAU procedure. PSM is therefore intended for UEs that are expecting only infrequent mobile originating and terminating services and that can accept a corresponding latency in the mobile terminating communication.

PSM has no support in the CS domain on the network side. PSM should only be used by UEs using the PS domain, SMS and mobile originated IMS or CS services. A UE that uses mobile terminated IMS or CS services other than SMS should not use PSM as neither IMS nor the CS domain provide support for mobile terminated CS voice or IMS services to UEs that are in PSM.

Applications that want to use the PSM need to consider specific handling of mobile terminating services or data transfers. A network side application may send an SMS or a device trigger to trigger an application on UE to initiate communication with the SCS/AS. Alternatively, if an SCS/AS has periodic downlink data, it is more efficient when the UE initiates communication with the SCS/AS to poll for downlink data with that period. For either of the options to work, the UE should request an Active Time that is long enough to allow for potential mobile terminated service or data delivery, e.g. to deliver an SMS.

When the UE wants to use the PSM it shall request an Active Time value during every Attach and TAU/RAU procedures. If the network supports PSM and accepts that the UE uses PSM, the network confirms usage of PSM by allocating an Active Time value to the UE. The network takes the UE requested value and any local MME/SGSN configuration into account for determining the Active Time value that is allocated to the UE. If the UE wants to change the Active Time value, e.g. when not content with the value provided in the Attach or TAU/RAU Accept, the UE requests the value it wants in the TAU/RAU procedure.

It is noted that a minimum recommended length for the Active Time is the time allowing for the 'msg waiting flag' in the MME/SGSN to trigger the SMSC via the HSS to deliver an SMS to the MME/SGSN, e.g. 2 DRX cycles plus 10 seconds.

The UE is in PSM until a mobile originated event (e.g. periodic RAU/TAU, mobile originated data or detach) requires the UE to initiate any procedure towards the network. In Attach and RAU/TAU procedures a PSM capable UE may request a periodic TAU/RAU Timer value suitable for the latency/responsiveness of the mobile terminated services. If the UE wants to change the periodic TAU/RAU Timer value, e.g. when not content with the value provided in the Attach or TAU/RAU Accept, the UE requests the value it wants in the TAU/RAU procedure.

Furthermore it is noted that, if the UE or application performs any periodic uplink data transfer with a periodicity similar to the Periodic TAU/RAU Timer value, it preferably requests a Periodic TAU/RAU Timer value that is at least slightly larger than the data transfer period to avoid periodic TAU/RAU procedures that would increase power consumption.

Any timers and conditions that remain valid during power-off, e.g. NAS-level back-off timers, apply in the same way during PSM. The UE may leave the PSM any time, e.g. for mobile originated communications.

If the network confirms the usage of PSM to a UE, the network shall not activate the ISR for such UE. Thus, in the current solution described in TS 23.682 the UE periodically wakes up from the sleep / power saving mode and stays awake long enough to be able to receive a possibly waiting message from the network. After handling possible incoming messages the UE goes back to sleep.

This may lead to unnecessary operation time for the UE and/or a high number of message transmitting attempts and/or packet losses between the UE the AS, which might lead to a high load on a network.

Summary of the Invention

Embodiments of the present invention address this situation and aim to overcome the above-described problem and to provide an improved communication with UEs which are able to enter power saving mode or sleep mode.

According to a first aspect of the present invention an apparatus is provided which comprises a processor and a memory for storing instructions to be executed by the processor, wherein the processor is configured to determine condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device by setting one or more wake-up behaviours and/or condition related accessibility based on one or more conditions, and to send the condition information to the terminal device.

According to a second aspect of the present invention a method is provided which comprises determining condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device by setting one or more wake-up behaviours and/or condition related accessibility based on one or more conditions, and sending the condition information to the terminal device. The first aspect and the second aspect may be modified as follows:

The at least one condition may comprise a time-related condition and/or an application- related condition, wherein the application-related condition may be a condition which relates to an application running on the terminal device.

It may be communicated with the terminal device based on the condition information.

The condition information may be updated and the updated condition information may be sent to the terminal device during the communication with the terminal device.

The condition information may be determined for a plurality of terminal devices by staggering the conditions for the terminal devices.

The determination may be performed when the terminal device registers with the apparatus (the apparatus on which the method is carried out).

Information may be requested from at least one network entity for determining the condition information.

It may be detected independently from the terminal device whether the one or more conditions is fulfilled, and communication with the terminal device may be performed based on this detection.

A condition synchronization check with the terminal device may be performed by checking whether the same conditions are provided for the apparatus and the terminal device. It may be indicated in a communication with the terminal device that a certain message is a last message.

The condition information may be sent to an application server related to an application running on the terminal device.

The apparatus may be or may be part of an application server or device trigger application server related to an application running on the terminal device, i.e., the method according to the second aspect may be carried out by such an application server or device trigger application server.

According to a third aspect of the present invention an apparatus is provided which comprises a processor and a memory for storing instructions to be executed by the processor, wherein the processor is configured to receive condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device in which one or more wake-up behaviours and/or condition related accessibility are set based on one or more conditions, to send the condition information to the terminal device, and to communicate with the terminal device based on the condition information.

According to a fourth aspect of the present invention a method is provided which comprises receiving condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device in which one or more wake-up behaviours and/or condition related accessibility are set based on one or more conditions, sending the condition information to the terminal device, and communicating with the terminal device based on the condition information. The third and fourth aspects may be modified similar as the first and second aspects.

According to a fifth aspect of the present invention an apparatus is provided which comprises a communication unit, configured to communicate with a network, a processor and a memory for storing instructions to be executed by the processor, wherein the processor is configured to receive condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility in which one or more wake-up behaviours and/or related accessibility are set based on one or more conditions, and to activate and deactivate at least the communication unit of the apparatus based on the received condition information.

According to a sixth aspect of the present invention a method is provided which comprises receiving condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility in which one or more wake-up behaviours and/or related accessibility are set based on one or more conditions, and to activate and deactivate at least a communication unit which is configured to communicate with a network based on the received condition information.

The fifth and sixth aspects may be modified as follows:

The at least one condition comprises a time-related condition and/or an application-related condition, wherein the application-related condition is a condition which relates to an application running on the apparatus.

It may be communicated with an application server or a device trigger application server related to an application running on the apparatus based on the condition information. Updated condition information may be received during the communication with the application server or device trigger application server.

It may be detected independently from the application server or device triggering application server whether the one or more conditions is fulfilled, and communication with the application server or device triggering application server may be performed based on this detection.

A condition synchronization check with the application server or device triggering application server may be performed by checking whether the same conditions are provided for the apparatus (the apparatus on which the method is carried out) and the application server or device triggering application server.

A message may be received from the application server or device triggering application server indicating that this message is a last message, and the communication unit may be deactivated when such a message is received.

According to a seventh aspect, a computer program product is provided which comprises code means for performing a method according to the second, fourth or sixth aspects and/or their modifications when run on a processing means or module. The computer program product may be embodied on a computer-readable medium.

Brief Description of the Drawings

These and other objects, features, details and advantages will become more fully 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 shows a simplified overview of an application server (AS) and user equipment (UE) according to an embodiment of the present invention,

Fig. 2 illustrates a signaling scenario according to an embodiment of the present invention, Fig. 3 shows the 3GPP architecture for machine-type communication (MTC) according to 3GPP TS 23.682, and

Fig. 4 illustrates a triggering flow using direct model over user plane according to 3GPP TS 23.682.

Detailed Description of embodiments

In the following, description will be made to embodiments of the present invention. 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.

As described above, in the current solution described in TS 23.682 the UE periodically wakes up from the sleep / power saving mode and stays awake long enough to be able to receive a possibly waiting message from the network. After handling possible incoming messages the UE goes back to sleep.

Hence, in particular in case a high number of UEs are present in a network, this could lead to a very high load of messages, and in particular a high number of unsuccessful messages (when the UE is in power saving mode) could be caused.

Embodiments of the present invention overcome this problem.

In particular, according to some embodiments, a network entity such as an application server / device trigger application server (AS, DT-AS) determines condition related wake- up behaviour or UE accessibility.

This is described in the following by referring to Fig. 1 which illustrates a simplified block diagram of an AS (or DT-AS) 1 as an example for a network entity which determines condition information including one or more condition related wake-up behaviour and/or condition related accessibility for a terminal device and a UE 2 as an example for a terminal device (or a MTC device, MTC-UE) according to a general embodiment of the present invention.

The AS/DT-AS 1 comprises a processor 1 1 and a memory 12 for storing instructions to be executed by the processor. In addition, a communication unit 13 may be provided, by which a connection to a network is provided.

The processor 1 1 is configured to determine condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device by setting one or more wake-up behaviours and/or condition related accessibility based on one or more conditions, and to send the condition information to the terminal device (e.g., UE 2).

According to an alternative embodiment, the determination as described above may be performed by another network entity. In this case, the processor 1 1 is configured to receive condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device in which one or more wake-up behaviours and/or condition related accessibility are set based on one or more conditions, to send the condition information to the terminal device, and to communicate with the terminal device based on the condition information (e.g., UE 2).

The UE 2 comprises a processor 21 , a memory 22 for storing instructions to be executed by the processor and a communication unit 23 by which a connection to a network is provided.

The processor 21 is configured to receive condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility in which one or more wake-up behaviours and/or related accessibility are set based on one or more conditions, and to activate and deactivate at least the communication unit of the apparatus based on the received condition information.

It is noted that deactivation of the communication unit as described above may be part of entering a power saving or sleep mode of the terminal device.

In this way, according to embodiments of the present invention, condition information are generated which indicate under which condition(s) the terminal device will wake up from a sleep mode and the terminal device will be accessible.

Hence, according to embodiments of the present invention communications between UEs and the network are synchronized, so that system overload through useless re-sendings and packet loss can be avoided and the reachability of UEs is improved.

It is noted that the condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility is also referred to as accessibility related parameter(s) in the following..

In the following, a more detailed embodiment of the present invention is described.

According to this embodiment, when a UE/MTC registers with an application server / device trigger application server (AS, DT-AS), the AS/DT-AS determines condition related wake-up periods / cycles / points of time for the application running on the UE, or more generally condition related wake-up behaviour or UE accessibility. Different conditions / condition sets may relate to different wake-up behaviours / accessibility, i.e. there may be one or more condition(s) vs. wake-up behaviour pairs for an application / UE. The AS/DT- AS sends the condition(s) vs. wake-up behaviour pair(s) to the UE/application. When given conditions are met while the UE is asleep, the UE/application applies the wake-up behaviour defined for the conditions and sends a message to the AS/DT-AS. The purpose of the message may be twofold:

- To check whether the AS/DT-AS has a message for the UE/application (as per current specifications).

To send parameters (e.g. results of measurements performed by the application, e.g. a detector or sensor) to the AS/DT-AS.

The reply message from the AS/DT-AS may contain an update of the condition(s) vs. wake-up behaviour pair(s) for the application / UE.

As an example, the condition vs. wake-up behaviour pair may be purely time-related, e.g. a certain wake-up period or cycle or timing pattern is followed during given periods of (daily, weekly, monthly or yearly etc.) time. This will effectively prevent the AS/DT-AS application from trying to send messages to a UE that is asleep or in power saving mode, or from sending messages to a queue or cache in the network for an undefined period which may exceed the maximum delay tolerable by the application.

As a further measure, the AS/DT-AS may stagger the conditions, typically or as an example, the wake-up periods / cycles / points of time, of different UEs or applications or application instances or of different groups of UEs or applications or application instances. This will help avoid system overloading and/or loss of packets through sudden simultaneous message bursts from different UEs towards the AS(s)/DT-AS(s).

The AS/DT-AS may use different information and/or information from different sources for determining the wake-up behaviour for a UE. The information may be e.g. application related information received from the UE or from the HSS/UDR or from an external AS or being configured in the AS/DT-AS, or subscription parameters received from the HSS/UDR or being configured in the AS/DT-AS. Some examples of possible conditions:

Point of time ("act after/upon this point of time")

Time window ("act within this time window") - Application related events (e.g. a sensor detects a value above or below a certain threshold and needs to send a report to the application server)

A time related condition and application related condition together ("act when both/all conditions are met")

Fig. 2 describes the principles of the suggested solution in form of a signalling scenario with several optional flavours or variations (with dash lines in the figure) and using the direct model of TS 23.682 / Annex D shown in Fig. 4. The signaling involves entities such as the UE, DT-AS / SCS / MTC-IWF, HSS / UDR and AS according to the architecture shown in Fig. 3

First, the basic signaling according to the present embodiment is described.

In step S1 , the UE registers with the DT-AS (or SCS or MTC-IWF). The registration request contains the IP address of the UE and UE and/or application parameters. In step S6, the DT-AS uses the received information (i.e., the UE/application parameters of the registration request) and other information such as configuration information for determining accessibility related parameters for the UE (i.e., condition related wake-up behaviour or UE accessibility as described above). In step S7, the DT-AS sends a response including the accessibility related parameters to the UE. Meanwhile, the DT-AS may adapt forthcoming triggering actions to the UE based on the accessibility related parameters (step S9A). That is, the DT-AS or AS will trigger the UE in line with the accessibility related parameters.

In this way, the U E / application can heed the received accessibility related parameters. Hence, in accordance with the accessibility related parameters, the UE can enter the sleep mode (step S1 1 ).

Step S1 2 illustrates a situation in which a trigger wakes up the UE to contact the AS. The UE heeds the accessibility related parameters in creating and sending a message to the AS. For example, when the application concerns monitoring of sensor values, the UE may send a sensor value when this sensor value exceeds a certain threshold (which is an example for the condition described above).

Thus, in step S1 3 the U E sends a message including parameters (e.g., measurement results or the like) to the DT-AS. In step S1 6, the DT-AS sends a response to this message, wherein the response may also include condition related wake-up behavior update and/or condition related accessibility update and/or application related parameters or the like.

As indicated by the dash lines, several modifications of the flow shown in Fig. 2 are possible.

For example, in step S6, the DT-AS may also refer to subscription parameters and/or further application parameters for determining the accessibility related parameters. In case of subscription parameters, the DT-AS sends a corresponding request, which may include corresponding parameters, to the HSS or UDR in step S2, which sends a response including the subscription parameters in turn in step S3. In case of application parameters, the DT-AS sends a corresponding request, which may include corresponding parameters, to the AS in step S4, which sends a response including the subscription parameters in turn in step S5.

As a further modification, after having determined the accessibility related parameters in step S6, the DT-AS sends the accessibility related parameters to the AS in step S8. In this way, the AS itself is able to adapt forthcoming triggering actions to the UE based on the accessibility related parameters (step S9B). In step S10 the AS sends a response to the DT-AS in order to confirm the adaptation in step S9B.

In step S14, the DT-AS may forward the message from the UE received in S13 to the AS. The AS may then send in step S15 a response to the DT-AS including parameters, which may be used in the response to the UE in step S16.

As a further variation, the accessibility related parameters (wake-up behaviour / accessibility conditions and parameters) may be determined by a third network entity and delivered to the UE/application and AS. In the signalling scenario in Fig. 2 the DT-AS/SCS / MTC-IWF corresponds to the third network entity in this respect and step 8 corresponds to the delivery of the parameters to the AS.

As a further variation, especially time related conditions may be applied (to not just for the UE waking up to check whether the AS/DT-AS has messages to send to the UE, but) to a UE/application originated communication, too. That may be for example, if the UE has got a reason to send a report to the AS/DT-AS, the UE shall use the time related conditions, e.g. one of certain windows or periods of time, to send the report to the AS/DT-AS. This will alleviate possible message flush in an environment where a multitude of similar applications get simultaneously triggered to send a message or report to the AS/DT-AS.

As a further variation/embodiment, especially regarding time related conditions, e.g. a window of absolute/universal time may be applied both by the UE and by the AS/DT-AS without any message sending by the UE to the AS/DT-AS to indicate that the UE is awake and ready to receive a possibly waiting message from the AS/DT-AS. In other words, both the UE and AS/DT-AS detect independently of each other that a condition is met or conditions are met, and consequently, the UE wakes up and the AS/DT-AS prepares to send a possibly waiting message, or messages, to the UE.

This variation/embodiment may further support, as a further variation, a condition synchronization check between the UE and the AS/DT-AS (i.e. to check for example that both entities still have/apply the same universal time windows) e.g. through the UE sending a check message to the AS/DT-AS e.g. during every Nth wake-up period.

This variation/embodiment may further support, as a further variation, an indication in the last message from the AS/DT-AS to the UE about the message being the last one so that the UE may go back to the power saving / sleep mode after handling the message.

These further variations/embodiments have the advantage of further minimizing the message load in the network.

Thus, by the embodiments described above it is possible to configure a terminal device such as a MTC-UE to wake up and/or sending messages only on certain conditions.

The proposed solution is based on current 3GPP standard procedures and only adds some new parameters in existing message exchange procedures and some design logic in the MTC-UE and application server / MTC-IWF. Hence, the solution can easily be applied to current procedures.

The proposal improves earlier solutions by tackling high latency related problems in areas of reachability, packet loss, system overload trough useless resendings, etc. An important use case is the communication between UEs and the AS in an environment where "UEs using UE battery saving techniques, UE sleep functions making UEs unreachable for long periods of time, UEs using low throughput bearers, etc, hence resulting in e.g. in high latency for accessing the devices from network side" (as per the related 3GPP work item description).

It is noted that the embodiments and the present invention in general is not limited to the specific examples given above.

According to another aspect of embodiments of the present invention, an apparatus is provided which comprises means for determining condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device by setting one or more wake-up behaviours and/or condition related accessibility based on one or more conditions, and means for sending the condition information to the terminal device.

According to a further aspect of embodiments of the present invention, an apparatus is provided which comprises means for receive condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility for a terminal device in which one or more wake-up behaviours and/or condition related accessibility are set based on one or more conditions, means for sending the condition information to the terminal device, and means for communicating with the terminal device based on the condition information.

According to a still further aspect of embodiments of the present invention, an apparatus is provided which comprises communication means for communicating with a network, means for receiving condition information indicating one or more condition related wake-up behaviours and/or condition related accessibility in which one or more wake-up behaviours and/or related accessibility are set based on one or more conditions, and means for activating and deactivating at least the communication means of the apparatus based on the received condition information.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects and/or embodiments to which they refer, unless they are explicitly stated as excluding alternatives.

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 network element or terminal (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 invention 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, eNode-B etc. 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 apparatuses, or any one of their respective 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 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.

It is noted that the embodiments and 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 be included which fall within the spirit and scope of the appended claims.