Method and apparatus for user equipment notification in a wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Disclosed is 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.

Description

METHOD AND APPARATUS FOR USER EQUIPMENT NOTIFICATION IN A WIRELESS COMMUNICATION SYSTEM

[0001] The present disclosure 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.

[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 (THz) 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 method and apparatus for user equipment notification in a wireless communication system.

[0009] According to an aspect of an exemplary embodiment, there is provided a communication method in a wireless communication system.

[0010] Aspects of the present disclosure provide efficient communication methods in a wireless communication system.

[0011] The present disclosure is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments of the present disclosure will be better understood from the following description with reference to the drawings, in which:

[0012] Figure. 1 illustrates a message flow of a method according to an embodiment of the present disclosure;

[0013] Figure. 2 illustrates a block diagram of a UE according to various embodiments of the present disclosure; and

[0014] Figure. 3 illustrates a block diagram of a base station or a network entity according to various embodiments of the present disclosure.

[0015] The 3GPP organisation has agreed a study item for Release 19, Rel-19, of the standard which relates to Ambient IoT (AIoT) devices. AIoT 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.

[0016] 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:

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

[0018] - DT: Device-terminated; and

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

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

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

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

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

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

[0025] - Handover is not supported.

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

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

[0028] 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.

[0029] 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.).

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

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

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

[0033] The following are architectural requirements that were agreed also in the same document:

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

[0035] - 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.

[0036] 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:

[0037] “Key Issue #X: Identification, Subscription, Registration and Connection management

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

[0039] 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.

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

[0041] - 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;

[0042] - 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.

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

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

[0045] Based on the above, it is to be studied whether and how reachability apply to Ambient IoT (AIoT) 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.

[0046] One problem associated with the aforementioned situation is that there is no network or application function insight about the UE source of power.

[0047] As indicated earlier, an AIoT 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.

[0048] Such information is currently lacking for AIoT 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.

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

[0050] According to a first aspect of the present disclosure, 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.

[0051] 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.

[0052] In an embodiment, the telecommunication network subscribes to be notified of changes in the status of the UE’s power source.

[0053] In an embodiment, the UE messages the telecommunication network before entering a hibernate mode.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] According to a second aspect of the present disclosure, there is provided apparatus arranged to perform the method of the first aspect.

[0058] 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.

[0059] Although a few preferred embodiments of the present disclosure 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 disclosure, as defined in the appended claims.

[0060] For a better understanding of the disclosure, 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:

[0061] Figure 1 shows a message flow illustrating a method according to an embodiment of the disclosure.

[0062] In an embodiment, the AIoT 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.

[0063] 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.

[0064] 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. As such, herein, the term UE and AIoT device may be used interchangeably. The meaning is clear from the context.

[0065] Furthermore, herein, the terms power, power source, energy or energy source may be used interchangeably.

[0066] The following relates to a new capability exchange to report a change in the type of power supply.

[0067] 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.

[0068] 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.

[0069] Additionally, the network may verify the capability of a given UE to be AIoT 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 of ‘1’ 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.

[0070] 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.

[0071] The following relates to a UE’s options to notify the network about a change of power supply.

[0072] 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:

[0073] - Report a change of its power source whenever such a change occurs e.g. when the UE was using power type / supply X and is now using power type / 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

[0074] - 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 / supply X, then the UE reports this event regardless of the power type / supply Y that the UE may now be using

[0075] - Report a change of its power source when a particular type of power supply is now being used, regardless of the type

[0076] - 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

[0077] 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

[0078] 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.

[0079] The UE may report when it enters a given power phase, e.g. power harvesting phase (e.g. ENERGY-HARVEST phase, AIoT-ENERGY-HARVEST, or any other naming convention). In another example, the UE enters a solar power charging phase (AIoT-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.

[0080] The UE may report a preference for a change of power source or change of power phase to:

[0081] - BATTERY-LESS or ENERGY-HARVEST or STATIC or NOMOTION or LIMITED-ENERGY or SOLAR-POWER or LIGHT-POWER mode, or piezoelectric (kinetic / vibration), electromagnetic, electrostatic, heat / thermal, thermoelectric, magnetic, wind / water, acoustic, etc.

[0082] Note that herein, the terms power source, power phase, power state, or power mode may be used interchangeably.

[0083] 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:

[0084] - 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 AIoT device

[0085] - 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

[0086] - The network may be configured to operate based on the above, for example this configuration may be based on subscription or OAM

[0087] 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.

[0088] 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.

[0089] Figure 1 shows a flowchart illustrating an embodiment of the disclosure, 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.

[0090] The steps in the flowchart are described below:

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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).

[0099] 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.

[0100] Step 10a: the AMF reports the occurrence of the event to the UDM.

[0101] Step 10b: the UDM reports the occurrence of the event to the NEF.

[0102] Step 11: in one alternative, the AMF reports the occurrence of the event directly to the NEF.

[0103] Step 12: the NEF reports the occurrence of the event to the AF.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] Figure 2 illustrates a block diagram of a UE according to various embodiments of the present disclosure. Furthermore, the UE of Figure 2 corresponds to the UE according to the above embodiments of the present disclosure.

