Service capability server / epc coordination for power savings mode and paging

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims priority to U.S. Provisional Application No. 62/056,924, filed Sep. 29, 2014, the disclosure of which is incorporated herein by reference in its entirety.

BACKGROUND

0002The Third Generation Partnership Project (3GPP) unites a number of telecommunications standard development organizations and provides their members with an environment in which to develop specifications for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities. 3GPP specifications also provide hooks for non-radio access to the core network, and for interworking with other networks.

0003More recently 3GPP introduced the Power Savings Mode (PSM) feature. PSM is a new user equipment (UE) state where the UE can stop listening for paging, stop performing idle mode procedures, etc. When the UE is in this state, it may not be reachable for mobile terminated (MT) communications. While the UE may certainly benefit from energy savings, other entities, such as for example, a Service Capability Server (SCS), lack control or awareness as to whether the UE is using the PSM feature. Likewise, the UE is unaware of when the SCS will need to reach the UE. Thus, the UE may not know the best time to invoke PSM.

0004The PSM feature presently allows the UE to ask the Mobile Management Entity (MME) to go into PSM mode for a predetermined amount of time. The MME has authority over whether the UE's request should be granted. Thus, a SCS cannot prevent a UE from entering a PSM state. The SCS also cannot control the instant the UE enters the PSM state, as well as the duration of the PSM state. Separately, the SCS is not apprised as to when the UE moves into and out of a PSM state. Without this information, the SCS cannot efficiently initiate and/or schedule its MT communication with the UE. Since many of the PSM capable devices are low power/low cost devices, it is important to avoid retransmission of data to these devices to avoid higher power consumption, wastage of network resources, and patchy communication with the device.

0005Further, the PSM feature requires that the UE request a value for ‘Periodic Tracking Area Update (TAU)’ and the ‘Active time’. The requested times depend upon when the UE anticipates that it will need to be available for MT data. While the MME decides the final value of these timers, the MME cannot initiate the request to provide an active timer for the UE.

SUMMARY

0006This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to limit the scope of the claimed subject matter. The foregoing needs are met, to a great extent, by the present application directed to a process and system for facilitating control and coordination of user equipment (UE).

0007In one aspect of the application, there is described a computer-implemented apparatus controlling power savings mode characteristics of a device on a network. The apparatus includes a non-transitory memory having instructions stored for controlling power savings mode characteristics. The non-transitory memory is operably coupled to a processor for executing the instructions. The instructions include receiving a request to update the characteristics of the device on the network. The instructions also include updating the characteristic of the device based upon the request. The instructions further include sending an acknowledgement that the characteristic has been updated.

0008In another aspect of the application, there is described a computer-implemented apparatus controlling power savings mode characteristics of a device on a network. The apparatus includes a non-transitory memory having instructions stored for controlling power savings mode characteristics. The non-transitory memory is operably coupled to a processor for executing the instructions. The instructions include receiving a tracking area update or an attach request from the device on the network. The instructions also include sending a device availability notification request to a core network interworking function or a service capability server. The instructions also include receiving a device availability notification answer from the interworking function or the service capability server.

0009In yet another aspect of the application, there is described a computer-implemented apparatus for supporting buffering and data handling for a power savings mode of a device on the network. The apparatus includes a non-transitory memory having instructions stored thereon. The non-transitory memory is operably coupled to a processor for executing the instructions. The instructions include receiving a downlink data notification from a serving gateway. The instructions also include determining the device is in a power saving mode and that an enhanced data handling flag is enabled. The instructions further include sending a downlink data notification acknowledgment to the serving gateway including the enhanced data handling flag.

0010In a further aspect of the application, there is described a computer-implemented method for controlling a power savings mode characteristic of a device on a network. The method includes the step of receiving a tracking area update or an attach request from the device on the network. The method also includes a step of sending a device availability notification request to a core network interworking function or a service capability server. The method further includes a step of receiving a device availability notification answer from the core network interworking function or the service capability server. The notification request provides notification information of when the device exits power savings mode.

0011In a further aspect of the application, there is described a computer-implemented method for controlling a power savings mode characteristic of a device on a network. The method includes the step of receiving a request to update the characteristics of the device on the network. The method also includes a step of updating the characteristic of the device based upon the request. The method also includes a step of sending an acknowledgement that the characteristic has been updated. The method further includes a step of forwarding an insert subscriber data request to a mobile management entity.

0012In a further aspect of the application, there is described a computer-implemented method for supporting buffering and data handling for a power saving mode of a device on a network. The method includes a step of receiving a downlink data notification from a serving gateway. The method also includes a step of determining the device is in power saving mode and that an enhanced data handling flag is enabled. The method also includes a step of sending a downlink data notification acknowledgment to the serving gateway including the enhanced data handling flag. The method further includes a step of paging the device.

0013There has thus been outlined, rather broadly, certain embodiments of the invention in order that the detailed description thereof may be better understood, and in order that the present contribution to the art may be better appreciated.

BRIEF DESCRIPTION OF THE DRAWINGS

0014In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

0015<figref idref="DRAWINGS">FIG. 1</figref> illustrates a basic architecture a E-UTRAN, evolved packet core and external network(s).

0016<figref idref="DRAWINGS">FIG. 2</figref> illustrates 3GPP core networking architecture.

0017<figref idref="DRAWINGS">FIG. 3A</figref> illustrates an interface between a LWM2M server and a LWM2M client according to an embodiment.

0018<figref idref="DRAWINGS">FIG. 3B</figref> illustrates an interface between a M2M service layer and a DM layer according to an embodiment.

0019<figref idref="DRAWINGS">FIG. 4A</figref> illustrates an embodiment of a machine-to machine (M2M) or IoT communication system.

0020<figref idref="DRAWINGS">FIG. 4B</figref> illustrates an embodiment of the application of a M2M service platform.

0021<figref idref="DRAWINGS">FIG. 4C</figref> illustrates an embodiment of the application of a system diagram of an example M2M device.

0022<figref idref="DRAWINGS">FIG. 4D</figref> illustrates an embodiment of the application of a block diagram of an exemplary computing system.

0023<figref idref="DRAWINGS">FIG. 5</figref> illustrates a call flow where a service capability server (SCS) sends device periodicity characteristics to the MME according to an embodiment.

0024<figref idref="DRAWINGS">FIG. 6</figref> illustrates another call flow where a SCS sends device periodicity characteristics to the MMM according to an embodiment.

0025<figref idref="DRAWINGS">FIG. 7</figref> illustrates a pre-triggering call flow according to an embodiment.

0026<figref idref="DRAWINGS">FIG. 8</figref> illustrates a tracking area update (TAU) call flow according to an embodiment.

0027<figref idref="DRAWINGS">FIG. 9</figref> illustrates an attach call flow according to an embodiment.

0028<figref idref="DRAWINGS">FIG. 10</figref> illustrates a call flow describing enhancements to a S1 release procedure according to an embodiment.

0029<figref idref="DRAWINGS">FIG. 11</figref> illustrates a user equipment assistance information call flow to indicate low power preference according to another embodiment.

0030<figref idref="DRAWINGS">FIG. 12</figref> illustrates a network-initiated service request procedure according to an embodiment.

0031<figref idref="DRAWINGS">FIG. 13</figref> is a use equipment triggered service request procedure according to another embodiment.

0032<figref idref="DRAWINGS">FIG. 14</figref> illustrates a lightweight machine-to-machine (LWM2M) server requests according to an embodiment.

0033<figref idref="DRAWINGS">FIG. 15</figref> illustrates a LWM2M server request according to another embodiment.

DETAILED DESCRIPTION OF THE ILLUSTRATIVE EMBODIMENTS

0034A detailed description of the illustrative embodiment will be discussed in reference to various figures, embodiments and aspects herein. Although this description provides detailed examples of possible implementations, it should be understood that the details are intended to be examples and thus do not limit the scope of the application.

0035Reference in this specification to “one embodiment,” “an embodiment,” “one or more embodiments,” “an aspect” or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. Moreover, the term “embodiment” in various places in the specification is not necessarily referring to the same embodiment. That is, various features are described which may be exhibited by some embodiments and not by the other.

0036The present application describes techniques for facilitating control and coordination of UEs between a core network (CN) and a service capability server (SCS). In one aspect of the present application, techniques are described whereby UEs are controlled upon entering, remaining within and exiting a power saving mode (PSM). In particular, the present application provides for new protocols between a core network (CN), including a mobility management entity (MME), a MTC Interworking function (MTC-IWF) and a service capability server (SCS). In one embodiment, the SCS can enable and/or disable PSM features for individual UEs to align UE reachability with machine mobile terminated (MT) data periodicity. In another embodiment, the SCS may subscribe to a MME to coordinate mobile terminated (MT) data on every tracking area update (TAU) and attach request. The SCS may also influence the decision of the “Active Timer” and “Periodic TAU timer” values which the MME sends to the UE in order for the UE's active time to be aligned with MT data. In another embodiment, the SCS may enable and/or disable enhanced buffering of data at a serving gateway (SGW) and also specially handle data at the eNodeB to ensure delivery of data packets to UEs in PSM or that are low power UEs. By so doing, application level retransmissions may be reduced and/or eliminated.

0037Another aspect of the application is directed to novel procedures for pre-triggering PSM UEs. For instance, a core network interworking function may facilitate transmitting a request message from a SCS to a MME. A machine type communication interworking function (MTC-IWF) is one type of core network interworking function that may facilitate transmitting a request message from a SCS to a MME or HSS. A service capability exposure function (SCEF) is another type of core network interworking function that may facilitate transmitting a request message from a SCS to a MME or HSS. For example, the SCS may notify the UE via a Device-Availability-Notification request to control a UE that is in an idle mode. Moreover, the SCS may receive an answer via a Device-Availability-Notification answer.

0038According to even another aspect of the present application, there is described a core network node (MME) with the capability of initiating a PSM in a UE. In one embodiment, the UE gives more control to the network by making it aware of its PSM capability and thereby allowing the network to perform network initiated PSM procedures. In another embodiment, the CN may enable PSM for the UE to provide a low power consumption preference in the UE Assistance Information.

0039In yet a further aspect of the present application, a procedure is described for optimizing paging for low mobility devices. By so doing, the UE may consume less battery power since AS functionalities are turned off during PSM. In one embodiment, the MME may be configured to provide a specific subset of tracking area (TA) List to each UE based on its mobility parameters in lieu of providing an entire TA List served by the MME to all connecting UEs. In another embodiment, the CN may support paging optimization for stationary/low mobility UEs, by paging the last updated tracking area in lieu of paging all tracking areas in the tracking area list.

