Improvements in and relating to user equipment notification

Abstract

A method of operating a User Equipment (UE) operatively connected to a telecommunication network wherein the UE notifies the telecommunication network if a status associated with a power source used b

Description

The present invention relates to a User Equipment, UE, for communication with a telecommunication network and more particularly to its choice or use of a particular power supply and to issues surrounding the notification of this to the telecommunication network. The 3GPP organisation has agreed a study item for Release 19, Rel-19, of the standard which relates to Ambient loT (AloT) devices. AloT devices can be battery-less or with limited energy storage capability (i.e., using a capacitor) and the energy required for operation is provided through the harvesting of radio waves, light, motion, heat, or any other power source that could be deemed suitable. The following are architectural assumptions that were agreed in 3GPP document S2-2401821, Architecture Assumption and Architecture Requirement, SA WG2 Meeting #160-Ad Hoc-e, E-meeting, January 22 - 29, 2024: “- The following traffic types for Ambient ioT device are to be studied: - DT: Device-terminated; and - DO-DTT: Device-originated - device-terminated triggered. NOTE 1: The final decision for including DO-A (Device-originated - autonomous) in the study depends on RAN decision. - The following two connectivity topologies as defined in TR 38.848[X5] are to be studied: - Topology 1: BS <-> Ambient ioT device; - Topology 2: BS <-> intermediate node <-> Ambient IoT device: Only a UE can act as an intermediate node which is under the network control. - The communication spectrum is assumed to be licensed. - Handover is not supported. RRC states are not supported by AloT Devices (see RAN SID[x]) No mobility (i.e. at least no cell selection / re-selection-like function) supported by AloT Devices (see RAN SID[x]) 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. 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.). NOTE 3: The security aspects for Ambient ioT requires coordination with SA3. NOTE 4: The charging aspects for Ambient IoT will be studied by SA5. NOTE 5: The NAS based Congestion control is not in the scope of this study.” The following are architectural requirements that were agreed also in the same document: “- Support forAloT Services needs to adhere to the nature of the AloT Devices (e.g. ultra-low complexity, power, cost and resource-constrained). Support of the security aspects needs to consider the nature of the AloT Devices (e.g. ultra-low complexity power, cost and resource-constrained) while addressing e.g. confidentiality, integrity, etc. One of the key issues related to the study is in 3GPP document TS 24.501 V18.5.0, “Non-Access-Stratum (NAS) protocol for 5G System (5GS)”, where the key issue defines the scope of the study with respect to particular functions as stated below: “Key Issue #X: Identification, Subscription, Registration and Connection management Description This Key Issue pertains to the authorization and management of Ambient IoT devices to support Ambient IoT services. 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. Based on the above consideration, the aspects to be studied in this key issue include: 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; 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. Study how to identify Ambient IoT device or group of devices and how to format the identifier. NOTE: NAS based Congestion control are not in the scope of this study. ” Based on the above, it is to be studied whether and how reachability apply to Ambient IoT (AloT) devices. For example, reachability can be impacted based on the energy supply of the UE where, in case of low energy, then the UE may not be reachable or if reachable then the communication may lead to complete power depletion. As such it may be desirable to communicate with the device when it has sufficient power. One problem associated with the aforementioned situation is that there is no network or application function insight about the UE source of power. As indicated earlier, an AloT device may harvest energy using different means such as radio waves, solar, etc, and may also have a capacitor where energy can be stored and re-used. For example, the UE may use solar energy during the day for its communication and at the same time the UE may charge a capacitor that can be used as a source of energy for times when there is no or insufficient sunlight. Or, in another example, the UE may be able to harvest different levels of energy at different times and / or circumstances, such that when more energy is harvested then the UE would be more suited to communicate or be communicated with. In another example, the UE may perform any of the previous energy related actions in addition to (or while) performing other non-energy related actions (e.g. communication, data delivery, etc.) with the network. Optionally, the UE performs different actions e.g. simultaneous or in-parallel or at different time instances. Such information is currently lacking for AloT devices i.e. there are no notifications which are sent to the AF or to the network to inform these entities about the power source of the UE. Without this insight, the AF or network may not be able to reach the device as needed since attempts for terminated data delivery, or terminated trigger to have the UE send data (or UE originated data delivery), may occur at times of very low, or no, energy which may lead to a lack of communication and service. The use of notifications about the UE’s energy source may therefore become critical, for example, for UE reachability and communication as well as data delivery, since the network may then be able to communicate with a UE when there is the maximum (or at least sufficient) level of energy or power present. 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. According to a first aspect of the present invention, there is provided a method of operating a User Equipment, UE, operatively connected to a telecommunication network wherein the UE notifies the telecommunication network if a status associated with a power source used by the UE satisfies a certain criterion. In an embodiment, the certain criterion is one of: a change from a first to a second power source; and available power in the power source dropping below a predefined level. In an embodiment, the telecommunication network subscribes to be notified of changes in the status of the UE’s power source. In an embodiment, the UE messages the telecommunication network before entering a hibernate mode. In an embodiment, the telecommunication network determines whether or not to send data to the UE depending on the status of the UE’s power source. In an embodiment, the telecommunication network determines to buffer the data for the UE to send at a later time if the status of the UE’s power source indicates a low power reserve. In an embodiment, the telecommunication network determines to transmit the buffered data to the UE if the status of the UE’s power source indicates that the UE is able to operate to receive data. According to a second aspect of the present invention, there is provided apparatus arranged to perform the method of the first aspect. In an embodiment, the network uses an event report (on power source change or type) to determine if data is to be sent to the UE or to be postponed for a later time. For example, when the power source is solar, the network can send data to the UE. But if the power source is for example a capacitor and optionally the power level in the UE is low, then the network buffers the data until the power source in the UE changes or the level changes, etc. 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. 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: Figure 1 shows a message flow illustrating a method according to an embodiment of the invention. In an embodiment, the AloT device notifies the network when it switches from one power source to another, or it notifies the network when it has sufficient power for communication. This information may be sent to the AF which can use it for initiating communications towards the UE. If the power level of the UE is low, then the network and / or AF may postpone the communication with the UE. Alternatively, if the energy level of the UE is indicated to be acceptable (i.e. not critically low) or the power source of the UE ensures that the UE’s energy will not be critically depleted, then the AF can initiate the communication with the UE. All details presented herein can apply to one or more technical standard e.g. 5G, 4G, 6G or other systems, and the corresponding network functions may then apply and the corresponding messages using any suitable protocol. Note that an AloT device may be referred to as a UE, or AloT device may be considered a special type or category of a UE. A UE may have at least AloT capabilities, or an AloT device can be a UE with restricted capabilities, etc. As such, herein, the term UE and AloT device may be used interchangeably. The meaning is clear from the context. Furthermore, herein, the terms power, power source, energy or energy source may be used interchangeably. The following relates to a new capability exchange to report a change in the type of power supply. The UE may indicate its capability to report a switch of power source type or to indicate a change in its power source. The UE may do so in any message e.g. NAS, RRC, other means. The UE may report (or indicate) to the network that it supports one or more of the following: no energy storage capability, or energy storage that do not need to be replaced or recharged manually, or solar power, energy harvesting, battery-less and / or other form of energy. In another example, the network may also report to the UE its capability to support such UE or to support a UE indicating a change in its power source or type. Additionally, the network may verify the capability of a given UE to be AloT capable device e.g. with regards to different or certain power harvesting sources or certain power sources that can be used. The network may also indicate it supports and / or allows the UE to report when the power source in the UE has changed. This may be done using any message e.g. NAS, RRC which may be dedicated or broadcast. For example, a new bit may be defined in the system information broadcast (SIB) to indicate whether the UEs should report a switch in their power source or not, where for example the bit value ofT may mean that the UEs should report this, and a value of ‘0’ may mean that the UEs should not report a switch or change in the type of power supply. Note that a new subscription information may be defined that indicates that the UE is permitted (or not) or permitted under certain conditions and / or circumstances (e.g. at a given location and / or time) to report its change of power supply. For example, if the subscription permits or requires this, then the network (e.g. AMF, MME, etc) may use this to indicate that the UE should do so using the indication provided above. If the subscription indicates that the UE is not permitted to report a change in its power source, then the network should indicate to the UE that it is not permissible to report a change in power source. The following relates to a UE’s options to notify the network about a change of power supply. The UE may be configured to report when a change in its power supply occurs, or when a change in the type of power source occurs. The UE may be preconfigured to do so or may be configured by the network to do so. For any of these configurations, the UE may: • Report a change of its power source whenever such a change occurs e.g. when the UE was using power type I supply X and is now using power type I supply Y, where X and Y are different types of power supplies - such as but not limited to - harvesting waves, solar, capacitor, battery, direct connection to a power source, etc • Report a change of its power source when a particular type of power supply is no longer being used, regardless of the type of the power supply that is now being used. For example, when the UE stops using power type I supply X, then the UE reports this event regardless of the power type / supply Y that the UE may now be using • Report a change of its power source when a particular type of power supply is now being used, regardless of the type • Report a change of its power source when the new power source is at a certain level or when the initial power source is at a certain level Note that for any of the above, the UE may also report its current level of energy for each power source, or the current energy level of the UE optionally based on the current power source The UE may report when it enters a critically low energy mode, which may be called a HYBERNATE (or HIBERNATE) mode. The UE in this mode may stop all communications until the energy level goes up (or get back to a predefined or preconfigured level or threshold that is considered acceptable to resume communications). The network which is informed about the UE’s entering HYBERNATE mode may avoid reaching the UE and / or sending any data and / or signaling to the UE and may store a local flag to indicate this mode of the UE. When the UE leaves this mode e.g. after its energy level goes up, the UE reports this event which leads to the network removing the flag on HYBERNATE mode and can resume sending data or signaling to the UE. In one example, the network may not remove the flag on HYBERNATE mode immediately but after a given time T (where T is any real number or representation of any time unit or duration). Note that the entering of HYBERNATE mode may be based on local UE decision and / or configuration by the network. When entering the HYBERNATE mode, the UE may provide a timer which indicates the expected time it will remain in this mode, or the expected time at which the UE will leave this mode. The UE may report when it enters a given power phase, e.g. power harvesting phase (e.g. ENERGY-HARVEST phase, AloT-ENERGY-HARVEST, or any other naming convention). In another example, the UE enters a solar power charging phase (AloT-Solar-Phase), etc. In another example, other naming are also possible, BATTERY-LESS or ENERGY-HARVEST or STATIC or NOMOTION or LIMITED-ENERGY or SOLAR-POWER or LIGHT-POWER phase, or any other power source phase that could be seen suitable. The UE may report a preference for a change of power source or change of power phase to: • BATTERY-LESS or ENERGY-HARVEST or STATIC or NOMOTION or LIMITEDENERGY or SOLAR-POWER or LIGHT-POWER mode, or piezoelectric (kinetic / vibration), electromagnetic, electrostatic, heat / thermal, thermoelectric, magnetic, wind / water, acoustic, etc. Note that herein, the terms power source, power phase, power state, or power mode may be used interchangeably. Note that any of the above may also be useful for the network. For example, the SCEF may buffer downlink data for the UE, where the data may have been received from the AF. The SCEF may need to know the best time to send the data to the UE based on the power level and / or source of the UE. For example, the SCEF (or any other NF) may behave as follows: • If the UE is using a particular energy source e.g. solar, and optionally the energy level is not critically low, then the SCEF can trigger the transfer of data or configurations to the AloT device • If the UE is using a power source e.g. capacitor optionally with critically low energy, or no direct power source, then the network continues to buffer the data and waits for events indicating better energy conditions in the UE • The network may be configured to operate based on the above, for example this configuration may be based on subscription or OAM As such, all of the above can be applicable to any network function or entity and so the use of the information on power source can be performed by any network entity. Note that the request to report an event may therefore be triggered purely by a network entity such as the NEF or AMF, RAN, UPF, etc, and this is not necessarily a request that comes from the AF. As such, any network function can be configured to request events about power source change and or report power source change as indicated by the UE, or use this information to plan delivery of data or signaling towards the UE such that the delivery may be done when the UE indicates particular power sources and / or certain levels of power. Figure 1 shows a flowchart illustrating an embodiment of the invention, noting that this is just an example and not a restriction. As such all steps shown can occur in different order or combination and the same actions or steps can be performed by other network functions even if they are not shown in the figure. As such, the actual entity performing a particular task is not always crucial. The steps in the flowchart are described below: Step 1: the AF and NEF can exchange capabilities about the service that the network provides, where this service is related to reporting of a change in UE power source, or when a UE is about to enter a HYBERNATE mode. This may be done using any message on the protocol between the NEF and the AF, where this may be solicited by the AF or initiated by the SCEF e.g. after a UE registers or has its subscription information updated, etc, or when the network deploys this service. Step 2: the AF subscribes to an event for power source change notification, optionally for a UE or a group of UEs. The identity of the UE(s) may be provided. Other conditions may be provided as listed earlier e.g. initial power source, target power source, change from one source to the other, where this change may be particularly defined or when any change happens, or when the UE enters HYBERNATE mode, etc, or any other event as has been described previously. Step 3: the NEF sends the subscribe request to the Unified Data Management, UDM, where the UDM may determine if the request can be granted. The UDM may determine the network node which may be responsible for this event subscription, where the AMF is an example of such a network node. The UDM may also verify if the UE subscription permits such a request, etc. As indicated earlier, the NEF may be the source of this event subscription and so the NEF may trigger this step even if no request is received from the AF. The NEF may be configured to operate as proposed in order to determine the best time to send data to the UE based on the energy source or level of the UE. Step 4: the UDM sends the subscribe request to the AMF and optionally identifies the one or more UEs for which the request is submitted. All the details about the request are also provided e.g. when the UE changes from one power source X to another Y, or when any power source changes, or when the new power source is of a certain type, etc. Step 5: the AMF forwards the request to the UE in any NAS message. Note that RRC messages may also be used, where the request may be forwarded by the AMF to the RAN and then from the RAN to the UE. The message (NAS or RRC) contains all the details of the event to subscribe and monitor for as have been described before. Other triggers or conditions may also be provided. Note that the RAN may also broadcast an indication that the UEs should monitor for specific events, where a bit position can be used for particular events e.g. UE expects to enter a HYBERNATE mode, or UE uses a particular source for its power, etc. Step 6: this step applies to any node which is at least shown in the figure, where any node may acknowledge receipt of the subscription request, where this acknowledgement may mean that the event is being processed and / or monitored accordingly. Step 7: the UE starts monitoring for the event which was subscribed to by the network, where the event may include any of the details that were previously listed. Note that the UE may autonomously monitor for a local event for which it is expected that the UE will enter a HYBERNATE mode. As such the UE may also take a local decision to monitor for any event even if not explicitly informed to do so. The UE may base its local decision on preconfigurations, USIM indications or file, indications of policy that is received from the UDM via a policy container or any other policy related message as defined in 3GPP TS 24.501, or based on user interactions to modify the UE settings, or based on any SIB that the network broadcasts, or based on dedicated NAS / RRC messages. Step 8: the UE detects the desired event e.g. change of a power source (of any type, etc, as per the event that has been subscribed to or as per UE autonomous decision, etc). Step 9: the UE reports the event to the network (e.g. AMF or RAN) using any NAS or RRC message, where the messages may be new or existing. Step 10a: the AMF reports the occurrence of the event to the UDM. Step 10b: the UDM reports the occurrence of the event to the NEF. Step 11: in one alternative, the AMF reports the occurrence of the event directly to the NEF. Step 12: the NEF reports the occurrence of the event to the AF. Note that after the NEF or the AF receives the event report, the NEF or AF may use this information to determine if data or signaling can be sent to the UE. For example, the NEF or AF can be configured to send data to the UE when the power source is of a certain type and optionally when the power level is above a certain threshold or level. Note that for all the above, the implementation may also apply to other network entities although not shown in the figure. For example, the SMF may subscribe to the events described above in order to determine the best time to send session management signaling or parameters to the UE if needed, etc. As such the details above can be extended to other network functions and not limited to those shown in the figure. Note that for any step in the above, the UE may be identified accordingly or a group of UEs may be identified accordingly such that every network entity may be able to determine the UE(s) in question for which an event is requested or reported, and the details associated with the event, etc. All the necessary information should be provided in the event request or report. 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. 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. 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. 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 5 feature disclosed is one example only of a generic series of equivalent or similar features. 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, 10 or any novel combination, of the steps of any method or process so disclosed.

Claims

1. A method of operating a User Equipment, UE, operatively connected to a telecommunication network wherein the UE notifies the telecommunication network if a status associated with a power source used by the UE satisfies a certain criterion.

2. The method of claim 1 wherein the certain criterion is one of: a change from a first to a second power source; and available power in the power source dropping below a predefined level.

3. The method of any preceding claim wherein the telecommunication network subscribes to be notified of changes in the status of the UE’s power source.

4. The method of any preceding claim wherein the UE messages the telecommunication network before entering a hibernate mode.

5. The method of any preceding claim wherein the telecommunication network determines whether or not to send data to the UE depending on the status of the UE’s power source.

6. The method of claim 5 wherein the telecommunication network determines to buffer the data for the UE to send at a later time if the status of the UE’s power source indicates a low power reserve.

7. The method of claim 6 wherein the telecommunication network determines to transmit the buffered data to the UE if the status of the UE’s power source indicates that the UE is able to operate to receive data.

8. Apparatus arranged to perform the method of any preceding claim.

Images