WO2018060543A1

WO2018060543A1 - SUPPORT FOR MOBILE ORIGINATED SHORT NOTIFICATION PROCEDURE FOR IoT DEVICES

Info

Publication number: WO2018060543A1
Application number: PCT/FI2017/050571
Authority: WO
Inventors: Parijat BHATTACHARJEE; Shalini Gulati
Original assignee: Nokia Technologies Oy
Priority date: 2016-09-30
Filing date: 2017-08-14
Publication date: 2018-04-05

Abstract

An apparatus comprises: at least one processor; and at least one non-transitory memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving a status indication/exception report from a user equipment, the status indication/exception report being based on a resume request message; verifying the status indication/exception report; if successfully verified, attempting to validate the status indication/exception report; and if successfully validated, responding with an acknowledgment/resume message; wherein the RRC states on both the user equipment and the apparatus are maintained in RRC_IDLE for the duration of the procedure.

Description

SUPPORT FOR MOBILE ORIGINATED SHORT NOTIFICATION PROCEDURE FOR

IoT DEVICES BACKGROUND Technical Field

The exemplary and non-limiting embodiments described herein relate generally to radio access networks and, more particularly, to apparatuses and methods for optimizing signaling loads for IoT devices in a radio access network.

Brief Description of Prior Developments

Internet of Things (IoT) devices use network connectivity to enable various physical elements embedded with electronics, software, sensors, and actuators to collect and exchange data. Methods of employing such network connectivity generally involves embedding both downlink (DL) and uplink (UL) traffic within initial handshake messages. Such methods are generally incapable of handling larger data transfers from and to the IoT device .

SUMMARY The following summary is merely intended to be exemplary. The summary is not intended to limit the scope of the claims.

In accordance with one exemplary aspect, an apparatus comprises: at least one processor; and at least one non-transitory memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving a status indication/exception report from a user equipment, the status indication/exception report being based on a resume request message; verifying the status indication/exception report; if successfully verified, attempting to validate the status indication/exception report; and if successfully validated, responding with an acknowledgement/resume message. The RRC states on both the user equipment and the apparatus are maintained in RRC_IDLE for the duration of the procedure.

In accordance with another exemplary aspect, a method comprises: receiving, at a network, a status indication/exception report from a user equipment in radio communication with the network, the status indication/exception report being based on a resume request message; verifying the status indication/exception report; if successfully verified, attempting to validate the status indication/exception report; and if successfully validated, responding with an acknowledgement/resume message. The RRC states on both the user equipment and the apparatus are maintained in RRC_IDLE for the duration of the procedure.

In accordance with another exemplary aspect, an apparatus comprises: means for receiving a status indication/exception report from a user equipment, the status indication/exception report being based on a resume request message; means for verifying the status indication/exception report; if successfully verified, means for attempting to validate the status indication/exception report; and if successfully validated, means for responding with an acknowledgement/resume message. The RRC states on both the user equipment and the apparatus are maintained in RRC_IDLE for the duration of the procedure . BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and other features are explained in the following description, taken in connection with the accompanying drawings, wherein:

Figure 1 is a schematic representation of one exemplary embodiment of an IoT device and various monitoring options;

Figure 2 is a schematic representation of one exemplary embodiment of a flow for a mobile originated short notification procedure for an IoT device;

Figure 3 is a schematic representation of one exemplary embodiment of a flow for a an exception report for an IoT device;

Figure 4 is a schematic representation of one exemplary embodiment of a flow for a method illustrating proposed impacts at an eNB in a radio access network;

Figure 5A is a schematic representation of one exemplary embodiment of a flow illustrating states of an IoT device and an eNB; and

Figure 5B is a schematic representation of idle and connected states of the IoT device and device context on the network of Figure 5A.

DETAILED DESCRIPTION OF EMBODIMENT

Referring to the Figures, exemplary embodiments of IoT devices, methods, and systems directed to the operation of IoT devices in radio access networks are shown. The exemplary devices, methods, and systems provide a mobile-originated secure, small data transfer capability with optimal signaling. The IoT devices include a wide range of sensors, actuators, and other electronic elements that communicate with each other over a network and exchange data (for example, as smart components in vehicles, buildings, medical applications, animal tracking, and the like) . The data can then be utilized to provide improved services. As per some estimates, the number of IoT devices deployed in such networks could be as high as 50 billion by the year 2020. Each of these IoT devices is expected to have a battery life of 10 years.