0040Table 1 below provides a list of generally used acronyms throughout the application.

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="147pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 1</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Acronym</entry><entry>Description</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>3GPP</entry><entry>3rd Generation Partnership Project</entry></row><row><entry /><entry>AVP</entry><entry>Attribute-Value Pair</entry></row><row><entry /><entry>AT</entry><entry>Attention</entry></row><row><entry /><entry>CN</entry><entry>Core Network</entry></row><row><entry /><entry>DL</entry><entry>Down Link</entry></row><row><entry /><entry>ECGI</entry><entry>E-UTRAN Cell Global ID</entry></row><row><entry /><entry>E-UTRAN</entry><entry>Evolved Universal Terrestrial</entry></row><row><entry /><entry /><entry>Radio Access Network</entry></row><row><entry /><entry>EMM</entry><entry>EPS Mobility Management</entry></row><row><entry /><entry>eNB</entry><entry>Evolved Node B</entry></row><row><entry /><entry>EPC</entry><entry>Evolved Packet Core</entry></row><row><entry /><entry>EPS</entry><entry>Evolved Packet System</entry></row><row><entry /><entry>ETSI</entry><entry>European Telecommunications</entry></row><row><entry /><entry /><entry>Standards Institute</entry></row><row><entry /><entry>FQDN</entry><entry>Fully Qualified Domain Name</entry></row><row><entry /><entry>HLR</entry><entry>Home Location Register</entry></row><row><entry /><entry>HSS</entry><entry>Home Subscriber Server</entry></row><row><entry /><entry>IE</entry><entry>Information Element</entry></row><row><entry /><entry>IMSI</entry><entry>International Mobile Subscriber Identity</entry></row><row><entry /><entry>IP</entry><entry>Internet Protocol</entry></row><row><entry /><entry>LS</entry><entry>Liaison Statement</entry></row><row><entry /><entry>LTE</entry><entry>Long Term Evolution</entry></row><row><entry /><entry>LWM2M</entry><entry>Lightweight Machine to Machine</entry></row><row><entry /><entry>M2M</entry><entry>Machine to Machine</entry></row><row><entry /><entry>M2M GW</entry><entry>M2M Gateway</entry></row><row><entry /><entry>MME</entry><entry>Mobility Management Entity</entry></row><row><entry /><entry>MS</entry><entry>Mobile Station</entry></row><row><entry /><entry>MSISDN</entry><entry>Mobile Subscriber Integrated</entry></row><row><entry /><entry /><entry>Services Digital Network-Number</entry></row><row><entry /><entry>MT</entry><entry>Mobile Termination/Mobile Terminated</entry></row><row><entry /><entry>MT-SMS</entry><entry>Mobile Terminated SMS</entry></row><row><entry /><entry>MTC</entry><entry>Machine Type Communication</entry></row><row><entry /><entry>MTC-IWF</entry><entry>Machine Type Communications</entry></row><row><entry /><entry /><entry>Inter-Working Function</entry></row><row><entry /><entry>NAS</entry><entry>Non-Access Stratum</entry></row><row><entry /><entry>PDN</entry><entry>Packet Data Network</entry></row><row><entry /><entry>PLMN</entry><entry>Public Land Mobile Network</entry></row><row><entry /><entry>PSM</entry><entry>Power Saving Mode</entry></row><row><entry /><entry>RAT</entry><entry>Radio Access Technology</entry></row><row><entry /><entry>RRC</entry><entry>Radio Resource Control</entry></row><row><entry /><entry>SGW</entry><entry>Serving Gateway</entry></row><row><entry /><entry>SC</entry><entry>Service Center</entry></row><row><entry /><entry>SCS</entry><entry>Services Capability Server</entry></row><row><entry /><entry>SDO</entry><entry>Standards Developing Organizations</entry></row><row><entry /><entry>SEES</entry><entry>Service Exposure and Enablement Support</entry></row><row><entry /><entry>SMS</entry><entry>Short Message Service</entry></row><row><entry /><entry>TA</entry><entry>Tracking Area</entry></row><row><entry /><entry>TAU</entry><entry>Tracking Area Update</entry></row><row><entry /><entry>TS</entry><entry>Technical Specification</entry></row><row><entry /><entry>UDC</entry><entry>User Data Convergence</entry></row><row><entry /><entry>UDR</entry><entry>User Data Repository</entry></row><row><entry /><entry>UE</entry><entry>User Equipment</entry></row><row><entry /><entry>UL</entry><entry>Up Link</entry></row><row><entry /><entry>ULA</entry><entry>Update-Location-Answer</entry></row><row><entry /><entry>USSD</entry><entry>Unstructured Supplementary Service Data</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0041The latest evolution of the 3GPP core network architecture for wireless communications is referred to as the Evolved Packet Core (EPC). EPC was first introduced by 3GPP in Release 8 of the standard. It was designed to have a “flat architecture” in order to handle data traffic efficiently from a performance and cost perspective, and few network nodes are involved in the handling of traffic. Protocol conversion is also generally avoided. It was also decided to separate the user data (also known as the “user plane”) from the signaling (also known as the “control plane”), which enables network operators to dimension and adapt their networks easily.

0042Machine type communications (MTC)s involve communications between different entities that do not necessarily involve human interaction. In particular, M2M devices may be characterized as having low mobility. That is, the M2M device might not move, move infrequently, or move only within a certain region. One example may be a M2M device installed in a street light. M2M devices may also be characterized as having infrequent mobile terminated communication. Specifically, they may infrequently need to receive data. For example, a smart meter may frequently collect data and send it to an SCS, but the SCS may infrequently initiate communication to the smart meter. M2M devices may further be characterized as having time-controlled communications, or asymmetric communications. Some M2M devices may send or receive data at very predictable times, e.g., an environmental sensor may be programmed to send sensor readings at defined times of the day. Conversely, other M2M devices may require a very short latency, e.g., a home security alarm system.

0043MTC devices may utilize the services of the SCS to communicate with external MTC applications. The 3GPP system provides transport for M2M device communication. Additionally, the 3GPP system may also provide other value added services for machine type communication. Different architectural models in 3GPP systems are based on the relationship of the MTC service provider (SCS) and the 3GPP network operator. A MTC-IWF is introduced in 3GPP system to enable the communication of 3GPP networks with one or more SCSs. The MTC-IWF could be a standalone entity or a functional entity of another network element. The MTC-IWF hides the internal PLMN topology and relays or translates information sent over the diameter based Tsp reference point to invoke specific functionality in the PLMN.

0044According to an embodiment, <figref idref="DRAWINGS">FIG. 1</figref> illustrates a basic architecture diagram <b>100</b> including a User Equipment (UE) <b>104</b>, e.g., a mobile phone or other wireless device, connected to the EPC <b>102</b> over E-UTRAN (LTE access network). The Evolved NodeB (eNodeB) <b>106</b> is the base station for LTE radio. The EPC includes four network elements: (i) the Serving Gateway (Serving GW) <b>110</b>, (ii) the Packet Data Network Gateway (PDN GW) <b>112</b>, (iii) the MME <b>114</b> and (iv) the HSS <b>116</b>. The EPC may be connected to external networks <b>108</b>. The HSS (for Home Subscriber Server) <b>116</b> is a database that contains user-related and subscriber-related information. It also provides support functions in mobility management, call and session setup, user authentication and access authorization.

0045The gateways (Serving GW <b>110</b> and PDN GW <b>112</b>) deal with the user plane. They transport IP data traffic between the User Equipment (UE) and the external networks. The Serving GW <b>110</b> is the point of interconnect between the radio-side and the EPC. As its name indicates, this gateway serves the UE by routing incoming and outgoing IP packets. It is the anchor point for intra-LTE mobility, i.e., in case of handover between eNodeBs and between LTE and other 3GPP accesses. It is logically connected to the other gateway, the PDN GW.

0046The PDN GW <b>112</b> is the point of interconnect between the EPC and external IP networks, such as the Internet. These networks are called PDN (Packet Data Network), hence the name. The PDN GW routes packets to and from the PDNs. The PDN GW also performs various functions such as IP address/IP prefix allocation or policy control and charging. 3GPP specifies these gateways independently but in practice they may be combined in a single “box” by network vendors.

0047The MME (for Mobility Management Entity) <b>114</b> deals with the control plane. It handles the signaling related to mobility and security for E-UTRAN access. The MME is responsible for the tracking and the paging of UEs in idle-mode. It is also the termination point of the Non-Access Stratum (NAS).

0048As shown in <figref idref="DRAWINGS">FIG. 1</figref>, a UE <b>104</b> can reach the EPC <b>102</b> using E-UTRAN, however this is not the only access technology supported. 3GPP specifies support of multiple access technologies and also the handover between these accesses. The idea is to bring convergence using a unique core network providing various IP-based services over multiple access technologies. Existing 3GPP radio access networks are supported. 3GPP specifications define how interworking is achieved between an E-UTRAN (LTE and LTE-Advanced), GERAN (radio access network of GSM/GPRS) and UTRAN (radio access network of UMTS-based technologies WCDMA and HSPA).

0049The architecture also allows non-3GPP technologies to interconnect the UE and the EPC. Non-3GPP means that these accesses were not specified in 3GPP. These technologies include, for example, WiMAX, cdma2000®, WLAN or fixed networks. Non-3GPP accesses can be split into two categories: the “trusted” ones and the “untrusted”. Trusted non-3GPP accesses can interact directly with the EPC. Untrusted non-3GPP accesses interwork with the EPC via a network entity called the ePDG (for Evolved Packet Data Gateway) (not shown). The main role of the ePDG is to provide security mechanisms such as IPsec tunneling of connections with the UE over an untrusted non-3GPP access. 3GPP does not specify which non-3GPP technologies should be considered trusted or untrusted. This decision is made by the operator.

0050The 3GPP network architecture illustrated in <figref idref="DRAWINGS">FIG. 1</figref> was originally designed to enable communication between devices that are traditionally operated by humans. For example, the 3GPP network is well suited for providing a smart phone with access to a packet switched network such as the internet and a circuit switched network such as a Global System for Mobile Communications (GSM) network. The 3GPP network was not originally designed in a way that is optimized for handling so called machine-to-machine (M2M) communications, also referred to as machine type communications (MTC), in which machines, or devices, communicate with each other over the network, such as communications involving smart metering, home automation, eHealth, consumer products, fleet management, etc.

0051In Release 11 (R11) of the 3GPP specifications, 3GPP enhanced the interworking capabilities of the UMTS core network for machine type communications/machine-to-machine communications. Interworking refers to a server, or application, interfacing to the core network for the purposes of exchanging information, controlling devices, or monitoring devices, or communicating with devices.

0052In another embodiment, <figref idref="DRAWINGS">FIG. 2</figref> illustrates a MTC architecture that is presented by 3GPP in TS 23.682 V11.5.0. As illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, a service capability server (SCS) <b>212</b> may provide services to the core network, devices, and applications. The SCS may also be called a M2M Server, MTC Server, a Service Capability Layer, or a Common Services Entity (CSE). An SCS <b>212</b> may be controlled by the operator of the home public land mobile network (HPLMN) or by an MTC service provider. An SCS may be deployed inside or outside the operator domain. If an SCS is deployed inside the operator domain, the SCS may be an internal network function and may be controlled by the operator. If an SCS is deployed outside the operator domain, the SCS may be controlled by a MTC service provider.

0053An SCS may communicate with a machine type communication (MTC) interworking function (MTC-IWF) <b>210</b> via a Tsp reference point, i.e., interface. The Tsp reference point is an example of an interface that is used for interworking with the core network.

0054In another embodiment, as illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, the reference point, i.e., interface, Tsms <b>202</b> may connect a short message service (SMS) service center (SMS-SC) <b>204</b> to a short message entity (SME) <b>206</b>. The Tsms reference point is another example of an interface that is used for interworking with the core network. The SMS-SC <b>204</b> communicates with the MTC-IWF over a T4 reference point.

0055The SCS <b>212</b> may be an entity that connects to a 3GPP network to communicate with user equipment MTC (UE MTC) application <b>216</b>, the MTC-IWF <b>210</b> in the HPLMN, e.g., as defined by the boundary <b>218</b>, or a SMS-SC <b>204</b> for device triggering. The SCS <b>212</b> may offer capabilities for use by one or more application server MTC (AS MTC) applications.

0056A UE may communicate through the public land mobile network (PLMN), which includes radio access network (RAN) <b>219</b>, with SCS(s) and/or other MTC UE(s). A MTC UE <b>214</b> may host one or more MTC applications <b>216</b>. The MTC applications may also be hosted on one or more application servers (AS)s <b>220</b>/<b>222</b>. The MTC application <b>216</b> may be a MTC communication endpoint that may interact with SCSs <b>212</b>, AS MTC applications, or other UE MTC applications.

0057An AS <b>220</b>/<b>222</b> may also host one or more MTC applications. An AS may interface with SCS(s) <b>212</b> or a GGSN/P-GW <b>224</b>. The MTC applications on an AS may interact with SCSs, UE MTC applications, or other MTC applications.

0058The MTC inter working function (MTC-IWF) <b>210</b> may hide the internal PLMN topology from the SCS <b>212</b>. The MTC-IWF may relay and/or translate signaling protocols used between itself and the SCS, e.g., over the Tsp reference point <b>208</b>, to support MTC functionality, e.g., MTC UE triggering, in the PLMN. For example, the SCS may request that the MTC-IWF send a trigger to a MTC device. The MTC-IWF may deliver the MTC trigger to the MTC device <b>214</b> via SMS. The MTC device <b>216</b>, based on the trigger, may respond to the SCS <b>212</b>. The MTC device <b>216</b> may, for example, respond with a sensor reading. When the MTC device <b>216</b> responds to the SCS <b>212</b>, the MTC device may use a packet data network (PDN)/packet data protocol (PDP) connection to communicate with the SCS <b>212</b>. The MTC device may connect with the SCS using an IP connection.

