Improvements in and relating to methods to toggling IoT device states

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present disclosure provides a method performed by an ambient internet of things (AIoT) device in a wireless communication system. The method comprises: receiving, from a network, a request message indicating a target state of the AIoT device, wherein the target state indicating mode of operation for the AIoT device; transitioning a current state of the AIoT device to the target state of the AIoT device, based on the request message, in case that the current state of the AIoT device is different from the target state of the AIoT device; and transmitting, to the network, a response message indicating a result of an operation performed based on the request message.

Description

IMPROVEMENTS IN AND RELATING TO METHODS TO TOGGLING IOT DEVICE STATES

[0001] The present disclosure relates to the wireless communication systems. Particularly, the present disclosure relates to methods and apparatus for managing operational states and modes of Ambient Internet of Things (AIoT) devices.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] The present disclosure relates to providing a method for defining and managing AIoT device states and modes, enabling network-controlled and application function-triggered transitions without relying on traditional RRC states.

[0009] One or more shortcomings discussed above are overcome, and additional advantages and features are provided by the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the disclosure.

[0010] In an embodiment, a method performed by an ambient internet of things (AIoT) device in a wireless communication system is disclosed. The method comprises: receiving, from a network, a request message indicating a target state of the AIoT device, wherein the target state indicating mode of operation for the AIoT device; transitioning a current state of the AIoT device to the target state of the AIoT device, based on the request message, in case that the current state of the AIoT device is different from the target state of the AIoT device; and transmitting, to the network, a response message indicating a result of an operation performed based on the request message.

[0011] In another embodiment, an ambient internet of things (AIoT) device in a wireless communication system is disclosed. The AIoT device comprises: memory; transceiver; and at least one processor, coupled to the transceiver, configured to: receive, from a network, a request message indicating a target state of the AIoT device, wherein the target state indicating mode of operation for the AIoT device; transition a current state of the AIoT device to the target state of the AIoT device, based on the request message, in case that the current state of the AIoT device is different from the target state of the AIoT device; and transmit, to the network, a response message indicating a result of an operation performed based on the request message.

[0012] The foregoing solution is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

[0013] The present disclosure relates to providing a method for defining and managing AIoT device states and modes, enabling network-controlled and application function-triggered transitions without relying on traditional RRC states.

[0014] For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which:

[0015] Figure 1 shows an illustration of states or modes of operation according to an embodiment of the disclosure;

[0016] Figure 2 shows a message flow illustrating an embodiment of the disclosure;

[0017] Figure 3 is a block diagram illustrating a structure of a UE according to an embodiment of the disclosure; and

[0018] Figure 4　is a block diagram illustrating a constitution of a network entity according to an embodiment of the disclosure.

[0019] It should be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0020] The 3GPP organisation has agreed a study item for Rel-19 which relates to Ambient Internet of Things (AIoT) devices. AIoT devices can be battery-less or with limited energy storage capability (i.e., using a capacitor) and the energy is provided through the harvesting of radio waves, light, motion, heat, or any other power source that could be seen suitable.

[0021] The following are architectural assumptions that have been agreed:

[0022] "- The following traffic types for Ambient IoT device are to be studied:

[0023] - DT: Device-terminated; and

[0024] - DO-DTT: Device-originated - device-terminated triggered.

[0025] NOTE 1: The final decision for including DO-A (Device-originated - autonomous) in the study depends on RAN decision.

[0026] - The following two connectivity topologies as defined in TR 38.848[X5] are to be studied:

[0027] - Topology 1: BS ↔ Ambient IoT device;

[0028] - Topology 2: BS ↔ intermediate node ↔ Ambient IoT device: Only a UE can act as an intermediate node which is under the network control.

[0029] - The communication spectrum is assumed to be licensed.

[0030] - Handover is not supported.

[0031] - RRC states are not supported by AIoT Devices (see RAN SID[x])

[0032] - No mobility (i.e. at least no cell selection / re-selection-like function) supported by AIoT Devices (see RAN SID[x])

[0033] Editor's note: The RAN SID reference is to be updated to RAN TR when available, and the meaning of no mobility is to be clarified by RAN.

[0034] NOTE 2: Coordination with RAN is required to determine the Ambient IoT device capabilities in relation to system level of functionality (considering e.g. traffic scenarios, connectivity topologies etc.).

[0035] NOTE　3: The security aspects for Ambient IoT requires coordination with SA3.

[0036] NOTE　4: The charging aspects for Ambient IoT will be studied by SA5.

[0037] NOTE　5: The NAS based Congestion control is not in the scope of this study."

[0038] The following are architectural requirements that were agreed:

[0039] "- Support for AIoT Services needs to adhere to the nature of the AIoT Devices (e.g. ultra-low complexity, power, cost and resource-constrained).

[0040] - Support of the security aspects needs to consider the nature of the AIoT Devices (e.g. ultra-low complexity power, cost and resource-constrained) while addressing e.g. confidentiality, integrity, etc."