Given the number of IoT devices projected to be deployed over time, it may be beneficial to optimize signaling requirements for such devices in order to reduce network loads. The exemplary embodiments disclosed herein assume use cases for IoT devices for sending alerts or exception reports to a network. For such cases, the IoT devices may not need to transmit excessive amounts of data. However, whatever data is transmitted may be received by the network and processed. The network may then transmit the data to IoT infrastructure (e.g., dashboards or the like) for further processing.

In the exemplary embodiments disclosed herein, one specific use case applicable to a wide number of IoT devices is a Critical Battery Level Alert. However, the exemplary embodiments described herein are not limited to a Critical Battery Level Alert, as other specific use cases may fall within the scope of the disclosed methods and systems. In particular, the signaling flow described with regard to the embodiments herein may be considered generic and extensible to other use cases that involve sending a critical status update or a notification to the infrastructure from an IoT device. The exemplary embodiments as described herein are directed to optimizing signaling load for IoT devices on a network side. At the same time, the network should be able to provide a means for an IoT device to send out an exception report (such as an authenticated critical alert) with minimal battery drain. A vast majority of IoT devices will be small, with limited battery supply and possibly no power connectivity. While the services that deploy these devices are expected to track and maintain them as well, with 50 billion devices being deployed, it is quite likely that once a battery of a device is drained, locating and servicing the device may be difficult. This may pose an environmental hazard at some point even if a small fraction of these (proposed) 50 billion devices are misplaced and forgotten since each of these will likely have an alkaline battery that should be properly disposed of. The apparatuses and methods of the exemplary embodiments disclosed herein are intended to foresee and address this issue and to provide one or more solutions that may help a network operator provide a green/eco-friendly service to device owners in an effort to ensure that out-of-service devices can be located and removed, replaced, or maintained.

In the exemplary embodiments disclosed herein, a second specific use case applicable to a wide number of IoT devices relates to the expectation that the IoT devices are intended for use in services such as metering and exception reporting. Since extended battery life of an IoT device is desired and expected in many cases, installers of such devices may forget to change the batteries on time without a notification from the device or a network, apparatus, or other system in which the device is installed .

Thus, the second specific use case addresses service continuity. It does so by ensuring that the device batteries are changed in time and preventing the device battery from completely draining in the first place. In general, this application can be extended to applications such as medical applications (the reporting of irregular heartbeat, vital signs exceeding a predetermined limit, etc.), fire detection, intruder alerts, and the like. Referring to Figure 1, a system showing a number of options for a user to monitor an IoT device is designated generally by the reference number 100 and is hereinafter referred to as "system 100." In system 100, the IoT device (shown at 110) is configured to provide notifications 120 to the user (shown at 130, e.g., an owner of the IoT device 110), and the user 130 may provide service 140 to the IoT device 110. The service 140 to the IoT device 110 may be, for example, the administration of any suitable maintenance to the IoT device 110 (such as, e.g., battery changes and the like) . In some embodiments, particularly when battery changes are performed, the service 140 may involve a site visit by the user 130 to replace the battery. In other embodiments, the service may involve the initiation of a message to an alarm monitoring entity to signal the possible presence of fire or an intruder.