0059The MTC-IWF <b>210</b> may authorize an SCS <b>212</b>, before the SCS may establish communication with a 3GPP network. For example, when the SCS <b>212</b> makes a trigger request on the Tsp reference point, the MTC-IWF <b>210</b> may check whether the SCS is authorized to send the trigger request and that the SCS has not exceeded its quota or rate of trigger submissions.

0060As further shown in <figref idref="DRAWINGS">FIG. 2</figref>, a mobile switching center (MSC) <b>238</b> is the primary service delivery node for GSM/CDMA, responsible for routing voice calls and SMS as well as other services (such as conference calls, FAX and circuit switched data). The MSC sets up and releases the end-to-end connection, handles mobility and hand-over requirements during the call and takes care of charging and real time pre-paid account monitoring.

LWM2M Architecture

0061Lightweight machine to machine (LWM2M) protocol was developed by the Open Mobile Alliance (OMA) standards body to enable management of resource constrained, M2M/IoT devices. The purpose of this protocol was to provide a lightweight architecture that minimizes protocol overhead by using an efficient transport protocol such as CoAP (Constrained Application Protocol) and minimizing message and data model sizes. <figref idref="DRAWINGS">FIG. 3A</figref> shows the OMA LWM2M architecture in which a LWM2M server <b>310</b> communicates to a LWM2M client <b>320</b> through various defined interfaces using a minimal, efficient stack. The LWM2M client <b>320</b> runs on a M2M/IoT device and implements LWM2M objects that could be used to perform management functions. These objects are LWM2M data models that incorporate resources hosted on the devices that can be exercised by a LWM2M server. Among some of the functions that can be managed are obtaining device information such as software version, battery level, and available memory as well as providing connectivity monitoring such as cellular link quality and radio signal strength.

0062The LWM2M architecture <b>350</b> may be incorporated into a M2M service layer architecture <b>370</b> through the M2M interface <b>360</b> as illustrated in <figref idref="DRAWINGS">FIG. 3B</figref>. As a result of this integration, device management of M2M/IoT devices <b>380</b> can be realized easily within the service layer domain. An M2M application registered to the service layer can then initiate management of devices to a management server such as the LWM2M Server, which will execute the management commands on the devices. As a result of this integration, key metrics such as link quality and battery level could be retrieved from the device and used as part of an overall power conservation strategy to manage the device.

General Architecture

0063<figref idref="DRAWINGS">FIG. 4A</figref> is a diagram of an example machine-to machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system <b>10</b> in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, gateway or service platform may be a component of the IoT/WoT as well as an IoT/WoT service layer, etc.

0064As shown in <figref idref="DRAWINGS">FIG. 4A</figref>, the M2M/IoT/WoT communication system <b>10</b> includes a communication network <b>12</b>. The communication network <b>12</b> may be a fixed network, e.g., Ethernet, Fiber, ISDN, PLC, or the like or a wireless network, e.g., WLAN, cellular, or the like, or a network of heterogeneous networks. For example, the communication network <b>12</b> may comprise of multiple access networks that provides content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network <b>12</b> may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network <b>12</b> may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

0065As shown in <figref idref="DRAWINGS">FIG. 4A</figref>, the M2M/IoT/WoT communication system <b>10</b> may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain includes M2M gateways <b>14</b>, such as a SCS with a proxy, and terminal devices <b>18</b>, such as UE devices. It will be appreciated that any number of M2M gateway devices <b>14</b> and M2M terminal devices <b>18</b> may be included in the M2M/IoT/WoT communication system <b>10</b> as desired. Each of the M2M gateway devices <b>14</b> and M2M terminal devices <b>18</b> are configured to transmit and receive signals via the communication network <b>12</b> or direct radio link. The M2M gateway device <b>14</b> allows wireless M2M devices, e.g., cellular and non-cellular as well as fixed network M2M devices, e.g., PLC, to communicate either through operator networks, such as the communication network <b>12</b> or direct radio link. For example, the M2M devices <b>18</b> may collect data and send the data, via the communication network <b>12</b> or direct radio link, to an M2M application <b>20</b> or M2M devices <b>18</b>. The M2M devices <b>18</b> may also receive data from the M2M application <b>20</b> or an M2M device <b>18</b>. Further, data and signals may be sent to and received from the M2M application <b>20</b> via an M2M service layer <b>22</b>, as described below. In one embodiment, the service layer <b>22</b> may be a PCE. M2M devices <b>18</b> and gateways <b>14</b> may communicate via various networks including, cellular, WLAN, WPAN, e.g., Zigbee, 6LoWPAN, Bluetooth, direct radio link, and wireline for example.

0066Referring to <figref idref="DRAWINGS">FIG. 4B</figref>, the illustrated M2M service layer <b>22</b> in the field domain provides services for the M2M application <b>20</b>, M2M gateway devices <b>14</b>, and M2M terminal devices <b>18</b> and the communication network <b>12</b>. It will be understood that the M2M service layer <b>22</b> may communicate with any number of M2M applications, M2M gateway devices <b>14</b>, M2M terminal devices <b>18</b> and communication networks <b>12</b> as desired. The M2M service layer <b>22</b> may be implemented by one or more servers, computers, or the like. The M2M service layer <b>22</b> provides service capabilities that apply to M2M terminal devices <b>18</b>, M2M gateway devices <b>14</b> and M2M applications <b>20</b>. The functions of the M2M service layer <b>22</b> may be implemented in a variety of ways. For example, the M2M service layer <b>22</b> could be implemented in a web server, in the cellular core network, in the cloud, etc.

0067Similar to the illustrated M2M service layer <b>22</b>, there is the M2M service layer <b>22</b>′ in the Infrastructure Domain. M2M service layer <b>22</b>′ provides services for the M2M application <b>20</b>′ and the underlying communication network <b>12</b>′ in the infrastructure domain. M2M service layer <b>22</b>′ also provides services for the M2M gateway devices <b>14</b> and M2M terminal devices <b>18</b> in the field domain. It will be understood that the M2M service layer <b>22</b>′ may communicate with any number of M2M applications, M2M gateway devices and M2M terminal devices. The M2M service layer <b>22</b>′ may interact with a service layer by a different service provider. The M2M service layer <b>22</b>′ may be implemented by one or more servers, computers, virtual machines, e.g., cloud/compute/storage farms, etc., or the like.

0068Referring also to <figref idref="DRAWINGS">FIG. 4B</figref>, the M2M service layer <b>22</b> and <b>22</b>′ provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications <b>20</b> and <b>20</b>′ to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The service layer <b>22</b> and <b>22</b>′ also enables M2M applications <b>20</b> and <b>20</b>′ to communicate through various networks <b>12</b> and <b>12</b>′ in connection with the services that the service layer <b>22</b> and <b>22</b>′ provide.

0069The M2M applications <b>20</b> and <b>20</b>′ may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location Tracking/geo-fencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications <b>20</b> and <b>20</b>′. Moreover, the M2M service layer may also be configured to interface with other devices such as UEs, SCSs and MMEs as discussed in this application and illustrated in the figures.

0070The method of controlling and coordinating UE's PSM mode as discussed in the present application may be implemented as part of a service layer. The service layer is a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both ETSI M2M and oneM2M use a service layer that may contain this method of controlling and coordinating UEs PSM mode. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs), e.g., service capabilities. An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE), such as a SCS which may be hosted on different types of network nodes, e.g., infrastructure node, middle node, application-specific node. Further, the method of reserving a Track as described in the present application can be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a resource-oriented architecture (ROA) to access services such as the reserving a Track according to the present application.

0071<figref idref="DRAWINGS">FIG. 4C</figref> is a system diagram of an example M2M device <b>30</b>, such as a M2M terminal device <b>18</b> or an M2M gateway device <b>14</b> for example. As shown in <figref idref="DRAWINGS">FIG. 4C</figref>, the M2M device <b>30</b> may include a processor <b>32</b>, a transceiver <b>34</b>, a transmit/receive element <b>36</b>, a speaker/microphone <b>38</b>, a keypad <b>40</b>, a display/touchpad/indicator(s) <b>42</b>, non-removable memory <b>44</b>, removable memory <b>46</b>, a power source <b>48</b>, a global positioning system (GPS) chipset <b>50</b>, and other peripherals <b>52</b>. It will be appreciated that the M2M device <b>40</b> may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This device may be a device that uses the disclosed systems and methods for embedded semantics naming of sensory data. The M2M device <b>30</b> may also be employed with other devices, including fore example LLN devices, Backbone routers and PCEs as described in this application and as illustrated in the figures.

0072The processor <b>32</b> may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor <b>32</b> may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the M2M device <b>30</b> to operate in a wireless environment. The processor <b>32</b> may be coupled to the transceiver <b>34</b>, which may be coupled to the transmit/receive element <b>36</b>. While <figref idref="DRAWINGS">FIG. 4C</figref> depicts the processor <b>32</b> and the transceiver <b>34</b> as separate components, it will be appreciated that the processor <b>32</b> and the transceiver <b>34</b> may be integrated together in an electronic package or chip. The processor <b>32</b> may perform application-layer programs, e.g., browsers, and/or radio access-layer (RAN) programs and/or communications. The processor <b>32</b> may perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

0073The transmit/receive element <b>36</b> may be configured to transmit signals to, or receive signals from, an M2M service platform <b>22</b>. For example, in an embodiment, the transmit/receive element <b>36</b> may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element <b>36</b> may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit/receive element <b>36</b> may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element <b>36</b> may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element <b>36</b> may be configured to transmit and/or receive any combination of wireless or wired signals.

0074In addition, although the transmit/receive element <b>36</b> is depicted in <figref idref="DRAWINGS">FIG. 4C</figref> as a single element, the M2M device <b>30</b> may include any number of transmit/receive elements <b>36</b>. More specifically, the M2M device <b>30</b> may employ MIMO technology. Thus, in an embodiment, the M2M device <b>30</b> may include two or more transmit/receive elements <b>36</b>, e.g., multiple antennas, for transmitting and receiving wireless signals.

0075The transceiver <b>34</b> may be configured to modulate the signals that are to be transmitted by the transmit/receive element <b>36</b> and to demodulate the signals that are received by the transmit/receive element <b>36</b>. As noted above, the M2M device <b>30</b> may have multi-mode capabilities. Thus, the transceiver <b>34</b> may include multiple transceivers for enabling the M2M device <b>30</b> to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

0076The processor <b>32</b> may access information from, and store data in, any type of suitable memory, such as the non-removable memory <b>44</b> and/or the removable memory <b>46</b>. The non-removable memory <b>44</b> may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory <b>46</b> may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor <b>32</b> may access information from, and store data in, memory that is not physically located on the M2M device <b>30</b>, such as on a server or a home computer.

0077The processor <b>32</b> may receive power from the power source <b>48</b>, and may be configured to distribute and/or control the power to the other components in the M2M device <b>30</b>. The power source <b>48</b> may be any suitable device for powering the M2M device <b>30</b>. For example, the power source <b>48</b> may include one or more dry cell batteries, e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

0078The processor <b>32</b> may also be coupled to the GPS chipset <b>50</b>, which is configured to provide location information, e.g., longitude and latitude, regarding the current location of the M2M device <b>30</b>. It will be appreciated that the M2M device <b>30</b> may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

0079The processor <b>32</b> may further be coupled to other peripherals <b>52</b>, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals <b>52</b> may include an accelerometer, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

0080<figref idref="DRAWINGS">FIG. 4D</figref> is a block diagram of an exemplary computing system <b>90</b> on which, for example, the M2M service platform <b>22</b> of <figref idref="DRAWINGS">FIG. 4A</figref> and <figref idref="DRAWINGS">FIG. 4B</figref> may be implemented. Computing system <b>90</b> may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within central processing unit (CPU) <b>91</b> to cause computing system <b>90</b> to do work. In many known workstations, servers, and personal computers, central processing unit <b>91</b> is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit <b>91</b> may comprise multiple processors. Coprocessor <b>81</b> is an optional processor, distinct from main CPU <b>91</b> that performs additional functions or assists CPU <b>91</b>. CPU <b>91</b> and/or coprocessor <b>81</b> may receive, generate, and process data related to the disclosed systems and methods for embedded semantic naming, such as queries for sensory data with embedded semantic names.