[0108] As shown in Figure. 2, the UE according to an embodiment may include a transceiver 210, a memory 220, and a processor 230. The transceiver 210, the memory 220, and the processor 230 of the UE may operate according to a communication method of the UE described above. However, the components of the UE are not limited thereto. For example, the UE may include more or fewer components than those described above. In addition, the processor 230, the transceiver 210, and the memory 220 may be implemented as a single chip. Also, the processor 230 may include at least one processor.

[0109] The transceiver 210 collectively refers to a UE receiver and a UE transmitter, and may transmit / receive a signal to / from a base station or a network entity. The signal transmitted or received to or from the base station or a network entity may include control information and data. The transceiver 210 may include a RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and a RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver 210 and components of the transceiver 210 are not limited to the RF transmitter and the RF receiver.

[0110] Also, the transceiver 210 may receive and output, to the processor 230, a signal through a wireless channel, and transmit a signal output from the processor 230 through the wireless channel.

[0111] The memory 220 may store a program and data required for operations of the UE. Also, the memory 220 may store control information or data included in a signal obtained by the UE. The memory 220 may be a storage medium, such as read-only memory (ROM), random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0112] The processor 230 may control a series of processes such that the UE operates as described above. For example, the transceiver 210 may receive a data signal including a control signal transmitted by the base station or the network entity, and the processor 230 may determine a result of receiving the control signal and the data signal transmitted by the base station or the network entity.

[0113] Figure 3 illustrates a block diagram of a base station or a network entity according to various embodiments of the present disclosure. Furthermore, the base station or the network entity of Figure 3 corresponds to the network apparatus according to the above embodiments of the present disclosure.

[0114] As shown in Figure 3, the base station(or the network entity receiver) according to an embodiment may include a transceiver 310, a memory 320, and a processor 330. The transceiver 310, the memory 320, and the processor 330 of the base station(or the network entity receiver) may operate according to a communication method of the base station(or the network entity receiver) described above. However, the components of the base station(or the network entity receiver) are not limited thereto. For example, the base station may include more or fewer components than those described above. In addition, the processor 330, the transceiver 310, and the memory 320 may be implemented as a single chip. Also, the processor 330 may include at least one processor.

[0115] The transceiver 310 collectively refers to the base station(or the network entity receiver) and a base station(or the network entity) transmitter, and may transmit / receive a signal to / from a terminal or a network entity or a base station. The signal transmitted or received to or from the terminal or a network entity or the base station may include control information and data. The transceiver 310 may include a RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and a RF receiver for amplifying low-noise and down-converting a frequency of a received signal. However, this is only an example of the transceiver 310 and components of the transceiver 310 are not limited to the RF transmitter and the RF receiver.

[0116] Also, the transceiver 310 may receive and output, to the processor 330, a signal through a wireless channel, and transmit a signal output from the processor 330 through the wireless channel.

[0117] The memory 320 may store a program and data required for operations of the base station(or the network entity receiver). Also, the memory 320 may store control information or data included in a signal obtained by the base station. The memory 320 may be a storage medium, such as read-only memory (ROM), random access memory (RAM), a hard disk, a CD-ROM, and a DVD, or a combination of storage media.

[0118] The processor 330 may control a series of processes such that the base station(or the network entity receiver) operates as described above. For example, the transceiver 310 may receive a data signal including a control signal transmitted by the terminal or the network entity or the base station, and the processor 330 may determine a result of receiving the control signal and the data signal transmitted by the terminal or the network entity or the base station.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] The disclosure is not restricted to the details of the foregoing embodiment(s). The disclosure 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 a user equipment (UE) in a wireless communication system, the method comprising:transmitting, to a network entity, a notification 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 includes 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 claim 1, wherein changes in the status of the UE’s power source is notified to the network entity.4.The method of claim 1, further comprising transmitting, to the network entity, a message before entering a hibernate mode.5.A method performed by a network entity in a wireless communication system, the method comprising:receiving, from a user equipment (UE), a notification if a status associated with a power source used by the UE satisfies a certain criterion.6.The method of claim 5, wherein the certain criterion includes one of a change from a first to a second power source, and available power in the power source dropping below a predefined level.7.The method of claim 5, further comprising, subscribing to be notified of changes in the status of the UE’s power source.8.The method of claim 5, further comprising, receiving, from the UE, a message before the UE enters a hibernate mode.9.The method of claim 5, further comprising, determining whether or not to send data to the UE depending on the status of the UE’s power source.10.The method of claim 9, further comprising, determining 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.11.The method of claim 10, further comprising, determining 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.12.A user equipment (UE) in a wireless communication system, comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:transmits, to a network entity, a notification if a status associated with a power source used by the UE satisfies a certain criterion.13.The UE of claim 12, wherein the certain criterion includes one of a change from a first to a second power source, and available power in the power source dropping below a predefined level.14.A network entity in a wireless communication system, comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:receives, from a user equipment (UE), a notification if a status associated with a power source used by the UE satisfies a certain criterion.15.The network entity of claim 14, wherein the certain criterion includes one of a change from a first to a second power source, and available power in the power source dropping below a predefined level.

Images