[0041] One of the assumptions indicates that Radio Resource Control, RRC, states are not supported. This may also mean that the Non-Access Stratum, NAS, modes and the UE functions may be quite different from what currently exists in terms of device NAS and RRC modes and states. Furthermore, an AIoT device may have a significantly reduced set of capabilities for communication and data exchange. For example, an AIoT device may perform simple read operation for data from its sensors and report it to the network, and / or may perform basic write operation to modify a parameter locally. The AIoT device is not expected to have the same type of QoS and / or PDU session as that of a smart device.

[0042] One of the key issues is set out below:

[0043] "Key Issue #X: Identification, Subscription, Registration and Connection management

[0044] Description

[0045] This Key Issue pertains to the authorization and management of Ambient IoT devices to support Ambient IoT services.

[0046] Considering that Ambient IoT devices are a new type of reduced capabilities devices, the existing subscription model may not be suitable. Specifically, there is the need to study the device identification method to support Ambient IoT devices which are under operator control.

[0047] Based on the above consideration, the aspects to be studied in this key issue include:

[0048] - Study whether subscription management, registration management and / or connection management are necessary for an Ambient IoT device or a group of Ambient IoT devices, and if so identify the necessary state machine(s), procedures and functionality considering the Ambient IoT devices capability and characteristics;

[0049] - Study whether and how reachability and paging apply to Ambient IoT device(s) considering the Ambient IoT devices capability and characteristics, and if so, what are the impacts.

[0050] - Study how to identify Ambient IoT device or group of devices and how to format the identifier.

[0051] NOTE: NAS based Congestion control are not in the scope of this study."

[0052] Based on the above, it is to be studied whether registration and connection management states are needed based on the current design.

[0053] The following should be noted about the UE states based on a current UE (i.e. UE which is not an AIoT device):

[0054] - The UE has RRC states, e.g. RRC_IDLE, RRC_CONNECTED, RRC_INACTIVE, etc, and the UE can transition between these states.

[0055] - The UE has NAS modes e.g. 5GMM-IDLE mode, 5GMM-CONNECTED mode, etc, and the UE can transition between these states

[0056] - The UE can have NAS states based on its registration status, etc,

[0057] For example, the UE which has not registered yet to the system is in a DEREGISTERED state, whereas after registration the UE is deemed to be in a REGISTERED state, noting that both of these states have substates and hence the UE can transition between substates accordingly as known.

[0058] However, the AIoT device may operate using different assumptions which is one of the main issues addresses by embodiments of the invention.

[0059] A problem in the art is that there is no current solutions available related to UE sates and how to switch between them. As indicated earlier, there have not been any state definitions and / or mode definitions for the AIoT device, and how the device transitions between them. However, it is clear that there may not be RRC states for use in an AIoT device.

[0060] It is therefore desirable to define the state(s) and / or mode(s) for an AIoT device and also how the UE can switch and / or transition between the state(s) and / or mode(s). There are currently no mechanisms to do so, especially without any input from the application function which may want to have control over the mode and / or state of operation of the AIoT device.

[0061] It is an aim of embodiments of the invention to address shortcomings in the prior art, whether mentioned herein or not.

[0062] According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows.

[0063] According to a first aspect of the present invention there is provided a method of operating a User Equipment, UE, in operative connection to a telecommunication network, wherein the UE is an Ambient Internet of Things, AIoT, device, wherein an Application Function, AF, in the telecommunication network is operable to trigger a change in the UE mode of operation via a service exposure that enables the AF to trigger the change in mode of operation.

[0064] In an embodiment, the UE is operable in a VALIDATED mode comprising a plurality of sub-modes comprising REPORT-ONLY, RECEIVE-ONLY, REPORT-and-RECEIVE and RECEIVE-and-EVENT-REPORT.

[0065] In an embodiment, the VALIDATE mode is entered following a security or validation procedure.

[0066] In an embodiment, the UE enters an INVALIDATED mode after completing an AIoT procedure.

[0067] In an embodiment, the UE enters a VOID state if instructed by the telecommunication network to stop operations.

[0068] In an embodiment, the UE is only permitted to enter a particular mode of operation a predefined number of times, to change mode of operation a predefined number of times or to remain in a particular mode of operation for a predetermined duration, before entering a different defined mode of operation.

[0069] In an embodiment, the different defined mode of operation is a VOID or SUSPEND mode.

[0070] In an embodiment, the UE indicates to the network its supported modes of operation.

[0071] According to a second aspect of the present invention there is provided apparatus arranged to perform the method of the first aspect.

[0072] A new service exposure is proposed that enables the AF to trigger a change in the Ambient IoT device state or mode of operation. This may also be performed by the network due to local configuration.

[0073] A new set of states or mode of operations are defined for the UE, which can be transitions to / from based on network commands, where this command may come from the AF.

[0074] The network and UE can confirm the result of the state change, or change in mode of operation, or provide a report on the mode of operation of the UE that it is currently in

[0075] Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims.

[0076] The embodiments presented are particularly applicable to Ambient IoT devices but should not be considered to be restricted to only these devices. As such any other UE may benefit from the techniques included herein.

[0077] Embodiments herein do not rely on a particular message format especially on the interface between the RAN (e.g. gNB, eNB or NG-RAN, etc.) and the AIoT device, or between a UE and the AIoT device, or between the AIoT device and another AIoT device, or between multiple UEs, RAN entities and / or AIoT devices. As such all the details herein would apply regardless of how the message format is defined. What really matters is the type of information that is being sent and how the recipient acts upon it (or in response to receiving this information).