0081In operation, CPU <b>91</b> fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus <b>80</b>. Such a system bus connects the components in computing system <b>90</b> and defines the medium for data exchange. System bus <b>80</b> typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus <b>80</b> is the PCI (Peripheral Component Interconnect) bus.

0082Memory devices coupled to system bus <b>80</b> include random access memory (RAM) <b>82</b> and read only memory (ROM) <b>93</b>. Such memories include circuitry that allows information to be stored and retrieved. ROMs <b>93</b> generally contain stored data that cannot easily be modified. Data stored in RAM <b>82</b> can be read or changed by CPU <b>91</b> or other hardware devices. Access to RAM <b>82</b> and/or ROM <b>93</b> may be controlled by memory controller <b>92</b>. Memory controller <b>92</b> may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller <b>92</b> may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

0083In addition, computing system <b>90</b> may contain peripherals controller <b>83</b> responsible for communicating instructions from CPU <b>91</b> to peripherals, such as printer <b>94</b>, keyboard <b>84</b>, mouse <b>95</b>, and disk drive <b>85</b>.

0084Display <b>86</b>, which is controlled by display controller <b>96</b>, is used to display visual output generated by computing system <b>90</b>. Such visual output may include text, graphics, animated graphics, and video. Display <b>86</b> may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller <b>96</b> includes electronic components required to generate a video signal that is sent to display <b>86</b>. Display <b>86</b>, may display sensory data in files or folders using embedded semantics names. Further, computing system <b>90</b> may contain network adaptor <b>97</b> that may be used to connect computing system <b>90</b> to an external communications network, such as network <b>12</b> of <figref idref="DRAWINGS">FIG. 4A</figref> and <figref idref="DRAWINGS">FIG. 4B</figref>.

SCS Coordination of PSM

0085According to an aspect of the present application, the goal of the Power Saving Mode (PSM) feature is to reduce power consumption at the UE. A UE under PSM mode is not reachable for MT communication, however, the UE remains registered with the network and there is no need to re-attach or re-establish packet data network (PDN) connections. The PSM feature introduces a new timer called “Active Time” which indicates the time during which the UE remains reachable before going into to PSM mode. The UE starts an active timer when it attaches to the network or performs a tracking area update (TAU). When the active timer expires, the UE deactivates its Access Stratum functions and enters PSM. In PSM, due to deactivation of Access Stratum functions, the UE stops all idle mode procedures, but continues to run non-Access Stratum (NAS) timers that may apply, e.g., the periodic TAU timer.

0086In one embodiment, the SCS may influence the selection of the “Active Timer” and “Periodic TAU timer” values that the MME sends to the UE. SCS may send a new “MT data Delay Tolerance” value to the MME (via the MTC-IWF). The “MT data Delay Tolerance” value indicates how much delay is acceptable for MT data. Preferably, the Delay tolerance should be more than (periodic TAU timer—active timer).

0087In another embodiment, the SCS may also send a new “Periodicity of MT data” value to the MME. This may be used by the MME to calculate values of the Active timer and align UE IDLE mode with MT data. If the MT data transmissions are aligned with UE Active Timer and Periodic TAU Timer, then the number of device triggers required to send periodic MT data to the UE may be reduced. This can save a lot of overhead in the network.

0088In a further embodiment, the SCS may subscribe to MME to coordinate with the SCS on every TAU and attach request. The SCS can set/reset a new “PSM sync flag” to enable/disable notifications on every TAU and attach request. It is envisaged that when a SCS has knowledge of MT data transmission periodicity, the SCS may send an indication to the core network to provide the periodicity characteristics. For example, the SCS will have this information if the sensor readings will only be requested by the SCS at certain times of the day. The periodicity characteristics include the delay tolerance of MT data and periodicity of MT data. This information is forwarded to MME by MTC-IWF, which stores the SCS addresses, the periodicity of MT data, the delay tolerance, PSM sync flag, and a PSM Disable Flag in the UE context. If there are multiple SCSs providing different values, then all these values may be stored in the UE context and the MME may choose PSM values such that the UE is ‘active’ whenever one or more SCSs need to reach the UE.

0089MME can now use the periodicity characteristics from the SCS and “Active Timer” and “Periodic TAU timer” values from the UE to choose appropriate “Active Timer” and “Periodic TAU timer” values. The values will be chosen such that they are well aligned with MT data transmission. If the PSM sync flag is set to false, the MME will not send a notification to SCS on every TAU request and Attach request. If the PSM sync flag is set, then the MME also sends a notification to SCS on every TAU request and Attach request.

0090When the SCS wants to change the MT data periodicity or Delay Tolerance values, it sends the indication to MME via MTC-IWF with new values. The MME overwrites the old values with new values in UE context. If the SCS wants to withdraw these parameters, it sends an indication to MME via MTC-IWF with “Action” AVP set to “delete”. The MME deletes these values from the UE context. Deletion of these values means that the SCS does not want to influence or coordinate the PSM status of the UE. The SCS may also disable the “PSM Sync Flag” and “PSM Disable Flag” by setting their values to “Disable” in the ‘Device Characteristics Exchange Request’.

0091According to an exemplary embodiment as illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, the SCS sends the device periodicity characteristics to the MME via the MTC-IWF and over the Tsp interface. Each of the steps in <figref idref="DRAWINGS">FIG. 5</figref> is denoted by an Arabic numeral. In Step <b>1</b>, the SCS sends a Device-Characteristics-Exchange (DCE) Request command to the MTC-IWF over Tsp. The DCE Request message can have the following Information Elements (IE)s: (i) External Identifier; (ii) SCS address; and (iii) Device characteristics (which is a grouped AVP) including (a) Action—add/delete and (b) Infrequent MT including (1) a ‘Delay Tolerance value’ for MT traffic, e.g., latency for SCS initiated communication, indicating how much delay is acceptable for MT data; (2) ‘Periodicity of MT communication’ which indicates the periodicity of MT data relative to a particular time.

0092Moreover, the IEs include (iv) PSM sync flag—Enable/Disable—which indicates if the SCS is to be kept in sync about UE's PSM status; (v) PSM disable flag—True/False—which indicates the UE has to be prevented from entering PSM; and (vi) Enhanced data handling flag—Enable/disable—which indicates that the UE is a PSM capable device and that enhanced buffering at SGW and data handling at eNodeB is to be enabled for the UE.

0093According to Steps <b>2</b> and <b>3</b>, the MTC-IWF checks whether the SCS is authorized to perform this operation in the HSS. If the check fails, the MTC-IWF sends a ‘Device Characteristics Exchange’ (DCE) Answer message with a cause value indicating the reason for the failure condition and the flow stops at this step. Otherwise, the HSS sends the Subscriber Information Response (IMSI and/or MSISDN and related “Routing information” including the serving node(s) identities) message to the MTC-IWF.

0094In Step <b>4</b>, the MTC-IWF forwards the DCE message to MME. The MME adds or deletes the UE characteristics from the UE context based on the “action” in the attribute value pair (AVP) of the “Device Characteristics” grouped AVP. The MME stores the “PSM Sync flag” in UE context, when the “PSM Sync Flag” is set to “enable”. If the “PSM Sync Flag” is “disable”, it clears the flag from the UE context. Moreover, the MME also stores the “PSM disable flag” in UE context, when the “PSM disable Flag” is set to “True”. If the “PSM Disable Flag” is “false”, it clears the flag from the UE context. It also stores the “Enhanced data handling flag” in UE context, when the “Enhanced data handling Flag” is set to “Enable”. If the “Enhanced data handling flag” is “disabled”, it clears the flag from the UE context.

0095In Step <b>5</b>, the MME acknowledges to the MTC-IWF that it has successfully added/deleted device characteristics of the UE by sending a Device-Characteristics-Exchange-Answer command with result code success.

0096In Step <b>6</b>, the MTC-IWF acknowledges to the SCS that MME has successfully updated device characteristics of the UE by sending a Device-Characteristics-Exchange-Answer command with result code success. If the “Enhanced data handling flag” has been successfully set to ‘enabled’ at HSS/MME, the SCS may configure application/transport level retransmission timers to be longer than usual.

0097In an alternative embodiment, the MTC-IWF sends UE parameters to the HSS and the HSS pushes the updated parameters to the MME. In particular, the HSS adds new fields to the existing Insert-Subscriber-Data Request/Answer or Delete-Subscriber-Data Request/Answer messages. An embodiment is shown in <figref idref="DRAWINGS">FIG. 6</figref>. Each of the steps in <figref idref="DRAWINGS">FIG. 6</figref> is denoted by an Arabic numeral. In particular, Step <b>1</b> is similar to that described above in <figref idref="DRAWINGS">FIG. 5</figref>. When the SCS wants to update the device characteristics of a UE to CN, it sends a Device-Characteristics-Exchange (DCE) Request command to the MTC-IWF over Tsp. The DCE Request message can have one or more of the IEs discussed above.

0098In Step <b>2</b>, the MTC-IWF forwards the Device-Characteristics-Exchange Request command message to HSS/HLR/UDR over S6m/Ud interface.

0099In Step <b>3</b>, the HSS validates, provides authorization, and indicates that the SCS is allowed to update the UE's characteristics. The HSS makes the updates to the UE's subscription information accordingly. If validation and authorization check succeeds, then based on the “action” AVP in “Device Characteristics” grouped AVP, the HSS adds or deletes the UE characteristics from the UE profile. It stores the “PSM Sync flag” in UE subscription, when the “PSM Sync Flag” is set to “enable”. If the “PSM Sync Flag” is “disable”, it clears the flag from the UE subscription.

0100The HSS also stores the “PSM disable flag” in UE subscription. It also stores the “Enhanced data handling flag” in UE context.

0101On the other hand, if the validation and authorization check fails, the HSS sends a Device-Characteristics-Exchange Answer command message with a cause value indicating the reason for the failure condition. MTC-IWF forwards the Device-Characteristics-Exchange Answer command message with the cause value indicating the reason for the failure condition to SCS and the flow stops at this step.

0102Next, the HSS acknowledges to the MTC-IWF that it has successfully added/deleted device characteristics of the UE by sending a Device-Characteristics-Exchange-Answer command with result code success (Step <b>4</b>). In Step <b>5</b>, the MTC-IWF acknowledges to the SCS that HSS has successfully updated device characteristics of the UE by sending a Device-Characteristics-Exchange-Answer command with result code success. If the “Enhanced data handling flag” successfully has been set to “enabled” at HSS/MME, the SCS may configure application/transport level retransmission timers to be longer.

0103In a further embodiment, if the UE is attached, then the HSS may update the subscription data to the serving node (serving MME) using an ‘Insert-Subscriber-Data Request’ or a ‘Delete-Subscriber-Data Request’ (Step <b>6</b>). In Step <b>7</b>, the serving node (serving MME) acknowledges to the HSS by sending an ‘Insert-Subscriber-Data Answer’ or a ‘Delete-Subscriber-Data Answer’ command with result code success.

0104According to another alternative embodiment, the SCS may directly exchange the ‘Device-Characteristics-Exchange request/answer’ messages with the UDR/HSS over the Mh interface. The call flow and procedure for this case is similar to the protocols discussed above except the MTC-IWF will be removed and the SCS directly sends the message to the HSS and the HSS directly sends the replies to the SCS over the Mh interface.

0105In another embodiment, in the case of the User Data Convergence (UDC) architecture, the device characteristics may be written to the User Data Repository (UDR) as temporary data. The HSS FE and the MME FE can read the data characteristics directly. Also, the MME can subscribe to the device characteristics that are stored in the UDR so that the MME will be notified whenever updates are made.

MT Data Waiting—Availability Subscription

0106According to another aspect of the present application, an SCS may send a pre-trigger using existing ‘Device-Action-Request’ message to a UE. The MTC-IWF sends this request to serving MME in a new ‘Device-Availability-Subscription-Request’ message. The SCS may subscribe to MME so as to be notified when the device becomes reachable. The SCS may also set/reset a new “MT data waiting flag” in the MME to enable/disable notifications on every TAU and attach request.