The system 100 comprises a cell site 150 and a mobile switching center 160 linked by a mobile backhaul 170. The cell site 150 may comprise pluralities of small cells 155 making up macrocells. Various types of small cells 155 include femtocells, picocells, microcells, and relays, which generally operate under mobile technology standards using protocols such as GSM, CDMA, TD-SCDMA, LTE, LTE-A, 5G, and the like. The small cells 155 may be linked to a radio/edge cloud 175. An IoT dashboard service may be monitored by a first IoT dashboard 180 configured for edge computing and/or cloud computing. For example, the IoT dashboard service may be hosted by an existing network element and may provide operations and maintenance (O&M) services for the IoT devices. A similar dashboard can be used to monitor the network as well. The mobile backhaul 170 carries voice and data traffic between the radio cloud 175 and the mobile switching center 160. The mobile switching center 160 (which may include a home subscriber server (HSS) , an IP multimedia subsystem (IMS), a network management system (NMS) , and/or an evolved packet core (EPC) . The IoT dashboard service may be provided by a second IoT dashboard 185 (which can be hosted by an existing network element that may provide O&M services for IoT devices) using existing network elements. The mobile switching center 160 may be linked to a signaling gateway interface 190 (SGi 190) and the IoT dashboard service may be provided by a third IoT dashboard 195 hosted on the web or a web cloud using existing network elements.

The user 130 has the option of monitoring the IoT device 110 via the first IoT dashboard 180, the second IoT dashboard 185, the third IoT dashboard 195, or a combination thereof. Monitoring via the first IoT dashboard 180 may be based on edge computing and/or cloud computing. In using the first IoT dashboard 180, control messaging may be minimal since any status update is made over a local breakout. In using the second IoT dashboard 185, the monitoring is based on existing infrastructure. For example, control messaging and context activation may be employed in additional network elements. In using the third IoT dashboard 195, IoT monitoring is through the SGi 190 and is based on a web/web cloud.

Referring now to Figure 2, one exemplary embodiment of a sample flow for an asynchronous start of a mobile originated short notification procedure is shown generally at 200 and is hereinafter referred to as "notification procedure 200." In the notification procedure 200, a short notification is initiated at an IoT device 210 or other type of a user equipment (UE) . The IoT device 210 may have or be associated with a controller 212 having a memory 214, a processor 216, and a sensor 218. The IoT device 210 selectively transmits a status indication/exception report 220 (e.g., a "resume request" message) to a network (eNB 230) or other apparatus via an uplink (UL) . The eNB 230 may have or be associated with a controller 232 having a memory 234 and a processor 236. The status indication/exception report 220 is selectively transmitted (if and when required) . An RRC state on both the IoT device 210 and the eNB 230 is maintained in RRC_IDLE (280) . An optional acknowledgement 240 is returned to the IoT device 210. The IoT device 210 exits a power saving mode 270 (PSM 270) for the duration of the short notification procedure. The PSM 270 operates independently of the RRC state. The IoT device 210 moves to the PSM 270 when there is no message to transmit or receive. Because the IoT device 210 does not exit the PSM 270 unless required, battery draw by the IoT device 210 is minimized and signaling loads on the network by the IoT device 210 are optimized. The notification procedure 200 may utilize a random access channel (RACH) as defined by current standards, but it proposes to modify the RESUME message to send the status indication. Furthermore, the use of the RESUME procedure/message instead of a specific preamble sequence may provide a secure method for status indication and protect the system from rogue IoT devices.

Referring now to Figure 3, one exemplary embodiment of a sample flow for a mobile originated critical/short notification procedure for an IoT device associated with a controller having a memory and a processor is shown generally at 300 and is hereinafter referred to as "notification 300." Notification 300 may be built on top of current 3GPP procedures. In particular, it is assumed that an IoT device 310 as a UE has been attached to a network (eNB 330, having a controller having a memory and a processor) and then moved to a radio resource control idle (RRC- IDLE) state. Since most IoT devices are expected to be stationary devices in PSM and in RRC-IDLE state for extended periods of time, the IoT device 310 may be registered on the network and a minimal context will be available at the eNB 330, thus providing for an optimal configuration by minimizing the load to the eNB 330. This minimal context enables the IoT device 310 to resume an earlier session using a "RESUME ID." This reduces the authentication/authorization overhead when the IoT device 310 wishes to resume the RRC connection and move to an RRC CONNECTED state. As shown, the notification 300 builds on top of a typical flow for resuming the RRC connection and optimizes by not changing the RRC state when sending short notifications in the IoT case. The existing procedure can coexist and still be utilized by IoT devices when sending larger amounts of data.

In the notification 300, the IoT device 310 may be capable of sending out a "chirp" on reaching a critical battery level. A "chirp" procedure is generally as simple as possible to reduce battery drain and to optimize signaling overhead. The chirp may contain a unique identification tag for the IoT device 310. Such an identification tag may be the "RESUME ID" from current standards. The chirp may also contain an optional field indicating the GPS location of the IoT device 310 if the IoT device 310 knows this information and such information has not been already pre-configured in any database pertaining to the IoT device 310. For IoT devices that do not know their GPS location, the relevant GPS locations may be communicated during normal operation or may be fed into the database on the network side at the time of installation and mapped to the unique identification tag of the IoT device. On receiving the chirp, the eNB 330 may classify the IoT device 310 in accordance with a list of devices for either maintenance or retrieval. The IoT device 310 may remain in this list and not be purged even if the IoT device 310 powers off, until the alarm is cleared by the owner of the IoT device 310 or other authorized user.

From a radio perspective, any mechanism employed to transmit the chirp may be substantially robust. The chirp may be unacknowledged to conserve battery of the IoT device 310 and to reduce signaling overhead on the network.

The network may maintain a database of unique identification tags for the locations of each "chirped" IoT device 310. The "status" from the chirp is updated in this database assuming multiple status cases are supported. Such information can be provided to other applications/OTT (over-the-top) operators for maintenance of the IoT devices 310 as a service.

The network may provide a notification to an installer of the IoT device 310 or such could be based on a query from the user. The notification based system is one use case for IoT devices 310 that support critical services such as critical battery level alert as described with regard to the present embodiment. However, while the presently-described embodiment specifies the case for critical battery level alert, the optimized signaling described herein can also be considered for several other IoT scenarios that utilize a notification to be urgently sent over a network with minimal overhead.

The "critical battery level" (CBL) is user-configurable at the time of installation of the IoT device 310. The CBL can be set to trigger an alarm when the battery is depleted to a percentage of the battery life based on accessibility (in terms of the power required to ensure that the transmission reaches the network) , reliability of the battery, estimated time required to replace the battery, and the like. For example: (i) an IoT device 310 that is easily accessible for maintenance can have the CBL set to 5%; (ii) an IoT device 310 that is difficult to access can have the CBL set to 20%; or (iii) an IoT device 310 that provides some critical exception reporting and is difficult to access could have the CBL set at 30%.

Procedures for clearing the alarm of the IoT device 310 (e.g., through a dashboard) can be based on different mechanisms depending on the underlying service being provided. Exemplary underlying services provided include, but are not limited to: (i) a user clears the alarm manually after checking the IoT device 310 and attending to the cause of the alarm (e.g., replacing the battery); (ii) the IoT device 310 clears the alarm itself once the triggering cause is removed by piggy backing on a regular procedure instead of using the critical procedure; and (iii) a timer-based option is employed on the network side to clear the alarm automatically on expiry of a timer (to reduce messaging further) . In implementing the notification 300, the IoT device 310 is attached to the eNB 330 and is in the RRC-IDLE state, as indicated at 335. A mobility management entity 340 (MME 340) and a serving gateway 345 (SGW 345) are associated with the IoT device 310 and the eNB 330. A first message (MSG1) is transmitted from the IoT device 310 to the eNB 330 using a RACH preamble 350. A second message (MSG2) is then transmitted from the eNB 330 to the IoT device 310 based on a random access response 355 (RAR 355) . A third message (MSG3) is then transmitted from the IoT device 310 back to the eNB 330 based on an RRC connection resume request NB 360. The eNB 330 may use a resume identification tag 365 to forward the MSG3 to either the MME 340 or an application-server/database, which may result in a push notification to the user, based on capabilities of the application. Optionally, a fourth message (MSG4) may be returned to the IoT device 310 for contention resolution 370 based on various options 385. In an acknowledgement mode of the options 385, the procedure may be repeated from MSG1 onwards until the contention resolution 370 (MSG4, if used) passes, with a backoff as per RACH procedure for the contention resolution. In the alternative, the MSG4 may be not acknowledged (either the IoT device 310 assumes that the transmission of the MSG1, MSG2, and MSG3 is always successful, or the IoT device 310 repeats the transmission of the MSG1, MSG2, and MSG3 a configurable number of times ) .

The standards have defined a "RESUME ID" in the RRC Connection Resume Request-NB message. This may have sufficient information for authenticating a device that is already registered on the network and remains in an idle state 390. One exemplary embodiment serving as an example for LTE indicates:

RRCCotmectitmResumeRequest-fiB message

Furthermore, the Establishment Cause-NB information element indicates : EstabtlshmentCause-NB information elemetil

i iS

Moreover, the RRC Connection Resume-NB information element indicates :

RRCConne tiouResume-NB message

However, in exemplary embodiments that implement the short notification procedures as described herein, various changes to the existing 3GPP standards for NB-IoT devices are proposed with regard to impacts at the eNB 230, 330. In particular, in MSG3, the "spare4" and the "ResumeCause" may be modified to "moIoTShortNotification . " When a message is received with "ResumeCause" set to "moIoTShortNotification, " a conditional IE "loTShortNotificationCauses" is expected to be present. The "loTShortNotificationCauses" may include a cause

"moCblAlertIndication" to indicate a critical battery level condition on an IoT device 210, 310 (in embodiments in which critical battery level is determined) . In embodiments in which a condition other than critical battery level is determined, a different suitable cause may be substituted. Irrespective of the cause, the length of this field can be decided based on how many such cases/causes are foreseen in the future. On receiving the RRC Connection Resume Request-NB message at the eNB 230, 330, the "ResumeCause" is set to

"moIoTShortNotification. " The eNB 230, 330 may then verify the "RESUME ID" as per existing procedures.

If the eNB 230, 330 "RESUME ID" verification is successful, then the eNB 230, 330 then validates the presence and value of the "loTShortNotificationCauses" conditional IE. On successful validation, the eNB 230, 330 may, as an option, forward the "loTShortNotificationCauses" to the MME re-using the current procedure as appropriate and optionally, the eNB 230, 330 can directly forward the "loTShortNotificationCauses" to a different entity such as an application-server/database that is specifically configured for this or other similar services. In embodiments in which the eNB 230, 330 is configured to support "loTShortNotificationCauses - acknowledged mode," the eNB 230, 330 may respond with MSG4 : Contention Resolution as per existing procedure with a "SUCCESS" cause, and the eNB 230, 330 may then terminate the procedure. However, in embodiments in which the eNB 230, 330 is configured to support

"loTShortNotificationCauses - unacknowledged mode," then the eNB 230, 330 may terminate the procedure with no response to the IoT device 210, 310. Furthermore, in a successful verification, on validation failure for the presence of or value range for

"loTShortNotificationCauses , " if the eNB 230, 330 is configured to support "loTShortNotificationCauses -acknowledged mode," then the eNB 230, 330 may respond with MSG4 : Contention Resolution as per existing procedure with a "FAILURE" cause. For this, the RRC Connection Resume message may include a new, optional "Cause" field that can be set to success/failure, and the eNB 230, 330 may terminate the procedure. However, in embodiments in which the eNB 230, 330 is configured to support "IoTShortNotificationCauses - unacknowledged mode," then the eNB 230, 330 may terminate the procedure with no response to the IoT device 210, 310.

Also, if the eNB 230, 330 "RESUME ID" verification is successful, the IoT device 210, 310 RRC state maintained by the network remains unchanged as RRC IDLE. On the other hand, if the "RESUME ID" verification fails, the eNB 230, 330 may discard the message. In this case no response is sent to the IoT device 210, 310 irrespective of the " IoTShortNotificationCauses" mode (acknowledged/unacknowledged) set at the eNB 230, 330.

It should be noted that in the short term, ResumeCause "spare4" may directly indicate "moCblAlertlndication" with no conditional IE "IoTShortNotificationCauses" field added (there may be a software-only update to test the critical battery level feature and to demonstrate the efficacy of this suggested method) .

Referring now to Figure 4, a method illustrating the proposed impacts at the eNB of the network, as described above, is shown generally at 400 and is hereinafter referred to as "method 400." In method 400, the "RESUME ID" is verified as indicated in block 420. A determination is made in block 425 as to whether the verification is successful. If the verification is not successful, the eNB discards the message, as indicated in block

430, and no response is sent to the UE (IoT device) . If the verification is successful, a determination made as to whether

"IoTShortNotificationCauses" was received as indicated in block

431. If it was not received, then an existing resume procedure is followed as indicated in block 433. If it was received, there is an attempt to validate the presence of or value range for "loTShortNotificationCauses, " as indicated in block 435. In block 440, an assessment is made as to whether the validation is successful. If the validation is not successful, a determination is made, in block 445, as to whether the eNB is configured to support "loTShortNotificationCauses - acknowledged mode." For an unsuccessful validation and if the acknowledgement is supported, a "MSG4 : Failure" is transmitted as indicated at block 450, the RRC Connection Resume message shallinclude a new, optional "Cause" field that can be set to success/failure, as indicated in block 455, and control is passed to a terminate block 460. If, on the other hand, in making the determination in block 445 it is determined that the eNB does not support "loTShortNotificationCauses - acknowledged mode," then the control passes to a terminate block 465 and no response is made to the UE (IoT device) .

If, from the block 440, the validation is successful, the "loTShortNotificationCauses" is forwarded as indicated in block 470. A determination is then made in block 475 as to whether the "loTShortNotificationCauses - acknowledged mode" is supported. If so, then a "MSG4 : Success" is received as indicated at block 480, and control is passed to the terminate block 460. If the "loTShortNotificationCauses - acknowledged mode" is not supported, then the control passes to the terminate block 465.

If control is passed to and terminated in block 460, the RRC state maintained by the network remains unchanged as RRC IDLE, as indicated in block 490.

In exemplary embodiments that implement the short notification procedures as described herein, various changes to the existing standards may also be made with regard to impacts at the IoT device 210, 310. From a standards perspective, the IoT device 210, 310 may be required to support: (i) the IoT device 210, 310 may be capable of supporting existing flows that support using "RESUME ID" during RRC IDLE to RRC CONNECTED transitions (as part of this new proposed procedure, the IoT device 210, 310 may remain in the RRC IDLE state); (ii) in addition, the IoT device 210, 310 may be capable of sending the RRC Connection Resume Request-NB message to the eNB 230, 330 with "ResumeCause" set to "moIoTShortNotification"; (iii) the IoT device 210, 310 may be capable of supporting the conditional field

" loTShortNotificationCauses" and may populate this as per the allowed values for "IoTShortNotificationCauses"; and (iv) the IoT device 210, 310 may be capable of supporting the acknowledged mode or the unacknowledged mode as configured on the eNB 230, 330.

To support the critical battery level feature in particular, the IoT device 210, 310 or the application running on such a device may need to support some additional requirements such as: (i) the IoT device 210, 310 may support a critical battery level parameter that indicates when an alert should be sent to the eNB 230, 330 (this parameter may be set during manufacturing or may be a configurable parameter); (ii) the IoT device 210, 310 may be capable of monitoring its own battery level and comparing it against a provisioned critical battery level value; (iii) if the IoT device detects that the battery level is less than or equal to a provisioned critical battery level, the IoT device may invoke the "moIoTShortNotification" procedure; and (iv) the IoT device 210, 310 may note that it has transmitted the "moCblAlertIndication" to the eNB 230, 330 already (this may ensure that the IoT device 210, 310 does not send repeated alerts due to fluctuations in battery level due to periods of inactivity) .

Referring to Figure 5A, the RRC states on both the IoT device 210 and the eNB 230 are maintained in RRC_IDLE for the duration of the procedure. As can be seen, over the duration of the short notification procedure, the IoT device 210 is out of PSM for as short a time as possible, namely, from MSG1 to MSG3 in the unacknowledged mode and from MSG1 until MSG4 is received in the acknowledged mode.

Referring to Figure 5B, the RRC_IDLE state is maintained on both the IoT device 210 and the eNB 230 via a modified resume procedure when the short notification is sent/received whereas they are moved to an RRC_CONNECTED state under a normal resume procedure .

The exemplary embodiments disclosed herein may be used in various eNB products. The exemplary embodiments disclosed herein may also provide additional functionality on the MME and further provide possible additional elements for databases, etc., depending upon how the exemplary embodiments are implemented . Referring now to all of the Figures described herein, any of the foregoing exemplary embodiments may be implemented in software, hardware, application logic, or a combination of software, hardware, and application logic. The software, application logic, and/or hardware may reside in the network or any associated component of the network. If desired, all or part of the software, application logic, and/or hardware may reside at any other suitable location. In an example embodiment, the application logic, software, or an instruction set is maintained on any one of various computer-readable media. A "computer- readable medium" may be any media or means that can contain, store, communicate, propagate, or transport instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

In one exemplary embodiment, an apparatus comprises: at least one processor; and at least one non-transitory memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving a status indication/exception report from a user equipment, the status indication/exception report being based on a resume request message; verifying the status indication/exception report; if successfully verified, attempting to validate the status indication/exception report; and if successfully validated, responding with an acknowledgment/resume message; the RRC states on both the IoT device and the eNodeB being maintained in RRC_IDLE for the duration of the procedure. In the apparatus, receiving a status indication/exception report from a user equipment may comprise receiving the status indication/exception report on an uplink from the user equipment transmitting data using a random access procedure. Attempting to validate the status indication/exception report may comprise validating a presence of or a value range for an "loTShortNotificationCauses" instruction. The apparatus may be further caused to forward the "loTShortNotificationCauses" instruction to one or more of a mobility management entity and an application-server/database . Responding with an acknowledgment/resume message may minimize a signaling load on the apparatus. Receiving a status indication/exception report from a user equipment may comprise receiving a battery level alert of the user equipment, receiving a report of an intruder, receiving a report of a fire, receiving a report of a medical condition of a patient, receiving a report of a water level, receiving a report of seismic activity, receiving a vehicle operational status report, or receiving a temperature alert, etc. The status indication/exception report may comprise a field containing a GPS location of the user equipment stored and subsequently retrievable. The apparatus may be further caused to classify the user equipment with a list of devices for either maintenance or retrieval. The apparatus may be further caused to maintain a database of unique identification tags for each user equipment.

In another exemplary embodiment, a method comprises: receiving, at a network, a status indication/exception report from a user equipment in radio communication with the network, the status indication/exception report being based on a resume request message; verifying the status indication/exception report; if successfully verified, attempting to validate the status indication/exception report; and if successfully validated, responding with an acknowledgement/ resume message to allow the user equipment to maintain an idle state.

Receiving, at a network, a status indication/exception report from a user equipment in radio communication with the network may comprise receiving the status indication/exception report on an uplink from the user equipment. Validating the status indication/exception report may comprise validating a presence of or a value range for an "loTShortNotificationCauses" instruction. The method may further comprise forwarding the "loTShortNotificationCauses" instruction to one or more of a mobility management entity and an application-server/database. The method may further comprise responding with an acknowledgment/resume message to allow the user equipment to maintain an idle state. Receiving a status indication/exception report from a user equipment may comprise receiving a battery level alert of the user equipment, receiving a report of an intruder, receiving a report of a fire, receiving a report of a medical condition of a patient, receiving a report of a water level, receiving a report of seismic activity, receiving a vehicle operational status report, or receiving a temperature alert, etc. The method may further comprise storing a field containing a GPS location of the user equipment and making the location of the user equipment available on the network. Making the location of the user equipment available on the network may comprise at least one of making data pertaining to the location of the user equipment available when the user equipment is not accessible by a user or the network and making data pertaining to the location of the user equipment available to a third party using an application program interface. The method may further comprise responding with an additional acknowledgment/resume message to allow the user equipment to maintain an idle state.

In another exemplary embodiment, an apparatus comprises: means for receiving a status indication/exception report from a user equipment, the status indication/exception report being based on a resume request message; means for verifying the status indication/exception report; if successfully verified, means for attempting to validate the status indication/exception report; and if successfully validated, means for responding with an acknowledgement/resume message; the RRC states on both the IoT device and the eNodeB being maintained in RRC_IDLE for the duration of the procedure.

It should be understood that the foregoing description is only illustrative. Various alternatives and modifications can be devised by those skilled in the art. For example, features recited in the various dependent claims could be combined with each other in any suitable combination ( s ) . In addition, features from different embodiments described above could be selectively combined into a new embodiment. Accordingly, the description is intended to embrace all such alternatives, modifications, and variances which fall within the scope of the appended claims .

Claims

1. An apparatus, comprising:

at least one processor; and

at least one non-transitory memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform:

receiving a status indication/exception report from a user equipment, the status indication/exception report being based on a resume request message;

verifying the status indication/exception report;

if successfully verified, attempting to validate the status indication/exception report; and

if successfully validated, responding with an acknowledgement/resume message;

wherein the RRC states on both the user equipment and the apparatus are maintained in RRC_IDLE for the duration of the procedure .

2. The apparatus of claim 1, wherein receiving a status indication/exception report from a user equipment comprises receiving the status indication/exception report on an uplink from the user equipment.

3. The apparatus of claim 1 or 2, wherein responding with an acknowledgement/resume message comprises receiving data using a random access procedure; wherein the RRC states on both the IoT device and the apparatus are maintained in RRC_IDLE for the duration of the procedure.

4. The apparatus of any of claims 1 through 3, wherein attempting to validate the status indication/exception report comprises validating a presence of or a value range for an "loTShortNotificationCauses" instruction.

5. The apparatus of claim 4, further comprising forwarding the "loTShortNotificationCauses" instruction to one or more of a mobility management entity and an application-server/database.

6. The apparatus of any of claims 1 through 5, wherein forwarding an additional acknowledgement/resume message minimizes a signaling load on the apparatus; wherein the RRC states on both the IoT device and the apparatus are maintained in RRC_IDLE for the duration of the procedure.

7. The apparatus of any of claims 1 through 6, wherein receiving a status indication/exception report from a user equipment comprises receiving a battery level alert of the user equipment, receiving a report of an intruder, receiving a report of a fire, receiving a report of a medical condition of a patient, receiving a report of a water level, receiving a report of seismic activity, receiving a vehicle operational status report, or receiving a temperature alert.

8. The apparatus of claim 7, wherein the status indication/exception report comprises a field containing a GPS location of the user equipment stored and subsequently retrievable .

9. The apparatus of any of claims 1 through 8, wherein the apparatus is further caused to classify the user equipment with a list of devices for either maintenance or retrieval.

10. The apparatus of claim 8, wherein the apparatus is further caused to maintain a database of unique identification tags for each user equipment.

11. A method, comprising:

receiving, at a network, a status indication/exception report from a user equipment in radio communication with the network, the status indication/exception report being based on a resume request message;

verifying the status indication/exception report;

if successfully validated, responding with an acknowledgement/resume message; wherein the RRC states on both the user equipment and the apparatus are maintained in

RRC_IDLE for the duration of the procedure.

12. The method of claim 11, wherein receiving, at a network, a status indication/exception report from a user equipment in radio communication with the network comprises receiving the status indication/exception report on an uplink from the user equipment .

13. The method of claim 11 or 12, wherein attempting to validate the status indication/exception report comprises validating a presence of or a value range for an "loTShortNotificationCauses" instruction.

14. The method of claim 13, further comprising forwarding the "loTShortNotificationCauses" instruction to one or more of a mobility management entity and an application-server/database.

15. The method of any of claims 11 through 14, further comprising responding with an acknowledgement/resume message while minimizing signaling load; wherein the RRC states on both the IoT device and the apparatus are maintained in RRC_IDLE for the duration of the procedure.

16. The method of any of claims 11 through 15, wherein receiving a status indication/exception report from a user equipment comprises receiving a battery level alert of the user equipment, receiving a report of an intruder, receiving a report of a fire, receiving a report of a medical condition of a patient, receiving a report of a water level, receiving a report of seismic activity, receiving a vehicle operational status report, or receiving a temperature alert.

17. The method of claim 16, further comprising storing a field containing a GPS location of the user equipment and making the location of the user equipment available on the network.

18. The method of claim 17, wherein making the location of the user equipment available on the network comprises at least one of making data pertaining to the location of the user equipment available when the user equipment is not accessible by a user or the network and making data pertaining to the location of the user equipment available to a third party using an application program interface.

19. The method of any of claims 11 through 15, further comprising forwarding an additional acknowledgement/resume message to allow the user equipment to maintain an idle state using transmitted data in a random access procedure.

20. An apparatus, comprising: means for receiving a status indication/exception report from a user equipment, the status indication/exception report being based on a resume request message;

means for verifying the status indication/exception report; if successfully verified, means for attempting to validate the status indication/exception report; and

if successfully validated, means for responding with an acknowledgement/resume message; wherein the RRC states on both the user equipment and the apparatus are maintained in RRC_IDLE for the duration of the procedure.