[0078] Note that an AIoT device may be referred to as a UE, or AIoT device may be considered a special type or category of a UE. A UE may have at least AIoT capabilities, or an AIoT device can be a UE with restricted capabilities, etc. In one example, Carrier Aggregation (CA), Multi-Radio Dual Connectivity (MR-DC), handover and its related features (e.g., CHO, DAPS, etc.) are not supported by AIoT device.

[0079] The UE may report the states which it supports, or the mode of operation or the service operation it can perform in or operate in. This may be based on the particular use case or capability of the AIoT or the service which is expected for this device.

[0080] Additionally, the network may verify the capability of a given UE to be AIoT capable device.

[0081] For all embodiments herein, new subscription information may be defined to indicate if the UE and / or the network can behave as set out. Furthermore, the UE may exchange any related capability indication to signal that the node in question can operate as described.

[0082] All messages or interactions between the UE and the network may be implemented using any protocol such as, but not limited to, NAS and / or RRC.

[0083] A UE state may also refer to a UE mode of operation or to a service operation that the UE can take. As such the term state is not to be considered as a restriction that binds a UE to a particular state but rather as an example of how the UE may perform or behave in certain modes or conditions or based on service operations or expectations.

[0084] Embodiments set out new states and substates and / or modes for AIoT devices. The name of the state and / or mode should not be regarded as a limitation but rather as an example and hence any name may be used. In other words, "mode" and "state" should not be interpreted in an overly strict manner.

[0085] A device that has not yet been registered with the network may be in a new INVALIDATED state. In this state, the UE needs to be validated e.g. by going through authentication or other security procedures, or by its identity being validated. In another example, the device may be validated as part of the registration process of the device with the network.

[0086] After a successful security and / or validation procedure, the AIoT device may enter a new VALIDATED state, where this is the main state of operation of this device.

[0087] Moreover, the AIoT device may exist (or switch to) any of the following new substates:

[0088] · REPORT-ONLY: in this substate the UE is only supposed (or allowed or permitted) to report data, or read data that has been collected (and / or stored) and report the data

[0089] o Note that in this substate the UE may report data either due to the UE needing to report data e.g. periodically, or based on a solicitation (or command, trigger, and / or indication, etc.) from the network. However, this data reporting may not necessarily be due to a threshold being crossed (e.g. the data reporting may not necessarily be due to occurrence of an event).

[0090] · RECEIVE-ONLY: in this substate, the UE may only receive data and / or commands from the network, and / or from an application function (AF) via the network, but this UE does not report any data itself. Additionally, the UE may (or may not) be permitted (or allowed) to store this received data. The UE may acknowledge the receipt of the data and / or command but may not send data. In one example, the UE may move (or switch, etc.) to a different substate, or stay in the same substate after receiving the data.

[0091] · RECEIVE-and / or-EVENT-REPORT: in this substate the UE only receives data and / or commands but can only report if particular events and / or conditions have occurred. For example, the event may be that a certain threshold has been crossed in relation to a parameter that has (or is) being sensed or monitored or observed. In one example, upon the observed parameter exceeding a pre-configured threshold, the UE enters or change substate to EVENT-REPORT in order to report the occurrence of this event to the network (and / or AF, etc.)

[0092] o In this sub-state, the UE may not report even if solicited to do so as long as the event in question has not been detected. This makes the distinction between this sub-state and the READ-ONLY or REPORT-ONLY substate

[0093] · RECEIVE-and / or-REPORT: the UE may receive data, report data and / or optionally behave as described for the RECEIVE-and / or-EVENT-REPORT (sub-) state.

[0094] · WRITE-ONLY: in this substate, the UE may only be allowed (or permitted) to store data, e.g. data received from the network when the UE was previously in a READ-ONLY or READ-and / or-REPORT substate. In one example, the UE in READ-ONLY substate may switch to WRITE-ONLY substate to store the received data. The network may command the UE to perform this substate switch.

[0095] Note that any of the functions above can be combined into one substate as well. For example, the WRITE-ONLY behavior may be part of the RECEIVE-ONLY substate.

[0096] Note that all of the above can be considered as states as well, where e.g. READ-ONLY, RECEIVE-ONLY, RECEIVE-and / or-EVENT-REPORT, can only be entered after a successful registration and / or validation or authorization by the network.

[0097] A new SUSPEND (sub-)state may be defined, where this may be a state on its own or a sub-state of any of the previous states. The UE may enter this state when the network is revalidating or re-authorizing the UE or performing security procedures with the UE. In this (sub-)state, the UE should not perform any operation (e.g. read, write, transmit, receive, report, etc.) until the procedure is completed. If successful, the UE enters any of the above states (except the INVALIDATED state). If not successful, the UE enters the INVALIDATED state.

[0098] In one example, upon unsuccessful completion of any of the AIoT procedure, the UE transitions to the INVALIDATED state (and / or any other suitable naming).

[0099] Additionally, a new VOID state can be defined wherein the UE enters this state after being notified to stop all communications and / or operations, where operations may be local.