0107MT Data Waiting Context refers to a context maintained by the MME for the UE, where the MME stores a MT data waiting flag, a validity timer and one or more SCS addresses. The SCS can set these parameters using a pre-trigger when SCS intends to send MT data to a UE in PSM. The MME sends UE availability notification to SCS on TAU request and attach request for the UE, which has MT data waiting flag set to true in this context.

0108In particular, the SCS uses Device Triggering protocols to transmit information to the UE via the 3GPP network to trigger the UE to perform application-specific task including initiating communication with the SCS or an AS connected to the SCS. Device Triggering is required when an IP address for the UE is not available or not known the SCS/AS.

0109In one embodiment, the device trigger message contains information that allows the 3GPP network to route the message to the right UE/device and the UE/device to route the information to the right application. The information destined to the application is referred to as the Trigger payload. The UE needs to be able to distinguish a Mobile Termination (MT) message carrying device triggering information from any other type of messages.

0110According to another embodiment, the SCS may send a validity-timer AVP with the Device-Action-Request message. The MME clears the “MT data waiting flag” after the expiry of validity-timer. After the flag is cleared, the MME does not notify the SCS on TAU request or attach request from UE. Moreover, the MME stores the SCS address, MT data waiting Flag in MT data waiting context in the UE context. If there are multiple SCSs providing different values, then all these values can be stored in the UE context.

0111If the MT data waiting flag is set, then the MME sends a notification to the SCS on every TAU request and Attach request. MME can use the SCS address to send this notification to SCS via MTC-IWF. When the SCS wants to recall/replace the trigger, it sends the indication to MME via MTC-IWF with new values. MME deletes/overwrites the old values with new values in UE context.

0112According to an exemplary embodiment as illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, a call flow for a new procedure where the SCS sends the pre-trigger to the MME via the MTC-IWF and over the Tsp interface is described. Each of the steps in <figref idref="DRAWINGS">FIG. 7</figref> is denoted by an Arabic numeral.

0113According to Step <b>1</b>, when the SCS wants to trigger a UE which may be in PSM, it sends a ‘Device-Action-Request’ (DAR) command to the MTC-IWF over Tsp. The DAR message can have the following IEs: (i) External Identifier; (ii) SCS address—SCS address is sent to the CN, this is used by the CN (MME) to send notification back to SCS; (iii) an indicator to use the pre-trigger procedure.

0114Alternatively, the SCS may send the DAR message without an indication that the pre-trigger procedure should be used. The MTC-IWF may recognize that the target UE could be in PSM and the MTC-IWF could then decide to send to proceed with the pre-trigger procedure and send the ‘Device-Availability-Subscription-Request’ to the MME.

0115In Steps <b>2</b> and <b>3</b>, the MTC-IWF checks whether the SCS is authorized to perform this operation. If this check fails, the MTC-IWF sends a ‘Device-Action-Answer’ message with a cause value indicating the reason for the failure condition and the flow stops at this step. Otherwise, the HSS sends the ‘Subscriber Information Response’ (IMSI and/or MSISDN and related “Routing information” including the serving node(s) identities, cause) message.

0116Next, in Step <b>4</b>, the MTC-IWF sends the ‘Device-Availability-Subscription-Request’ message to MME. Based on the “Action-type” AVP, the MME adds/updates/deletes the trigger parameters from the UE context. It stores the “MT data waiting Flag” in “MT data waiting context” in UE context, when the “Action-type” is set to “Device Trigger Request/Device Trigger Replace.” It also maintains a validity-timer for this trigger. If the “Action-type” is “Device Trigger Recall”, it clears the flag from the UE context.

0117In Step <b>5</b>, the MME acknowledges to the MTC-IWF that it has successfully added/deleted trigger parameters of the UE by sending a ‘Device-Availability-Subscription-Answer’ command with result code success.

0118In Step <b>6</b>, the MTC-IWF acknowledges to the SCS that MME has successfully updated trigger parameters of the UE by sending a ‘Device-Action-Answer’ command with result code success. The MTC-IWF may provide an indication in the ‘Device-Action-Answer’ to indicate that the pre-trigger procedure was used and that the MTC-IWF has subscribed to the device's availability. Additionally, if the MTC-IWF (and not the SCS) decides to use the pre-trigger procedure, then the MTC-IWF may give the SCS an indication that the trigger payload has been discarded because the pre-trigger procedure was used.

0119Preferably, the trigger information is not stored at MTC-IWF and rather stored in the serving nodes. This is in accordance with the requirement on the MTC-IWF to be a stateless entity. Also the device trigger information is stored in the MME and thus the storage requirements are distributed throughout the network. When SMS based triggering is used, all triggers are stored in a centralized location (the SMS-SC).

0120In another embodiment, when the UE performs a tracking area update, the UE comes out of PSM, and moves to a cell served by a different MME. Then the ‘MT Data Waiting’ context can also be transferred to the new MME as part of the ‘Context Transfer’ done during normal TAU. Namely, when the CN sends a notification to the SCS on TAU requests and attach requests, the SCS can immediately trigger the UE and the trigger can be delivered without any overhead to the network. Alternatively, when the CN sends a notification to the SCS on TAU requests and attach request, the SCS can immediately send the UE mobile terminated data over the user plane, i.e., over the SGi reference point.

Enhancements to TAU Procedure

0121According to another aspect of the present application, new IEs and new messages introduced in the TAU procedure for efficiently handling the PSM UEs are described. For example, in one embodiment, the TAU request may be updated to send a ‘bearer status’ to the MME. If the MME understands that the SCS wants to send MT data to the UE, the MME may use the bearer status to activate all of the bearers. The MME may also increase the UE's T3440 timer and keep it in connected state for data delivery.

0122In another embodiment, when a UE changes MME's, the context response and update location ACK messages may be updated to also contain UE device characteristics including but not limited to, “PSM sync flag”, “PSM disable flag”, “MT data waiting context” and associated SCS addresses. These new parameters are sent to the new serving MME in addition to the existing UE context from HSS/old MME.

0123In yet another embodiment, a new ‘Device Availability Notification Request/Answer’ is employed to notify and coordinate with an SCS about the UE's PSM parameters. PSM parameters refer to Active timer and Periodic TAU Timer values of a PSM UE. A PSM UE sends its PSM parameters to the MME on a TAU request or attach request if/when it intends to enter PSM mode. The MME may modify these values and send them back to UE.

0124As discussed above, the SCS may subscribe to the MME. The MME will coordinate with the SCS on every TAU and attach request. The selection criteria in the CN for the ‘Periodic TAU Timer’ and the ‘Active Timer’ may be updated with inputs (device characteristics) provided by the SCS. If the SCS has knowledge of the periodic MT data and prefers to align the UE's active timer and Periodic TAU timer with MT data periodicity, then the SCS may send these values to the MME (via the MTC-IWF) using the ‘Device-Characteristics-Exchange Request’ as previously discussed. The SCS may set “PSM sync flag” in this request, if it wants to be notified every time UE is active. If the SCS sets the “MT data waiting flag” in the CN, then the CN also sends this notification to the SCS about UE availability. The SCS will also be able to control how long the UE goes into PSM as well as how long the PSM will remain active. The SCS may also prevent the UE from going into PSM mode.

0125According to another embodiment, the SCS may also send the payload with the ‘Device Availability Notification Answer message’, when the SCS has MT data waiting and does not have UE contact information. Conversely, if the SCS has UE's contact information, it may send the data to UE via the SGi reference point after sending the ‘Device Availability Notification Answer message,’ message because the UE will be active and able to receive the MT data. If the SCS includes a payload in the ‘Device Availability Notification Answer message’ then the TAU accept may be updated to carry the small data to UE. Alternatively, the MME may deliver this payload in a NAS down link (DL) transfer message.

0126In an exemplary embodiment as shown in <figref idref="DRAWINGS">FIG. 8</figref>, protocols for enhancing the TAU are described. Each of the steps is denoted by an Arabic numeral in <figref idref="DRAWINGS">FIG. 8</figref>. In Step <b>1</b>, the UE initiates TAU procedure. Then, the UE sends the TAU request to eNodeB (Step <b>2</b>). Here, a PSM UE can be mandated to provide the EPS bearer status in the TAU request when it comes out of PSM mode to let the MME know which bearers are active in the UE. Next, the eNodeB sends the TAU request to MME (Step <b>3</b>). If the MME is a new MME and does not have the UE's context, then the new MME sends a Context Request to the old MME (Step <b>4</b>). In turn, the old MME sends the UE's context to new MME (Step <b>5</b>) Apart for the regular UE context, it will also contain UE device characteristics as previously discussed which includes one or more of an “Enhanced Data Handling Flag”, “PSM sync flag”, “PSM disable flag”, “MT data waiting flag” and associated SCS addresses.

0127Steps <b>6</b>-<b>16</b> will not be discussed in detail. Step <b>16</b> encompasses authentication/security. Step <b>7</b> illustrates a context acknowledgment between the new MME and Old MME. Step <b>8</b> illustrates create a session request from the new MME and the new SGW. Steps <b>9</b> and <b>10</b> illustrate the modify bearer request and response, respectively, between the new SGW and PGW. Step <b>11</b> illustrates create a session response from the new SGW and the new MME. Step <b>12</b> illustrates an update location between the new MME and HSS. Steps <b>13</b> and <b>14</b> illustrate a cancel location and acknowledgment, respectively, between the HSS and old MME. Steps <b>15</b> and <b>16</b> illustrate a lu Release command and lu release complete, respectively, between the eNB and new MME.

0128In Step <b>17</b>, the ‘Update Location Ack’ message on the S6a reference point is modified to transfer new parameters in the UE subscription. This message is used to send subscription information from the HSS to the MME. In order to support this feature, new subscriber data fields are provided including but not limited to new subscription fields, such as UE device characteristics, a PSM disable flag, a PSM sync flag, associated SCS addresses, and MT data waiting context. If the UE context in MME has a PSM Sync Flag enabled and/or “MT data waiting Flag” enabled in the MT data waiting context, then the MME sends a “Device Notification request” to the MTC-IWF with addresses of all SCSs to notify about the UE's connected status (Step <b>18</b>). This message may contain one or more of the following information elements: (i) UE Identity: IMSI/External ID/MSISDN; (ii) SCS Address List; (iii) Active Timer: The current value of the active timer stored in MME for the specific UE; (iv) Periodic TAU timer: The current value of the periodic TAU timer stored in the MME for the specific UE; and (v) Cause: TAU Request.

0129Thereafter in Step <b>18</b>, the MTC-IWF forwards the ‘Device Availability Notification Request’ to the SCS. The MTC-IWF may change the UE identity, e.g., IMSI or MSISDN, etc., to an External ID using HSS Enquiry or by checking information cached in the MTC-IWF. MTC-IWF derives the device reachable duration and device non-reachable duration from received active timer and periodic TAU timer values. The MTC-IWF also maps the received cause value to the set of cause values that can be understood by the SCS. This message may contain one or more of the following information elements: (i) External Identifier; (ii) Type: Information Message/Request message; (iii) Device reachable duration: calculated by MTC-IWF; (iv) Device non-reachable duration: calculated by MTC-IWF and (v) Reason. Moreover, the MTC-IWF sends the Device Availability Notification Request message to all the SCS in the SCS Address List and starts a guard timer.

0130Next in Step <b>20</b>, the SCSs respond to the MTC-IWF with a ‘Device Availability Notification Answer’. The SCS, upon receiving the PSM parameters, compares them with the existing values and checks if the values need to be modified. Namely, expected M2M data traffic and application scenarios may be considered for modifying values. Based on the PSM parameters, the SCS may also schedule the MT data traffic to match the UE's state transitions. The modified device reachable and non-reachable duration may be suggested in the ‘Device Availability Notification Response’ message. The ‘Device Availability Notification Response’ message contains one or more of the following information elements: (i) Proposed Device reachable duration; (ii) Proposed Device non-reachable duration; and (iii) PSM disable flag—True/False—indicates the UE has to be prevented from entering PSM. SCS can also send the payload with this message, when SCSs wants to trigger the UE.

0131In Step <b>21</b>, the MTC-IWF waits for the responses from the SCSs. It then collects all of the responses and calculates the new active timer and periodic TAU timer using all received device reachable and non-reachable duration from different SCS and constructs the response with the following information elements: (i) UE Identity: IMSI/External ID/MSISDN; (ii) Proposed Active Timer: value of the active timer calculated at the MTC-IWF; and (iii) Proposed Periodic TAU timer. The MME considers the values proposed by the SCS and either recalculates new values or accepts the suggested values. If the message carries a payload, which can be delivered through NAS signalling at MME, then the MTW-IWF also forwards the payload to MME in “Device Availability Notification Answer” message.

0132In Step <b>22</b>, the MME makes its decisions based upon the following parameters (i) Periodic TAU Timer; (ii) Active Timer; and (iii) T3440 Timer. The following considerations are made. The first consideration is whether the timer request made by the UE in TAU Request. The second consideration is whether the device characteristics information provided by the SCS as per the updates was performed using the ‘Device Characteristics Exchange’. The third consideration is whether the ‘Device Notification Answer’ was received from the SCS. The ‘active timer’ may be chosen based on the highest value provided and the ‘periodic TAU timer’ may be based on the lowest value provided. Fourth, the MME may decide whether to increase the ‘T3440 Timer’ and keep the UE in connected mode for MT data or to increase the ‘Active timer’ and keep the UE in IDLE mode (listening for paging) based on a configured threshold that is determined to be efficient for UE battery consumption.

0133Steps <b>23</b> and <b>25</b> discuss deletion of session request protocols. In Step <b>24</b>, the MME sends a TAU accept to the UE. Here, the MME sends the “Periodic TAU Timer”, “Active Timer” and “T3440 Timer” previously calculated in Step <b>22</b>. If required, the MME may prevent the UE from going into PSM mode (based on a request from the SCS) by providing an ‘Active Timer’ value of ‘FFFF’ (a reserved value). If there SCS indicates that there is no pending data, then the UE may be instructed to immediately go into PSM by providing an ‘Active Timer’ value of ‘0’. In Step <b>26</b>, a TAU complete message is sent from the UE to the new MME. In an alternative embodiment, ‘small data transmissions’ are sent from the new MME to the UE as part of the ‘Tau Accept’ message. The MME may also indicate that the eNodeB should perform special data handling for the UE if “Enhanced data handling flag” is set to “Enabled” in the UE context. If this flag is sent to eNodeB, then eNodeB may configure the data bearers in a special way (e.g. use RLC AM mode for the data bearers, use lower order modulation scheme, etc.) to increase the chances of successful data delivery to the UE and reduce the chances that a retransmission will be required. This can also help to reduce chances of application level retransmissions from SCS.

0134Next, in Step <b>27</b>, the MME may alternatively perform the ‘small data transmissions’ as part of NAS DL transfer message. MME determines if bearer activation is needed. After TAU Accept the MME can establish the data bearers by initiating an ‘S1-AP Initial Context Setup Request’ when there is a downlink data (DDN message).

Attach Procedure Changes

0135According to another aspect of the application changes are proposed to the Attach procedure. Namely, when a UE attaches, the MME may check with the SCS and then make its decision about providing the ‘Active Timer’ and the ‘Periodic TAU Timer’ based on the SCS inputs and the device characteristics received from the SCS in “Device characteristics Exchange Request”. In an exemplary embodiment, <figref idref="DRAWINGS">FIG. 9</figref> illustrates the call flows for the Attach procedure. Each of the steps is denoted by an Arabic numeral in <figref idref="DRAWINGS">FIG. 9</figref>. In Step <b>1</b>, the Attach request is sent to the eNodeB. The attach request is forwarded from the eNodeB to the new MME in Step <b>2</b>. Steps <b>3</b>-<b>6</b> encompass identification requests between the UE, eNodeB, new MME and an old MME. Steps <b>7</b>-<b>10</b> describe prompts for deleting session requests.

0136In Step <b>11</b>, the ‘Update Location Ack message’ on the S6a reference point is modified to transfer new parameters in the UE subscription. This message is used to send subscription information from the HSS to the MME. To support this feature, new subscriber data fields are employed as previously discussed in this application. These include one or more of the new subscription fields, such as UE device characteristics, Enhanced data handling Flag, PSM disable flag, PSM sync flag and its associated SCS addresses and MT data waiting context.

0137Steps <b>12</b>-<b>16</b> describe the creation of a session request. In Step <b>17</b>, the MME sends an ‘Initial Context Setup Request/Attach accept’ to the UE. The MME sends the “Periodic TAU Timer”, “Active Timer” and “T3440 Timer.” These calculations are similar to those discussed in Step <b>22</b> of <figref idref="DRAWINGS">FIG. 8</figref>. If the Enhanced data handling Flag is set to enable, then MME also sends this flag to the eNodeB in a new information element. If this flag is sent to the eNodeB, then the eNodeB can configure the data bearers in a special way, e.g., use RLC AM mode for the data bearers, use lower order modulation scheme, etc., to increase the chances of successful data delivery to the UE and reduce the chances that a retransmission will be required. This can also help to reduce chances of application level retransmissions from SCS.

0138In Step <b>18</b>, the radio resource control (RRC) connection is employed from the eNodeB to the UE. Steps <b>19</b>-<b>22</b> describe transfer steps between the UE and new MME. Step <b>23</b> and <b>24</b> describes the Bearer modification between the new MME and the Serving GW. Steps <b>25</b> and <b>26</b> describe the notification request/response between the new MME and the SCS.

0139In Step <b>27</b>, if the UE context in MME has “PSM Sync Flag” enabled and/or “MT data waiting Flag” enabled, then the MME sends “Device Availability notification request” to MTC-IWF with addresses of all SCSs to notify about the UE's connected status. It may have an AVP indicating the cause of initiation, which is “Attach request.” Steps <b>28</b>-<b>31</b> are similar to those described above in Steps <b>19</b>-<b>22</b>, respectively, of <figref idref="DRAWINGS">FIG. 8</figref>.

Enhancements to S1 Release Procedure

0140According to another aspect of the present application, techniques are described whereby the MME is capable of notifying the SCS/AS when a UE moves from a CONNECTED to IDLE state during the 51. This approach allows the SCS/AS to suggest to the MME whether to delay or advance PSM transitions. This may depend upon the needs of the M2M Application. This may also help the SCS to keep in sync about when the UE enters in and out of PSM state.

0141It is further proposed that the PSM parameters typically transferred to the UE during Attach or TAU procedure may now also be transferred during the 51 Release procedure. In particular, new messages are introduced on the T5b and Tsp interfaces to inform the SCS about the UEs IDLE or PSM transitions. Moreover, the CN may decide on the PSM parameter, i.e., Active Timer and Periodic TAU timer, based upon the SCS proposed time durations and the reason that caused the S1 release. The CN passes the PSM parameters to the eNodeB using the enhanced UE Context Release Command message. In addition, the RRC Connection Release message is enhanced to carry the PSM parameters provided by the CN. This creates a means of transferring PSM parameters to the UE not only during Attach/TAU but also during S1 Release procedure.

0142In an exemplary embodiment, as shown in <figref idref="DRAWINGS">FIG. 10</figref>, enhancements to the S1 Release Procedure call flow are described. Each of the steps in <figref idref="DRAWINGS">FIG. 10</figref> is denoted by an Arabic numeral.

0143In Step <b>1</b>, according to some scenarios, the eNodeB may release the UE's RRC connection before requesting the MME for S1 context release. Next, the eNodeB initiates the S1 Release procedure by sending the UE Context Release Request S1AP message (Step <b>2</b>).

0144Then MME decides to inform the SCS about the UE's state change based on the criteria below (Step <b>3</b>). The first criteria is whether the “PSM Sync Flag’ has been set in the UE's mobility context at the MME as previously discussed. The second criteria is whether the UE has been marked for PSM activation based on UE's power preference indication or as determined by the CN based on statistical data collection as previously discussed. The MME composes the ‘Device Availability Notification Request’ message and sends it to the MTC-IWF over the T5b interface. This message contains the following information elements: (i) UE Identity: IMSI/External ID/MSISDN; (ii) SCS Address List: This may be a list of SCS identifiers or a list of SCS IP Addresses; (iii) Active Timer: The current value of the active timer stored in MME for the specific UE; (iv) Periodic TAU timer: The current value of the periodic TAU timer stored in MME for the specific UE; and (v) Cause: The S1 Release cause as indicated by the eNodeB or the cause for which the MME decides to release the S1 connection.

0145The MME may start a timer to time-out if the SCS/MTC-IWF response takes too long. If the SCS delays the response beyond this time, the MME can proceed with the rest of the S1 Release procedure with the PSM parameters that are currently stored in the UE's context. If the response from the SCS reaches after the guard timer, then the MME may consider the PSM parameters provided by the SCS during the next TAU or Attach Procedure. If the PSM parameters provided by the SCS are critical, e.g., if the SCS wants to prevent the UE from entering PSM, than the MME may initiate paging, e.g., to a single last known eNodeB, to provide the new PSM parameters.

0146In Step <b>4</b>, the MTC-IWF constructs a new message ‘Device Availability Notification Request’ using the incoming message parameters and sends it to the SCS over Tsp interface. MTC-IWF may change the UE identity, e.g., IMSI or MSISDN, etc., to External ID using HSS Enquiry or by checking information that is stored in MTC-IWF cache. MTC-IWF derives device reachable duration and device non-reachable duration based on the received active timer and periodic TAU timer values. The MTC-IWF also maps the received cause value to the set of cause values that can be understood by the SCS. The ‘Device Availability Notification Request’ message that is sent from MTC-IWF to SCS contains one or more of the following information elements: (i) External Identifier; (ii) Type: Information Message/Request message; (iii) Device reachable duration calculated by MTC-IWF; (iv) Device non-reachable duration calculated by MTC-IWF and (v) Cause. The MTC-IWF fans out the ‘Device Availability Notification Request’ message to all the SCS mentioned in the SCS Address List sent by the MME.

0147In Step <b>5</b>, the SCS upon receiving the PSM parameters checks if the values need to be modified. The expected M2M data traffic, the received reason, and the needs of the M2M application may be considered in this decision. Based on the PSM parameters, the SCS may schedule the MT data traffic to match the UE's state transitions. New Device reachable and non-reachable duration may be suggested in the ‘Device Availability Notification Answer’ message. This message may contain one or more of the following information elements: (i) Proposed Device reachable duration; (ii) Proposed Device non-reachable duration; (iii) PSM disable flag—True/False—indicates the UE has to be prevented from entering PSM or not.

0148According to Step <b>6</b>, the MTC-IWF waits for the responses from all the SCS. It then collects all the responses and calculates the new active timer and periodic TAU timer using all received device reachable and non-reachable duration from the different SCS's and constructs the response to the MME with the following information element: (i) UE Identity: IMSI/External ID/MSISDN; (ii) Proposed Active Timer: value of the active timer calculated at the MTC-IWF; (iii) Proposed Periodic TAU timer. MME will consider the values proposed by the SCS and either recalculates new values or accepts the suggested values.

0149According to Steps <b>7</b> and <b>8</b>, the MME initiates the release of all activated bearers with the SGW. The SGW releases all the bearers and sends an acknowledgment to the MME. The bearers protocols were discussed above.

0150In Step <b>9</b>, the MME sends the PSM Parameters to the eNodeB in ‘UE Context Release Command’. The new information element ‘PSM Parameter’ is included in the ‘UE Context Release Command’ SLAP message. The PSM Parameters IE will carry the new active timer and periodic TAU timer. Next, the eNodeB sends the received PSM Parameters to the UE in the RRC Connection Release message by adding the new Information element ‘PSM Parameters’ which carries the active timer and periodic TAU Timer (Step <b>10</b>). Next, the eNodeB sends ‘UE Context Release Complete’ S1AP message to MME and indicates whether the PSM Parameters are passed to the UE by including a new information element ‘PSM Parameters passed to the UE’ flag (Step <b>11</b>).

0151Further in Step <b>12</b>, the MME checks for ‘PSM Parameters passed to the UE’ flag in ‘UE Context Release Complete’ S1AP message and if the flag is “FALSE”, MME may decide to page the UE to send the new PSM Parameters. The Paging procedure may be initiated by the MME only if the MME finds that there is a benefit in passing the PSM Parameters to the UE. For example, if there is no substantial change in the PSM timer values, the MME may skip the paging procedure. Also if the S1 release was triggered by the eNodeB for congestion reasons, the MME might skip the paging procedure. Once the Paging and Service Request procedures are complete, the PSM Parameters are passed to the UE using one of the below mentioned approaches described below.