[0100] Optionally, the new state may be entered after the UE first clears all its contents, firmware, memory, or resets or deletes all configurations locally. Note that a UE may enter this state even if the UE has not yet registered with the network or even if the UE is in any of the above listed states, including the INVALIDATED state.

[0101] In another example, the UE may reset and / or delete all configurations and / or all (or part of) stored data, as a result of transition between different states defined above. For example, after performing a READ-ONLY or REPORT-ONLY the UE flushes (or deletes) or releases its stored information (e.g. data, configuration, etc.) and moves (or transit) to VOID state (and / or any other state). This UE behavior may be decided based on network configurations (or commands) and / or UE.

[0102] In another example, the network may release all (or part of) AIoT devices and release all data related to communication with those devices. In another example, the network indicates (implicitly or explicitly) to the AIoT device to release itself and delete (or flush) all data related to communication with the network and / or data stored and / or data collected to be reported to the network, etc.

[0103] In another example, the UE may wait for the new configuration (or commands) from the network to transit between different states (or substates).

[0104] The network may configure the UE to only operate or exist in one state or operation modes, mentioned herein in this invention, e.g. READ-ONLY, WRITE-ONLY, etc.

[0105] In another example, the UE is only allowed to be read (or in READ-ONLY state) or to REPORT-ONLY state, a given number of times (e.g. X times, X is integer value, preconfigured by the network) before moving to VOID or SUSPEND state. Similarly, the UE may only be a WRITE-ONLY state a given number of times before it is moved to VOID or SUSPEND.

[0106] In another example, the UE is only allowed to be in (or enter) a given state (and / or mode), a given number of times (e.g. X times, X is an integer value, preconfigured by the network) before moving to another state or to be moved to VOID or SUSPEND.

[0107] In another example, the UE is only allowed to be in (or enter) a given state (and / or mode), for a given time T (e.g. T is an integer value, preconfigured by the network). In another example, to be in a given state for a given time T before moving to another state or to be moved to VOID or SUSPEND.

[0108] For any of the above, using a number of state changes say X, or a time duration in which state changes can be performed say T, the parameters X and / or T may be associated with a particular device character or the intended usage, or this can be based on device priority information or similar.

[0109] In another example, after performing N tasks in a given state, the UE may be moved to another state or moved to VOID or SUSPEND.

[0110] In all examples herein, the UE may be moved between two states, state A and state B, where state A and B may be different. In another example, A and B may be the same state.

[0111] In another example, the UE may only be allowed to toggle its state (or operation mode), mentioned herein, a given number of times (e.g. X times, X is an integer value, preconfigured by the network) before moving to VOID or SUSPEND state. Additionally, the UE may not be able to change (or toggle) its state after an X state changes.

[0112] The network may only allow the UE certain number of transitions of states, e.g. READ-ONLY to WRITE-ONLY.

[0113] In one example, state transition frequency can be defined or used e.g. the UE can only toggle its state K number of times (where K is an integer) within a certain time period T (where T represents any time unit).

[0114] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the present disclosure as defined by the claims and their equivalents. The following description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the present disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

[0115] Figure 1 shows an illustration of states or modes of operation according to an embodiment of the invention.

[0116] The dashed rectangle (labelled VALIDATED) may indicate that the states REPORT-ONLY, RECEIVE-ONLY, RECEIVE-and / or-EVENT-REPORT, REPORT-and / or-RECEIVE are optionally sub-states of the VALIDATED state. The UE can transition between these as shown with the double-ended arrows. The UE may enter the SUSPEND state from any other state except the VOID state. Note that the SUSPEND state may be implemented as a sub-state of any other state. The UE may transition between the NON-VALIDATED and the VALIDATED state (and optionally any of its sub-states) as shown by the double-ended arrows.

[0117] The SUSPEND state may be entered when the network determines to re-validate or re-authorize or re-authenticate the UE (or do so for the first time), or when the network runs any security related procedure.

[0118] In case the network (e.g. gNB) detects that no more information is to be collected, or stored or transmitted or reported or a radio link problem has occurred, the network may request (or command) the AIoT device to enter the SUSPEND (or VOID or any other naming) state and terminate communication with this network (and / or other devices or UEs).

[0119] The network may be configured to inform the UE which state to start with, where this may be based on local policies or based on subscription information. As such, after validation of the UE, the network may send a message, which may be part of the validation process or the registration process, to inform the UE which state the UE should start operating with (or in).

[0120] Alternatively, the UE indicates the desired state, and the network may verify whether the UE can operate in that state or not based on the details above. In one example, the UE may signal its preference to the network to change (or modify) its state, using (or through) UEAssistanceInformation (or a similar procedure or a procedure modified to be suitable for communication between the AIoT device and the network). In one example, when the AIoT device is configured to do so, it may signal to the network one or more of the following (e.g. through UEAssistanceInformation and / or another existing or newly defined procedure):

[0121] - If it prefers an adjustment in the timing (or periodicity or frequency) of reporting any data (or information) to the network;

[0122] - If it prefers an adjustment in the timing (or duration) in remaining (or staying) in a given state and / or transiting between different states.

[0123] - If it is experiencing any internal malfunction (e.g. internal overheating or memory damage, etc.) and it needs to be moved to SUSPEND or VOID (or NONVALIDATED states) or switched off (or released), etc., in this case all (or part of) configuration and / or data available at the AIoT device may be also released.