0152In one approach, upon finishing Service Request procedure, the UE state transitions to the CONNECTED state and the PSM parameters are transmitted in the downlink data message. In another approach, the PSM Parameters may be transmitted to the UE as an SMS. In a further approach, the Service Request procedure is skipped and the PSM parameters are passed to the UE during paging procedure. After receiving Paging request message, the UE sends the RRC Connection Setup request message to the eNodeB. The eNodeB could be made intelligent to remember that the paging was done to transmit PSM parameters and hence sends RRC Connection Release message to the UE along with the PSM Parameters. Transmitting the PSM parameters to the UE is thus accomplished even though the Paging procedure fails.

Network Initiated PSM

0153In yet another aspect of the present application, protocols whereby the Core Network (MME) knows the PSM capability of a UE/Device are described. Namely, the UE gives more control to the network by making it aware of its PSM capability and thereby allowing the network to perform any network initiated procedures. In particular, the UE Radio Capability Information is stored in the MME when the UE is in ECM IDLE state. By so doing, the UE doesn't have to transmit this information to the eNodeB every time it transits information or a message from the ECM IDLE to ECM CONNECTED state. Instead, the eNodeB fetches this information from the MME.

0154According to an embodiment, the UE Radio Capability information stored in the MME could be enhanced to contain an additional information element called the ‘PowerSaveMode’. The ‘PowerSaveMode’ IE indicates whether the UE is PSM capable and thus allowing the network to make decisions on moving the UE to PSM state. The ‘UE Capability Information’ RRC message and the ‘UE Capability Info Indication’ S1AP message are enhanced to carry this new information element from the UE to the MME.

0155According to another embodiment, the CN enables PSM for the UE that indicates low power consumption preference in the UE Assistance Information. If the UE indicates a low power consumption preference during RRC Connection Reconfiguration, the network may consider it as an indication to move the UE to PSM state. This would eventually help the UE to consume less battery power since it's AS functionalities are turned off during PSM.

0156The UE Assistance Information carrying the low power information to the eNodeB is forwarded to the CN at any time during the CONNECTED state, thus making the CN aware of the UE's power preferences. A new S1AP message ‘UE Preference Indication’ is introduced to carry the power preference value to the MME. The MME, upon receiving the message, checks the PSM supported flag and decides whether the PSM could be enabled for the UE or not. If the UE's subscription information indicates there is no PSM feature supported, then this message is ignored.

0157In an exemplary embodiment as shown in <figref idref="DRAWINGS">FIG. 11</figref>, a call flow is provided for UE assistance information to indicate low power preference. Each of the steps is denoted by an Arabic numeral. In Step <b>1</b>, if the eNodeB sets the ‘powerPrefindicationConfig’ IE to setup in otherConfig of RRC Connection Configuration/Re-Configuration as mentioned in 36.331 and UE supports power preference indication, the UE may transmit UE Assistance Information with power preference set too Low to eNodeB. Then in Step <b>2</b>, the eNodeB composes a new S1AP message ‘UE Preference Indication’ with ‘low power consumption requested’ enumerated value and sends the message to MME. The MME checks the UE subscription details to see if the PSM feature is supported for the UE. The MME may further co-ordinate with the SCS to share the PSM parameters during Attach, TAU or S1 Release procedure.

0158As described below in Table 2, UE preference indication of S1AP messages is provided. Here, the IE/Group Name includes, for example, Message Type, MMM UE S1AP ID, and eNB UE S1AP ID.

0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="105pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 2</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>IE/Group Name</entry><entry>Presence</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Message Type</entry><entry>M</entry></row><row><entry /><entry>MME UE S1AP ID</entry><entry>M</entry></row><row><entry /><entry>eNB UE S1AP ID</entry><entry>M</entry></row><row><entry /><entry>Low Power Consumption</entry><entry>M</entry></row><row><entry /><entry>Requested</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0159If the UE does not request an Active timer in the TAU or Attach procedure, or during the S1 Release procedure, the MME may consider the statistical data collected by monitoring ECM state changes. This may include an input to request the SCS for PSM Parameters and activate PSM for the UE. Examples of statistical data include the times of UE state changes, when the UE sends and receives data, etc. The statistical analysis is done at MME only if the network supports PSM feature for the particular UE otherwise no statistical data is collected or analysed.

0160According to another embodiment, a UE application might control its PSM settings via a new AT command interface modification, to allow the application layer or the OS in the UE to influence the ‘Active Timer’ value and the ‘periodic TAU Timer’ value that the UE modem requests in the Attach or TAU procedures. Here, the ‘R’ interface between the TE and MT on the UE may be updated with new AT commands to enable control of the PSM feature from an application. If the UE wishes to use PSM, it may provide an intended value for the ‘Active Timer’ and the ‘Periodic TAU timer’ in the Attach or TAU request. The assumption is that the UE may ask for a ‘Periodic TAU timer’ that is slightly greater than its periodic data communication (if any) and the ‘Active timer’ value would allow for any MT data to be delivered. The periodic time value and expected MT data time are determined by the application layer. In particular, a new protocol describes ‘PSM Push’ informs the MT about the application's preferred ‘Active Timer’ value and the ‘periodic TAU Timer’ value. The MT can use these values whenever it sends Attach Request or TAU request to CN. If there are multiple applications, the MT can choose the appropriate values based on inputs from all applications. MT may choose maximum value from all the active timer values provided by applications. MT may also choose the lowest TAU timer value of all the TAU timer values provided by applications.

CN Optimizations for ‘Low Mobility’ Devices

0161According to another aspect of the present application, the CN may be configured with information about when and if the UE is expected to be mobile. This section proposes the optimizations at the CN based on the mobility parameters of a particular UE/Device shared by the SCS. The nature of some M2M devices is that they are either stationary or have a limited mobility. For example, a M2M device installed in a street light is stationary and a M2M device installed in a temperature/pressure sensor within an industry remains within a fixed boundary. This particular ‘low mobility’ characteristic of a UE/Device could be leveraged to provide optimizations in the network.

0162In one embodiment, the SCS may pass the device characteristics information to the CN using the ‘Device Characteristics Exchange (DCE)’ message as discussed earlier in this application. The CN stores the device characteristics in the UE subscription information and uses them in the Attach, TAU and Paging procedures. The Device Characteristics Exchange message may be extended with the below mentioned information element to support sharing of mobility characteristics. For example, Device Characteristics (grouped AVP and may 1 or more instances may be present) may include the following aspects of Device Mobility: (i) Mobility status—STATIONARY, MOBILE_WITHIN_A_BOUNDARY; (ii) Mobility status flag—Enabled, Disabled; (iii) Duration—Duration for which the UE would stay in the mentioned mobility status; and (iv) Mobility radius—a value in meters which is applicable if mobility status is stationary.

0163According to another embodiment, enhancements to the Attach and TAU procedure to assign tracking area ID (TAI) List for UE based on the ‘low mobility’ characteristic are described. The network may also provide an ECGI List which may be used for more granular tracking and paging. An ECGI list identifies the particular cells that the UE can camp on in ‘IDLE’ mode without informing the MME by performing a normal tracking area update. When a UE registers to a network, the MME allocates a set of tracking areas to the UE and provides the TAI List in Attach Accept (TAU Accept in case of TAU procedure). The TAI List contains a list of TAs which is close to the UEs current location. The UE does not perform tracking area update procedure while it is moving within the TAs provided in the TAI list.

0164In addition, the Mobility Status information element contains values which indicate whether the UE is stationary or can roam within a boundary. The Mobility Status flag indicates whether the Mobility Status mentioned is currently valid. For example, when a M2M device installed in a shipping container reaches a warehouse, the respective application server might indicate to the SCS that the Mobility Status is now stationary and set the Mobility Status flag to Enabled. When the shipment starts to move, the Mobility Status flag is set to Disabled. The Duration field could also be used to indicate how long a Mobility Status field is valid. Upon the expiry of duration time, the Mobility Status flag is set to Disabled. The Mobility radius field indicates the roaming area of the M2M device. This parameter is useful for the MME to decide the TAs on which the device may be reachable.

0165Moreover, when the UEs for which the mobility status and mobility radius is known by the SCS, the SCS shares this information in the DCE message with the MME. The MME stores this information in the subscription details and uses them to provide a minimal TAI List which covers specific TAs instead of giving a full TAI List served by the MME.

0166The MME may also provide an ECGI List based on Mobility Status and Mobility Radius during Attach or TAU procedures. By providing the ECGI list, the MME has more control and granularity on where the UE is located and this could be used to optimize paging procedure. If the UE moves beyond the provided ECGI list, it triggers TAU procedure. This may also be employed to inform the SCS that the UE has moved beyond the range provided and may invoke any application level functionalities. For example, the SCS can indicate the Mobility Status for a UE as STATIONARY and Mobility Radius set to 100 meters. Then the MME can allocate an ECGI List with one or two cell IDs. Alternatively, if the Mobility Status is set as ‘MOBILE_WITHIN_A_BOUNDARY’ and Mobility Radius is set to 5,000 meters, then the MME could deduce a TAI list which covers the UE's roaming region and share it with the UE instead of sharing the entire TAI List served by the MME. Table 3 below indicates the new information element ECGI List to be passed in the Attach Accept NAS message. Moreover, the TAU Accept message is also enhanced to include the ECGI List information element shown in Table 4 below.

0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="98pt" align="left" /><colspec colname="2" colwidth="63pt" align="center" /><colspec colname="3" colwidth="42pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" rowsep="1">TABLE 3</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Information Element</entry><entry>Presence</entry><entry>Format</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Protocol discriminator</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>Security header type</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>Attach accept message identity</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>EPS attach result</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>Spare half octet</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>T3412 value</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>TAI list</entry><entry>M</entry><entry>LV</entry></row><row><entry /><entry>ESM message container</entry><entry>M</entry><entry>LV-E</entry></row><row><entry /><entry>GUTI</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>Location area identification</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>MS identity</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>EMM cause</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>T3402 value</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>T3423 value</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>Equivalent PLMNs</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>Emergency number list</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>EPS network feature support</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>Additional update result</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>T3412 extended value</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>ECGI List</entry><entry>O</entry><entry>LV</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0000<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="91pt" align="left" /><colspec colname="2" colwidth="63pt" align="center" /><colspec colname="3" colwidth="49pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" rowsep="1">TABLE 4</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Information Element</entry><entry>Presence</entry><entry>Format</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Protocol discriminator</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>Security header type</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>Tracking area update accept</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>message identity</entry></row><row><entry /><entry>EPS update result</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>Spare half octet</entry><entry>M</entry><entry>V</entry></row><row><entry /><entry>T3412 value</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>GUTI</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>TAI list</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>EPS bearer context status</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>Location area identification</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>MS identity</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>EMM cause</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>T3402 value</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>T3423 value</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>Equivalent PLMNs</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>Emergency number list</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>EPS network feature support</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>Additional update result</entry><entry>O</entry><entry>TV</entry></row><row><entry /><entry>T3412 extended value</entry><entry>O</entry><entry>TLV</entry></row><row><entry /><entry>ECGI List</entry><entry>O</entry><entry>LV</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Paging Optimizations

0167According to a further aspect of the application, optimizations for the paging procedure based on the enhancements during Attach and TAU procedure are described. For a stationary UE which is in IDLE state, the MME can do paging only for specific TAs and not on the actual TAI List that the MME serves. Also for UEs that are mobile and which stay within a particular boundary, the MME could deduce a smaller TAI List which results in the reduction of unnecessary signalling on all other eNodeBs of the TAI List.

0168According to one embodiment, the MME uses the stored TAI List and/or ECGI List which was generated during Attach or TAU procedure during paging. The SLAP Paging Request message sent from the MME towards the UE may be enhanced to include a new information element called the ECGI List. Table 5 below highlights the new IE sent in the paging message.

0000<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="49pt" align="center" /><colspec colname="3" colwidth="77pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" rowsep="1">TABLE 5</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>IE/Group Name</entry><entry>Presence</entry><entry>Range</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Message Type</entry><entry>M</entry><entry>—</entry></row><row><entry /><entry>UE Identity Index value</entry><entry>M</entry><entry>—</entry></row><row><entry /><entry>UE Paging Identity</entry><entry>M</entry><entry>—</entry></row><row><entry /><entry>Paging DRX</entry><entry>O</entry><entry>—</entry></row><row><entry /><entry>CN Domain</entry><entry>M</entry><entry>—</entry></row><row><entry /><entry>List of TAIs</entry><entry>—</entry><entry>1</entry></row><row><entry /><entry>>TAI List Item</entry><entry>—</entry><entry>1 . . . <maxnoofTAIs></entry></row><row><entry /><entry>>>TAI</entry><entry>M</entry><entry>—</entry></row><row><entry /><entry>CSG Id List</entry><entry>—</entry><entry>0 . . . 1</entry></row><row><entry /><entry>>CSG Id</entry><entry>—</entry><entry>1 . . . <maxnoofCSGId></entry></row><row><entry /><entry>Paging Priority</entry><entry>O</entry><entry>—</entry></row><row><entry /><entry>List of ECGI</entry><entry>—</entry><entry>1</entry></row><row><entry /><entry>>ECGI List Item</entry><entry>—</entry><entry>1 . . . <maxnoofECGIs></entry></row><row><entry /><entry>>>ECGI</entry><entry>O</entry><entry>—</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0169In a further aspect of the present application, updated to the service request procedure for supporting enhanced buffering and data handling for PSM capable UEs are described. In particular, new IEs are introduced in the Downlink Data Notification Acknowledge for supporting enhanced data handling for PSM capable UEs, e.g., constrained devices. Downlink Data Notification Acknowledge may be updated to include the “Enhanced data handling” Flag to the SGW. If the MME finds that the UE is in PSM mode and the “Enhanced data handling Flag” is set to “Enabled” in UE context, MME can indicate to SGW for buffering the UE data for a longer time is desired in order to avoid application level retransmissions by SCS.

0170In an exemplary embodiment as shown in <figref idref="DRAWINGS">FIG. 12</figref>, a network initiated service request call flow is described. Each of the steps is denoted by an Arabic numeral. In Step <b>1</b>, the Downlink Data is received at a S-GW from a PDN GW. Downlink Data notification is made to the MME in Step <b>2</b><i>a</i>. In Step <b>2</b><i>b</i>, if the UE is in PSM mode and Enhanced data handling Flag is “Enabled”, the MME (or SGSN) may send Downlink Data Notification Acknowledge with “Enhanced data handling” Flag set to Enabled to SGW. The MME (or SGSN) may also send the timer value in a new information element, to indicate the amount of time for which the data has to be buffered. If the UE is expected to be in PSM mode for 20 minutes, the MME (or SGSN) can send 20+ minutes of time to SGW. On receiving this flag and the timer, SGW may decide to buffer the UE's data for specified time to avoid application level retransmissions. Notably, when the UE is in PSM mode, the subsequent steps may not be executed. Steps <b>3</b><i>a</i>-<i>b </i>and <b>4</b><i>a</i>-<i>b </i>refer to Paging protocols ultimately to the leading to the UE. Step <b>5</b> relates to a Service Request Procedure. Steps <b>6</b><i>a</i>-<i>b </i>refer to the Stop Paging protocol.

0171According to another aspect of the present application, new IEs are introduced in the S1-AP Initial Context Setup request for supporting enhanced data handling for PSM capable UEs (constrained devices). In one embodiment, the 1-AP Initial Context Setup request may be updated to include the “Enhanced data handling Flag” to eNodeB. If the MME finds that “Enhanced data handling Flag” is set to “Enabled” in UE context, MME may indicate to the eNodeB that special handling of the UE data is required to avoid application level retransmissions by SCS.

0172In an exemplary embodiment as illustrated in <figref idref="DRAWINGS">FIG. 13</figref>, UE triggered service request procedures are described. Each step is denoted by an Arabic numeral. After the NAS service request has been transmitted to the MME from the UE and authenticated (Steps <b>1</b>-<b>3</b>), the S1-AP initial context setup request (Step <b>4</b>) is performed. Here, the S1-AP Initial Context Setup request can be updated to include “Enhanced data handling” Flag to the eNodeB. If the MME finds that “Enhanced data handling Flag” is set to “Enabled” in the UE context, the MME can indicate this to eNodeB. If this flag is sent to eNodeB, then eNodeB can configure the data bearers in a special way, e.g., use RLC AM mode for the data bearers, use lower order modulation scheme etc.) to increase the chances of successful data delivery to the UE and reduce the chances that a retransmission will be required. This can also help to reduce chances of application level retransmissions from SCS.

0173According to an alternative embodiment, two new QCI values, say 10 for GBR bearers and 11 for non-GBR bearers, may be introduced. When a PSM capable UE attaches to the network, this new QCI 10 or 11 is used for its bearers, when special data handling is desired for these devices. When a UE is in PSM mode and the downlink data is received at SGW, the SGW may send a DDN message to MME and the MME may respond with timer value for buffering data. The SGW may then buffer the data for desired time based on the timer value provided by MME and also the based on the new QCI value associated with the bearer.

0174When the PSM capable UE is connected, the eNodeB may perform special data handling for the bearers with new QCI values (10 or 11), e.g., using RLC AM mode for the data bearers, using lower order modulation scheme, etc., to increase the chances of successful data delivery to the UE. This can help to reduce the likelihood of application level retransmissions from the SCS.

0175According to another alternative embodiment, when a UE is in PSM mode and the downlink data is received at SGW, the SGW sends a DDN message to the MME and the MME may respond with timer value for buffering data. Additionally MME may indicate the amount of data that it can buffer at MME. If the data received and buffered at SGW is within the data limit indicated by MME, the SGW may forward the data to the MME. The data gets buffered at the MME in this case and can be later delivered using NAS DL transfer message over the SRBs. If MME relocation is required when data is buffered at the MME, the buffered data may also be transferred to the new MME with the Context Transfer procedure.

LWM2M Embodiment

0176A LWM2M client may include resources that indicate the state, or level, of the client's battery. The LWM2M server may send an observe request to the LWM2M client to indicate that the server should be notified when the battery reaches a certain level. When the client notifies the server of the battery level, the server may inform the client that it is permitted to sleep for a longer time period in order to conserve energy. According to an aspect of the present application, the LWM2M Client's “Connectivity Monitoring” object may be updated with a new resource called “Max Sleep Time”. The server may use this new resource to indicate to the client how long it is permitted to sleep and be unavailable for mobile terminated communications. The LWM2M Client may use this “Max Sleep Time” value to configure its PSM settings when it performs a Tracking area update.

0177In an exemplary embodiment as illustrated in <figref idref="DRAWINGS">FIG. 14</figref>, LWM2M Server Requests that the Client Adjust its PSM Settings is described by the call flows. Each of the steps is denoted by an Arabic numeral. In Step <b>1</b>, the SCS uses the M2M Interface to send power and sleep preferences to the LWM2M Server for the client. The SCS may choose to send this message when the UE registers with the SCS or it may choose to modify the Power/Sleep preferences based on some event such as a new application being started, etc. Next, the LWM2M Server acknowledges the preferences (Step <b>2</b>). Thereafter, the LWM2M Server asks the client to notify the server when the battery level reaches a certain level (Step <b>3</b>). Then, the client notifies the Server that the battery has reached a certain level (Step <b>4</b>).

0178Based on the battery level, the LWM2M server informs the client that it is permitted to sleep for some maximum amount of time (Step <b>5</b>). For example, the client may be told that it is permitted to go into sleep mode for up to 20 minutes. During sleep mode, the client may not be reachable for mobile terminated communications. Next, the Client may send a response to the server indicating that it's “Max Sleep Time” resource has been updated (Step <b>6</b>). Thereafter, the Client (UE) will do a tracking area update and provide the MME with an Active Time and TAU Timer that are calculated based on the “Max Sleep Time” that was provided in step <b>5</b> (Step <b>7</b>). For example, if a “Max Sleep Time” of 20 minutes was provided in step <b>5</b>, then the UE may choose an Active Time of 5 minutes and a TAU Timer of 25 minutes. The LWM2M client may be configured to use an AT command to inform the protocol stack of the desired Active Time and TAU Time. Further, the MME may indicate that it accepts the TAU and new timer values (Step <b>8</b>).

0179In an alternative embodiment, if the LWM2M Server has an interface with the core network, then the LWM2M server may use its interface with the core network to request that the UE's PSM settings be adjusted. For instance, <figref idref="DRAWINGS">FIG. 15</figref> illustrates call flows whereby the LWM2M server requests that the SCS adjust the client's PSM settings. Each of the steps in <figref idref="DRAWINGS">FIG. 15</figref> is denoted by an Arabic numeral. First, the LWM2M Server asks the client to notify the server when the battery level reaches a certain level (Step <b>1</b>). Then, the client notifies the Server that the batter has reached a certain level (Step <b>2</b>). Next, the LWM2M Server sends a request to an SCS requesting that the device's maximum sleep time be adjusted (Step <b>3</b>). According to Steps <b>4</b>-<b>7</b>, the SCS uses the device characteristics update procedure as discussed earlier in this application. Thereafter, the SCS acknowledges the LWM2M Server's request to adjust the UE's sleep time (Step <b>8</b>). Subsequently, the Client (UE) requests a tracking area update (Step <b>9</b>). Lastly, the MME provides the UE with an Active Time and TAU Timer that are calculated based on the “Max Sleep Time” provided in Step <b>3</b>. For example, if a “Max Sleep Time” of 20 minutes was provided in step <b>3</b>, then the MME may choose an Active Time of 5 minutes and a TAU Timer of 25 minutes. It is noted that Steps <b>3</b> and <b>8</b> above may take place on the M2M Interface between the SCS and the LWM2M Server.

0180According to the present application, it is understood that any or all of the systems, methods and processes described herein may be embodied in the form of computer executable instructions, e.g., program code, stored on a computer-readable storage medium which instructions, when executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above may be implemented in the form of such computer executable instructions. Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, but such computer readable storage media do not includes signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium which can be used to store the desired information and which can be accessed by a computer.

0181According to yet another aspect of the application, a non-transitory computer-readable or executable storage medium for storing computer-readable or executable instructions is disclosed. The medium may include one or more computer-executable instructions such as disclosed above in the plural call flows according to <figref idref="DRAWINGS">FIGS. 6-15</figref>. The computer executable instructions may be stored in a memory and executed by a processor disclosed above in <figref idref="DRAWINGS">FIGS. 4C and 4D</figref>, and employed in devices including UEs, HSSs and SCSs. In one embodiment, a computer-implemented UE having a non-transitory memory and processor operably coupled thereto, as described above in <figref idref="DRAWINGS">FIGS. 4C and 4D</figref>, is disclosed. Specifically, the non-transitory memory has instructions stored thereon for controlling a power savings mode characteristic of a device on the network. The processor is configured to perform the instructions of: (i) receiving a request to update the characteristics of the device on the network; and (ii) updating the characteristic of the device based upon the request; and (iii) sending an acknowledgement that the characteristic has been updated.

0182In another embodiment, the non-transitory memory includes instructions stored thereon for controlling a power savings mode characteristic of a device on the network. The processor is configured to perform the instructions of: (i) receiving a tracking area update or an attach request from the device on the network; (ii) sending a device availability notification request to a core network interworking function or a service capability server; and (iii) receiving a device availability notification answer from the interworking function or the service capability server.

0183In yet another embodiment, the non-transitory memory includes instructions stored thereon for supporting buffering and data handling for a power savings mode of a device on the network. The processor, operably coupled to the non-transitory memory, is configured to perform the instructions of: (i) receiving a downlink data notification from a serving gateway; (ii) determining the device is in power saving mode and that an enhanced data handling flag is enabled; and (iii) sending a downlink data notification acknowledgment to the serving gateway including the enhanced data handling flag.

0184While the systems and methods have been described in terms of what are presently considered to be specific aspects, the application need not be limited to the disclosed aspects. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the claims, the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structures. The present disclosure includes any and all aspects of the following claims.