[0124] - If it expects not to send or receive any more data in the near future, and in this case, it can provide its preference to transition out of RECEIVE-and / or-EVENT-REPORT where this indication may express its preferred AIoT device state (e.g. SUSPEND or PAUSE or IDLE);

[0125] - If it prefers (not) to be provisioned with reference parameters (e.g. time information or location information, etc.);

[0126] - If it prefers to move (or transit) to a different state (or substate). In one example, the UE preference to move from READ-ONLY to WRITE-ONLY or READ-and / or WRITE state;

[0127] - if it prefers for all above mentioned examples to stay in the same state (or substate) or mode. Additionally, the duration (and / or location);

[0128] - if it prefers a given parameters or configuration or command or indication or event to trigger to the UE the need to change state;

[0129] - if it prefers to operate or exist in one state only, e.g. READ-ONLY, WRITE-ONLY, etc.

[0130] In one alternative, the UE initial state is pre-determined except if otherwise explicitly indicated by the network. Any of the (sub-)states above, e.g. under the VALIDATED state, may be an initiate state for the UE.

[0131] In one example, during validation, or security procedures, the UE enters the SUSPEND state.

[0132] In another example, after successful completion of the security, authorization, validation, etc., the UE can be in any of the (sub-)states of the VALIDTED state as described above.

[0133] Note that the network may have a corresponding state for each UE or for each UE context. Similar transitions can occur at the network side.

[0134] During registration, the UE may indicate its supported states or modes of operation, where a mode of operation may correspond to at least one state from the above. This may be indicated by means of a bitmap or any new field or information element (IE) that can be included in any message (RRC and / or NAS).

[0135] The establishment, modification and / or release of SRBs and / or DRB(s) between a AIoT device and gNB may be similar to existing methods for other type of UEs or different. In one example, new type of SRBs and / or DRBs maybe introduced to carry the information between AIoT device and gNB. In one example, AS security may not be applied to all SRBs and / or DRBs of the AIoT device. In another example, encryption and / or integrity protection methods may not apply to AIoT SRBs and / or DRBs.

[0136] Note that the naming of above states (or substates), messages, information elements, signaling, procedures, bearers, entities or devices that are communicating with AIoT device(s), may include AIOT or Ambient AIoT or any other suitable naming. For example, AIoT-RECEIVE or Ambient-IoT-RECEIVE, etc.

[0137] Additionally, the AIoT device may be defined according to its deployment environment or functionality / application, e.g., AIoT-Indoor, AIoT-Outdoor, or AIoT-Indoor / Outdoor, AIOT-INVENTORY, AIOT-SENSORS, AIOT-POSITIONING, AIOT-COMMAND, etc.

[0138] Additionally, the AIoT device may be defined to operate (or use) other states, for example, ENABLED or DISABLED, ACTIVATED or DEACTIVATED, etc.

[0139] In one example, relevant to all of the above, the network will assume (implicit indication from the UE) that the UE has lost charge or dropped out of the network, upon the UE failure to respond to the network in any of the above states for a given period of time, for example, a timer expiry, and timer value preconfigured by the network or provided to the UE in any other methods.

[0140] In another example, the UE will explicitly indicate to the network the UE failure to be in a given state or mode (or be toggled to a state or mode). Optionally, the network may SUSPEND or VOID or disable communication with this UE or this UE operations or states and / or modes, etc.

[0141] For all of the above, the UE may indicate that it is able to operate in accordance with the above, or the UE can operate in a set of states where a state may be associated with a well-known behavior. The UE may indicate it supports receiving commands from the network to toggle its state.

[0142] In another example, the allowed states for an AIoT device and / or UE depend on the AIoT services and / or use cases that such AIoT device and / or UE is configured to support. For example, the potential states of an AIoT device and / or UE supporting an Inventory service only may include RECEIVE-and / or-EVENT-REPORT state but not necessarily READ-and WRITE related states, while the potential states of an AIoT device or UE supporting a Command service may include READ-only, WRITE-only, and READ-and / or-WRITE. Hence, the toggling of the state(s) of an AIoT device or UE may be also bound to the services it is configured to support.

[0143] The UE may operate in any of the states indicated above and / or in any state (or substate) which may not have been listed above. Regardless of the state name, embodiments provide a method by which the network can toggle the device state by issuing a command such that the UE will transition from one state to another.

[0144] The network may do so based on local configurations, policies, subscription information, and / or after receiving an external request from the AF optionally via the Network Exposure Function (NEF). As such, toggling a UE state may be triggered based on interaction between an AF and the network, or locally based on policies of the network.

[0145] When the network determines to toggle or change the state of the UE, or the mode of operation of the UE e.g. where a mode of operation may correspond to a state that has been described above (or may have not mentioned above), then the network may send a message or command to the UE to change its mode of operation.

[0146] A key element of embodiments is that the network should inform the UE to change its expected behavior or set of functions, where each set of functions or expected behavior may correspond to a well-known action or behavior. For example, the network may inform the UE to enter READ-ONLY mode where the UE may have been in any other state or mode of operation. In another example, the network may inform the UE to enter READ-ONLY then REPORT-ONLY or REPORT-ONLY after the UE has successfully completed a previous command from the network to enter READ-ONLY state. The UE state may be used hereafter to refer either to a state or a mode of operation.

[0147] The AF may negotiate or discover the NEF exposure services or capabilities for the 5GS (or any other system), where the NEF may indicate the support of toggling the states of IoT devices.

[0148] A network function (e.g. AMF, SMF, MME, etc.), which may be any function that is either existing or new, may subscribe to the UDM for getting events related to a requirement to toggle a UE state or mode of operation. Note that this may be done by a new NF that is potentially dedicated to handle or service AIoT devices. However, the details set out herein would still apply regardless of the NF. As such, the NF may be assumed to be an AMF for the purpose of describing embodiments.

[0149] Figure 2 shows a message flow illustrating an embodiment of the invention.

[0150] Note: although Figure2 refers to "NAS / RRC message", how the network communicates with the AIoT device may be different and hence any other protocol may be used. All the details still apply in this case regardless of the protocol (or messages or signaling or information elements, etc.) or air interface type (or system information) or message naming.

[0151] In step 1, the AF discovers the capability of the NEF exposure service, or the type of exposure service that can be offered and, in particular, the service to toggle UE states. Note that any message (e.g. message naming, content, etc.) may be used between the AF and NEF, and either the AF solicits the NEF's service capabilities or the NEF updates the AF with service capabilities, or both AF and NEF exchange this information.

[0152] In step 2, the AF provides a request to toggle the UE's state, where this request is submitted to the NEF. The AF identifies the UE which may be a single UE or a group of UEs. A single UE will be used hereafter but the techniques can equally apply to a group of UEs. The request provides a clear indication about what is needed e.g. to toggle a UE's state such that the target state is indicated. The current UE state may also be indicated if necessary.

[0153] In step 3, the NEF communicates the request with the UDM, for example, in order to verify if the AF is allowed to place such a request or not. The NEF may indicate the details of the request e.g. to toggle a UE state to a target state. The NEF may also provide the identity of the AF. The request may be to toggle a UE state into (or to) a target state, where this information of the target state may be provided.

[0154] In step 4, the UDM verifies if the request can be granted optionally based on the AF or the UE subscription or the type of the request. The UDM may indicate if the request is not authorized, or if the request can be authorized based on the UE subscription, AF identity, etc.

[0155] In step 5, the UDM determines which NF is responsible for this request e.g. the UDM communicates with the AMF and provides the request e.g. to toggle a UE state and may indicate the target state to use.

[0156] In step 6, the network (AMF or RAN) sends a message to the UE indicating the new state that the UE should transition to. Alternatively, the request may be to report the current state of the UE.

[0157] In step 7, the UE reports the result of the operation e.g. indicating if any state transition has been performed or reporting the current state of the UE.

[0158] In step 7a, the UE transitions into a new state based on the request received from the network. Note that step 7a may occur before the UE reports the result of the operation to the network in step 7. Note that this step assumes that the UE has successfully toggled its state or that it can successfully do so. Otherwise, if this is not possible then the UE does not change its state.

[0159] In step 8: the NF (e.g. AMF, RAN) sends the result of the request to the source NF e.g. the UDM. The result may be that the UE has changed its state or not, or may report the UE's current state (which may be a new state e.g. in the case that the UE has changed its state, or any other state such as the state that the UE is in and that may not have changed based on the request from the network).

[0160] In step 8a: the NF (e.g. AMF, RAN) updates the UE's state or context to reflect the new UE state, based on the operation or result indicated by the UE. If the operation or result is successful, then the AMF and / or RAN can update the UE's state, otherwise the UE state is not updated and optionally a "failure to update" indication may be stored.

[0161] In step 9: the UDM indicates the result of the request to update a UE state (or to report the current state of the UE) to the NEF. This may be based on the result received from the NF such as the AMF.

[0162] In step 10: the NEF indicates the result of the operation e.g. the result to toggle the UE state or to report the current UE state.

[0163] The steps above may occur at a different order and / or combination. Moreover, additional steps and / or combination of steps may be added, as required.

[0164] It should also be noted that the message names shown here may be different in practice. For example, instead of a State Request message from the UE, where the message contains the result within it, a State Response message may be used instead, etc. The same applies to any other node. As such the naming of the messages are to be seen as examples and not restrictions or limitations. Note that all the above may also comprise other types of requests although not shown in the figure. For example:

[0165] · The request may be to query the current state of the UE or group of UEs. As such all the steps can still be applied however the UE will reply to indicate its current state. Alternatively, a NF may have this information and provide it to the AF via the NEF. This information may reside in the AMF, MME, UDM, or NEF, or SMF, etc. As such the NEF may be configured to store the UE state or mode of operation and when queried the NEF can provide this information to the AF. Alternatively, the NEF may either query the UDM or communicate directly (or via the UDM) with another NF (e.g. the AMF) in order to get this information and then reply. As such any NF (e.g. AMF) may store this information and when queried the NF can provide it in a response.

[0166] · The request may be to query resource availability in the UE, and hence the UE may respond to provide indications about its resources, where resources may be memory, power, etc

[0167] Note that other modes of operation may also be defined, although the corresponding states have not been listed earlier. For example, such modes may include:

[0168] · Mobile Originated / Mobile Only mode: in this mode, the UE is only expected / allowed to initiate communication for sending data and hence the UE is not expected to receive data. However, the UE may receive commands that may be needed to control the UE behavior.

[0169] · Mobile Terminated mode: the UE is not allowed to initiate data transmission but only allowed to receive data, signaling and optionally the UE may respond to signaling (e.g. control messages) but not to send data unless the UE state or mode of operation is changed.

[0170] · Device triggered device terminated mode: in this mode the UE is triggered by the network to send or receive data and / or signaling.

[0171] Note that the modes listed above are applicable to the solutions provided earlier i.e. the signaling flow can be used to also switch or trigger transition of modes, where the modes may be any of those listed above.

[0172] Figure 3 is a block diagram illustrating a structure of a UE according to an embodiment of the disclosure.

[0173] Referring to FIG. 3, the UE includes a radio frequency (RF) processor 310, a baseband processor 320, a storage 330, and a controller 340.

[0174] The RF processor　310　performs the functions of signal band conversion and amplification and the like to transmit and receive signals over a radio channel. The RF processor　310　up-converts the baseband signal provided from the baseband processor　320　into an RF band signal and then transmits the signal through the antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processors　310　may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), and the like. Although one antenna is illustrated in　the drawing, the UE may include a plurality of antennas. In addition, the RF processor　310　may comprise a plurality of RF chains. Further, the RF processors　310　may perform beamforming. For beamforming, the RF processor　310　may adjust the phase and magnitude of each signals transmitted and received through a plurality of antennas or antenna elements. The RF processor may perform MIMO operation, and may receive multiple layers when performing the MIMO operation.

[0175] The baseband processor　320　performs the function of converting between baseband signals and bit strings according to the physical layer protocol of the system. For example, the baseband processor　320　performs coding and modulation on the transmission bit string to generate complex symbols when transmitting data. In addition, when receiving data, the baseband processor　320　performs demodulation and decoding on the baseband signal provided from the RF processor　310　to recover the received bit string. For example, in case of following an orthogonal frequency division multiplexing (OFDM) scheme, the baseband processor　320　performs coding and modulation on the transmission bit string to generate complex symbols, maps the complex symbols to subcarriers, performs inverse fast Fourier transform (IFFT) computation on the subcarriers, and inserts cyclic prefix (CP) to generate OFDM symbols when transmitting data. In addition, when receiving data, the baseband processor　320　separates the baseband signal provided from the RF processor　310　into OFDM symbols, restores the signal mapped to the subcarriers by the fast Fourier transform (FFT) computation, and performs demodulation and decoding to restore the bit string.

[0176] As described above, the baseband processors　320　and RF processors　310　are responsible for transmitting and receiving signals. Accordingly, the baseband processors　320　and RF processors　310　may be referred to as a transmitter, a receiver, a transceiver, or a communicator. Further, at least one of the baseband processor　320　and the RF processor　310　may comprise a plurality of communication modules for supporting different radio access technologies. In addition, at least one of the baseband processor　320　and the RF processor　310　may include different communication modules for processing different frequency band signals. Examples of different radio access technologies include wireless local area networks (WLANs) (e.g., institute of electrical and electronics engineers (IEEE) 802.11), cellular networks (e.g., LTE), and the like. In addition, different frequency bands may include super high frequency (SHF) bands (e.g., 2.N RHz, N Rhz) and millimeter wave bands (e.g., 60 GHz).

[0177] The storage　330　stores basic programs for the operation of the UE, application programs, and data, such as configuration information. More particularly, the storage　330　may store information about the secondary access node with which the UE performs radio communication using the secondary radio access technology. Further, the storage　330　provides stored data in response to a request from the controller　340. The controller　340 may include a multi-connection processor 342.

[0178] The controller　340　controls the overall operation of the UE. For example, the controller　340 transmits and receives signals through the baseband processor　320　and RF processor　310. The controller　340　also writes data to the storage　330　and reads data from the storage　330. To achieve this, the controller　340　may include at least one processor　. For example, the controller　340　may include communication processor (CP) for controlling communications and application processor (AP) for controlling upper layers, such as application programs.

[0179] Figure　4　is a block diagram illustrating a constitution of a network entity according to an embodiment of the disclosure.

[0180] Referring to FIG. 4, the network entity is constituted to include an　RF processor　410, a　baseband processor　420, a　backhaul communicator　430, a　storage　440, and a　controller　450.

[0181] The　RF processor　410　performs the function of signal band conversion, amplification and the like to transmit and receive signals over the radio channel. The　RF processor　410　up-converts the baseband signals provided from the　baseband processor　420　into RF band signals, and then transmits the signal through the antennas, and down-converts the RF band signals received through the antennas into baseband signals. For example, the　RF processor　410　may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, and the like. Although one antenna is depicted in　the drawing, the first access node may include a plurality of antennas. In addition, the　RF processor　410　may comprise a plurality of RF chains. The　RF processor　410　may perform beamforming. For beamforming, the　RF processor　410　may adjust the phase and magnitude of signals transmitted and received through a plurality of antennas or antenna elements. The　RF processor　410　may perform downlink MIMO operations to transfer signals on one or more layers.

[0182] The　baseband processor　420　performs the function of converting between baseband signals and bit strings according to the physical layer protocol of a first radio access technology. For example, the　baseband processor　420　performs coding and modulation on the transmission bit string to generate complex symbols when transmitting data. The　baseband processor　420　also performs demodulation and decoding on the baseband signals provided from the　RF processor　410　to recover the received bit string when receiving data. For example, in the case of following an OFDM scheme, the　baseband processor　420　performs coding and modulation on a transmission bit string to generate complex symbols, maps the complex symbols to subcarriers, performs IFFT computation on the subcarriers, and insert CP to generate OFDM symbols when transmitting data. In addition, the　baseband processor　420　separates the baseband signals provided from the　RF processor　410　into OFDM symbols, recovers the signals mapped to the subcarriers by the FFT computation, and performs demodulation and decoding to recover the receiving bit strings when receiving data. As described above, the　baseband processor　420　and RF processor　410　are responsible for transmitting and receiving signals. Thus, the　baseband processor　420　and RF processor　410　may be referred to as a transmitter, a receiver, a transceiver, a communicator, or a wireless communicator.

[0183] The　backhaul communicator　430　provides interfaces for communicating with other nodes in a network. The　backhaul communicator　430　converts a bit string to be transmitted from the main network entity to another node, for example, an auxiliary network entity, a core network, or the like into a physical signal, and converts a physical signal received from another node into a bit string.

[0184] The　storage　440　stores basic programs, application programs, and data, such as configuration information for the operation of the main network entity. More particularly, the　storage　440　may store information about bearers allocated to the connected UE, measurement results reported by the connected UE, and the like. The　storage　440　may also store information as criteria for determining whether to enable or disable multi-connectivity of the UE. In addition, the　storage　440　provides stored data in response to requests from the　controller　450. The controller　450 may include a multi-connection processor 452.

[0185] The　controller　450　controls the overall operations of the network entity. For example, the　controller　450 transmits and receives signals through the　baseband processor　420　and RF processor　410, or through the　backhaul communicator　430. The　controller　450　also writes data to the　storage　440　and reads data from the　storage　440. To achieve this, the　controller　450　may include at least one processor.

[0186] At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as 'component', 'module' or 'unit' used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term "comprising" or "comprises" means including the component(s) specified but not to the exclusion of the presence of others.

[0187] Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

[0188] All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive.

[0189] Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0190] The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1.A method performed by an ambient internet of things (AIoT) device in a wireless communication system, the method comprising:receiving, from a network, a request message indicating a target state of the AIoT device, wherein the target state indicating mode of operation for the AIoT device;transitioning a current state of the AIoT device to the target state of the AIoT device, based on the request message, in case that the current state of the AIoT device is different from the target state of the AIoT device; andtransmitting, to the network, a response message indicating a result of an operation performed based on the request message.2.The method of claim 1, wherein the current state of the AIoT device includes at least one of validated state and invalidated state.3.The method of claim 2, wherein the validated state includes at least one sub-state comprising one of REPORT-ONLY, RECEIVE-ONLY, RECEIVE-and / or-EVENT-REPORT, and REPORT-and / or-RECEIVE.4.The method of claim 2, wherein the current state of the AIoT device further includes suspend state for performing revalidating of the AIoT device, re-authorizing of the AIoT device, or security procedures with the AIoT device.5.The method of claim 2, wherein the current state of the AIoT device further includes void state for stopping all operations.6.The method of claim 2, wherein the transition from the validated state to the invalidated state occurs via suspend state.7.The method of claim 1, wherein the AIoT device is only permitted to enter a particular mode of operation a predefined number of times, to change mode of operation a predefined number of times or to remain in a particular mode of operation for a predetermined duration, before entering a different defined mode of operation.8.An ambient internet of things (AIoT) device in a wireless communication system, comprising:memory;transceiver; andat least one processor, coupled to the transceiver, configured to:receive, from a network, a request message indicating a target state of the AIoT device, wherein the target state indicating mode of operation for the AIoT device;transition a current state of the AIoT device to the target state of the AIoT device, based on the request message, in case that the current state of the AIoT device is different from the target state of the AIoT device; andtransmit, to the network, a response message indicating a result of an operation performed based on the request message.9.The AIoT device of claim 8, wherein the current state of the AIoT device includes at least one of validated state and invalidated state.10.The AIoT device of claim 9, wherein the validated state includes at least one sub-state comprising one of REPORT-ONLY, RECEIVE-ONLY, RECEIVE-and / or-EVENT-REPORT, and REPORT-and / or-RECEIVE.11.The AIoT device of claim 9, wherein the current state of the AIoT device further includes suspend state for performing revalidating of the AIoT device, re-authorizing of the AIoT device, or security procedures with the AIoT device.12.The AIoT device of claim 9, wherein the current state of the AIoT device further includes void state for stopping all operations.13.The AIoT device of claim 9, wherein the transition from the validated state to the invalidated state occurs via suspend state.14.The AIoT device of claim 8, wherein the AIoT device is only permitted to enter a particular mode of operation a predefined number of times, to change mode of operation a predefined number of times or to remain in a particular mode of operation for a predetermined duration, before entering a different defined mode of operation.

Images