Method for determining charging duration and related apparatus

Abstract

The present application provides a method for determining a charging duration, and a related apparatus. In the method, a reader / writer may receive first information, the first information being used for instructing determination of a charging duration of an Ambient Internet of Things (AIoT) device; the reader / writer may send second information to the AIoT device, the second information being used for triggering uplink data; the reader / writer receives the uplink data sent by the AIoT device and obtains time information of the uplink data; then, the reader / writer obtains the charging duration of the AIoT device on the basis of the time information. In this way, the reader / writer can determine that the AIoT device is in an active state on the basis of the uplink data sent by the AIoT device, and the reader / writer can determine the charging duration of the AIoT device on the basis of the uplink data, which can increase the possibility that the AIoT device is in the active state, and further increase the task response rate of the AIoT device, improving the quality of task completion by the AIoT device.

Description

A method and related apparatus for determining charging duration

[0001] This application claims priority to Chinese Patent Application No. 202410958568.8, filed on July 16, 2024, entitled "A Method and Apparatus for Determining Charging Duration", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a method and related apparatus for determining charging duration. Background Technology

[0003] With the rapid development of IoT technology, IoT devices are being used more and more widely in various fields. Among them, Ambient IoT devices (AIoT devices for short) are a new type of IoT devices that harvest energy from radio waves, light, motion, heat, or any other available environmental energy sources and use it as a power source.

[0004] However, in some scenarios, the energy harvested by AIoT devices from the environment may be weak, unstable, or the conversion efficiency of the harvested energy may be low. These situations may cause AIoT devices to be unable to complete tasks due to insufficient energy. Furthermore, insufficient energy may prevent AIoT devices from reaching an activation state, thus preventing them from receiving task requests from the network side, resulting in low task response rates or poor task completion quality. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method and related apparatus for determining charging duration. The purpose is to determine the charging duration of an AIoT device, thereby charging the AIoT device based on the charging duration, increasing the energy stored in the AIoT device, and thus improving its task response rate and task completion quality.

[0006] Firstly, this application provides a method for determining charging duration, applied to a reader / writer, such as a base station or terminal device capable of communicating with AIoT devices. In this method, the reader / writer receives first information, such as first information sent by the core network, indicating the need to determine the charging duration of the AIoT device. For example, the first information can be indication information, indicating the need to determine the charging duration of the AIoT device; or it can be a task request signaling carrying the indication information. The reader / writer then sends second information to the AIoT device, which triggers uplink data, i.e., triggers the AIoT device to send uplink data to the reader / writer. For example, the second information can be initial trigger information. Subsequently, the reader / writer receives the uplink data sent by the AIoT device and can obtain the time information of the uplink data. Finally, the reader / writer obtains the charging duration of the AIoT device based on the time information of the uplink data.

[0007] Since the reader has received uplink data from the AIoT device, indicating that the device is active, it can determine the charging duration of the AIoT device based on the time information of the uplink data. This allows the reader to subsequently charge the AIoT device based on the charging duration, increasing the likelihood of it reaching activation. In this active state, the AIoT device can receive task requests, thereby improving its task response rate and task completion quality.

[0008] In one possible implementation, the first information can be used to instruct the reader to determine the charging duration of the AIoT device. Accordingly, the reader obtains the charging duration of the AIoT device based on the time information of the uplink data; specifically, the reader determines the charging duration of the AIoT device based on the time information of the received uplink data. Thus, the communication behavior of the reader receiving uplink data sent by the AIoT device is associated with the device's access status and the determination of its charging duration. Based on this, and determining that the AIoT device is in an active state, the charging duration required for the AIoT device to reach its active state can be accurately determined based on the time information of the uplink data.

[0009] In one possible implementation, the uplink data timing information can be used to indicate the first reception moment when the reader receives the uplink data. Correspondingly, based on the uplink data reception timing information, the reader determines the charging duration of the AIoT device. This can be achieved by: after the preset charging duration ends, the reader obtains the first start moment of that preset charging duration. For example, the reader can charge the AIoT device within the preset charging duration; after the preset charging duration ends, i.e., after the reader finishes charging the AIoT device, the reader can obtain the time it took to charge the AIoT device. The timestamp is used as the first start time; for example, other devices such as terminal devices can charge the AIoT device within a preset charging time. After the preset charging time ends, the reader can obtain the timestamp of the other device charging the AIoT device as the first start time; the reader then obtains the first receiving time of the uplink data based on the time information. For example, the reader can record the timestamp of the received uplink data as the first receiving time; subsequently, the reader can determine the charging time of the AIoT device based on the time interval between the first start time and the first receiving time.

[0010] Therefore, charging the AIoT device first can increase the likelihood of it reaching the activation state. Furthermore, the charging time of the AIoT device determined based on the first start time of the preset charging time and the first receiving time of the uplink data is more accurate. In addition, the method of calculating the time between the first start time and the first receiving time is also easier to process, thus improving the accuracy and speed of obtaining the charging time of the AIoT device.

[0011] In one possible implementation, after the AIoT device receives the second information, there may be a time period including at least one time slot. The AIoT device may send uplink data in one time slot of the time period, so that the reader may receive the uplink data in one time slot of the time period. The timing information of the uplink data may be used to indicate the time slot in which the reader receives the uplink data. For example, the reader may receive the uplink data sent by the AIoT device based on the time slot ALOHA protocol, which can divide the time period into multiple time slots. Accordingly, the reader determines the time information of the AIoT device based on the time information of receiving uplink data. This can be achieved as follows: for example, after the reader or other device completes charging the AIoT device for a preset charging time, the reader can obtain the second start time of the starting time slot of the time period, which is the start time of the first time slot in the time period, after the preset charging time ends. The reader then obtains the end time of the time slot in which it receives uplink data based on the time information. Subsequently, the reader can determine the duration between the second start time of the starting time slot of the time period and the end time of the time slot in the time period in which the reader receives uplink data, and then determine the sum of this duration and the preset charging time as the charging time of the AIoT device.

[0012] Thus, when there are multiple AIoT devices, each device can select different time slots within a time period to send uplink data. This solves the problem of conflicting uplink data sent by multiple AIoT devices, which would prevent the reader from receiving the uplink data. It also avoids situations where the reader cannot determine the charging time of the AIoT device.

[0013] In one possible implementation, the first information received by the reader can be used to instruct the AIoT device to determine its own charging duration. The second information sent by the reader to the AIoT device also instructs the AIoT device to determine its own charging duration, so that the AIoT device receives the instruction to determine its own charging duration. Accordingly, the uplink data sent by the AIoT device received by the reader can include time information, which indicates the charging duration of the AIoT device. That is, the AIoT device includes its determined charging duration in the uplink data sent to the reader, and the reader can obtain the charging duration of the AIoT device based on the received uplink data. In this way, the AIoT device has a better understanding of its own status, and can record a more accurate charging duration.

[0014] In one possible implementation, when an AIoT device is charged by a reader or other device for a preset charging duration, the AIoT device can determine the charging duration as the time interval between the first start time of the preset charging duration and the time when the voltage across its capacitor reaches a threshold. For example, the AIoT device can record the timestamp of receiving charging as the first start time of the preset charging duration, and then record the timestamp of the voltage across its capacitor reaching the threshold as that time. In this way, the time when the voltage across the AIoT device's capacitor reaches the threshold accurately indicates the time when the AIoT device reaches its activated state. Therefore, the AIoT device can accurately determine the time when it reaches its activated state and further determine a more accurate charging duration.

[0015] In one possible implementation, the uplink data may further include at least one of the AIoT device's device identifier and random data. For example, the device identifier may be the AIoT device's EPC, and the random data may be RN16. Thus, the reader can obtain the AIoT device's charging duration based on the uplink data's time information, while simultaneously obtaining the AIoT device's device identifier and / or random data. The random data can also serve as a temporary identifier for the AIoT device, facilitating the reader to store the charging durations of different AIoT devices based on different device identifiers or temporary identifiers, thus avoiding confusion.

[0016] In one possible implementation, the first information received by the reader can also be used to instruct the AIoT device to perform a task. For example, the first information may be a task request signaling, which instructs the AIoT device to perform a specific task, such as an inventory task, a read task, or a write task. The task request signaling may include indication information used to determine the charging duration of the AIoT device. Correspondingly, the uplink data sent by the AIoT device received by the reader may also include third information, which instructs the AIoT device to execute the task indicated by the first information. In this way, the charging duration of the AIoT device can be determined simultaneously with the need for the AIoT device to complete a task, reducing signaling overhead between the reader and the AIoT device and lowering costs without affecting task execution.

[0017] In one possible implementation, the method for determining the charging duration may further include: the reader sending fourth information to the core network, the fourth information including the charging duration of the AIoT device. For example, after receiving the charging duration of the AIoT device, the core network can store and analyze the charging duration. This allows the core network to obtain the charging duration indication to charge the AIoT device when it subsequently needs the device to perform a task, increasing the likelihood of it reaching an activated state, thereby improving the task response rate and the quality of task completion.

[0018] Secondly, this application provides a method for determining charging duration, applicable to environmental Internet of Things (AIoT) devices. For example, an AIoT device can be an IoT device that collects energy from unstable environmental energy sources such as geothermal energy, solar energy, and radio frequency signals, and uses this energy as its driving force. In this method, the AIoT device can receive second information sent by a reader / writer, which triggers the AIoT device to send uplink data to the reader / writer. After the reader / writer receives first information indicating the determination of the charging duration of the AIoT device, it sends the second information to the AIoT device. Subsequently, the AIoT device can send uplink data to the reader / writer. After receiving the uplink data, the reader / writer can obtain the time information of the uplink data. Finally, the reader / writer can obtain the charging duration of the AIoT device based on the time information of the uplink data.

[0019] Thus, when an AIoT device is active, it can receive the second information sent by the reader and send uplink data back to the reader, enabling the reader to detect the AIoT device's active state. Based on the time information of the uplink data, the reader can then determine the charging duration of the AIoT device. Therefore, the AIoT device can be charged according to the determined charging duration to keep it active as much as possible. This increases the likelihood of the AIoT device receiving task requests, improves its task response rate, enhances the quality of task completion, and reduces the likelihood of the AIoT device failing to execute tasks due to not being active.

[0020] Thirdly, this application provides a method for determining charging duration, applied to a core network. For example, the core network may include multiple network elements such as AMF network elements and AF network elements. In this method, the core network can send first information to the reader / writer. The first information is used to indicate the charging duration of the AIoT device. After receiving the first information, the reader / writer can send second information to the AIoT device to trigger uplink data transmission. This allows the reader / writer to receive the uplink data sent by the AIoT device and obtain the uplink data's time information. Subsequently, the reader / writer can determine the charging duration of the AIoT device based on the uplink data's time information, thus fulfilling the instruction of the first information sent by the core network.

[0021] In this way, the reader can determine that the AIoT device is in an active state based on the uplink data sent by the AIoT device. Based on the time information of the uplink data, the reader can determine the charging time to make the AIoT device reach the active state as much as possible. Then, the reader can charge the AIoT device based on this, improve the task response rate of the AIoT device, and improve the quality of the AIoT device in completing tasks.

[0022] Fourthly, this application provides a system for determining charging duration, which may include a core network, a reader / writer, and an AIoT device. The core network may send first information to the reader / writer, which is used to indicate the charging duration of the AIoT device. The reader / writer may receive the first information sent by the core network and then send second information to the AIoT device, which may be used to trigger uplink data. Subsequently, the AIoT device may receive the second information sent by the reader / writer and then send uplink data to the reader / writer. Finally, the reader / writer may receive the uplink data sent by the AIoT device and obtain the time information of the uplink data, and then obtain the charging duration of the AIoT device based on the time information.

[0023] It should be noted that the charging duration determination system provided in the fourth aspect corresponds to the charging duration determination methods provided in the first, second and third aspects above. Therefore, the technical effects of the implementation method in the fourth aspect can be found above and will not be repeated here.

[0024] Fifthly, this application provides an electronic device including a memory and a processor; the memory stores computer program code, the computer program code including computer instructions; one or more processors invoke the computer instructions to cause the electronic device to execute the charging duration determination method of the first aspect, the charging duration determination method of the second aspect, and the charging duration determination method of the third aspect described above.

[0025] Sixthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for determining the charging duration of the first aspect, the method for determining the charging duration of the second aspect, and the method for determining the charging duration of the third aspect.

[0026] In a seventh aspect, this application provides a computer program product, which includes computer program code. When the computer program code is executed by an electronic device, it implements the method for determining the charging duration in the first aspect, the method for determining the charging duration in the second aspect, and the method for determining the charging duration in the third aspect. Attached Figure Description

[0027] Figure 1a is a schematic diagram of a communication system provided in an embodiment of this application;

[0028] Figure 1b is a schematic diagram of another communication system provided in an embodiment of this application;

[0029] Figure 2a is a schematic diagram of an environmental energy source provided in an embodiment of this application;

[0030] Figure 2b is a schematic diagram of an unstable environmental energy environment provided in an embodiment of this application;

[0031] Figure 2c is a schematic diagram showing a large difference in the energy storage state of an AIoT device provided in an embodiment of this application;

[0032] Figure 2d is a schematic diagram of an AIoT device provided in an embodiment of this application, where the charging time is longer than the discharging time.

[0033] Figure 3 is a signaling interaction diagram of a method for determining charging duration provided in an embodiment of this application;

[0034] Figure 4 is a schematic diagram of controlling an AIoT device to send and return data using the time-slotted ALOHA protocol according to an embodiment of this application;

[0035] Figure 5 is a schematic diagram of an ACK provided in an embodiment of this application;

[0036] Figure 6a is a signaling interaction diagram of a charging duration information reporting method provided in an embodiment of this application;

[0037] Figure 6b is a signaling interaction diagram of another charging duration information reporting method provided in the embodiments of this application;

[0038] Figure 7 is a signaling interaction diagram of another method for determining charging duration provided in an embodiment of this application;

[0039] Figure 8 is a signaling interaction diagram of another charging duration information reporting method provided in the embodiments of this application;

[0040] Figure 9 is a signaling interaction diagram of another charging duration information reporting method provided in an embodiment of this application. Detailed Implementation

[0041] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0042] The embodiments of this application are applied to communication systems, which can be second-generation (2G) communication systems, third-generation (3G) communication systems, long-term evolution (LTE) systems, fifth-generation (5G) communication systems, LTE and 5G hybrid architectures, 5G New Radio (5G NR) systems, and new communication systems that will emerge in the future development of communication.

[0043] In this application embodiment, an example of a communication system can be shown in FIG1a, which includes a base station 101, an AIoT device 102, and a core network 103.

[0044] In this application embodiment, an example of a communication system can also be shown in FIG1b, which includes a base station 101, an AIoT device 102, a core network 103, and a terminal device 104.

[0045] In the embodiments provided in this application, the core network may include a variety of network elements, such as Access and Mobility Management Function (AMF) network elements, application function (AF) network elements, etc., which can be referred to in the description of the embodiments below, and will not be elaborated here.

[0046] In the embodiments provided in this application, the base station can be any device with wireless transceiver capabilities, including but not limited to: evolved Node B (NodeB or eNB or e-NodeB) in LTE systems, base stations (gNodeB or gNB) or transmission receiving points / transmission reception points (TRPs) in new radio (NR), base stations evolved subsequently by 3GPP, access nodes, wireless relay nodes, wireless backhaul nodes, etc. in Wi-Fi systems. The base station can be: macro base station, micro base station, pico base station, small cell, relay station, or balloon station, etc. The base station can include one or more co-located or non-co-located transmission reception points (TRPs). The base station can also be a radio controller, centralized unit (CU), and / or distributed unit (DU) in a cloud radio access network (CRAN) scenario. The base station can communicate with the terminal, or it can communicate with the terminal through a relay station. The terminal can communicate with multiple base stations using different technologies. For example, the terminal can communicate with base stations that support LTE networks, base stations that support 5G networks, and can also establish dual connections with both LTE and 5G base stations.

[0047] In the embodiments provided in this application, the terminal device can take various forms, such as a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, vehicle-mounted terminal device, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, wearable terminal device, etc. A terminal may also be referred to as a terminal device, user equipment (UE), access terminal device, vehicle-mounted terminal, industrial control terminal, UE unit, UE station, mobile station, mobile station, remote station, remote terminal device, mobile device, UE terminal device, terminal device, wireless communication device, UE agent, or UE device, etc. A terminal device can also be a fixed terminal or a mobile terminal.

[0048] In the embodiments provided in this application, AIoT devices are a new type of Internet of Things (IoT) devices that harvest energy from available environmental energy sources and use it as a power source. AIoT devices can be solar sensors, etc., that harvest energy from sunlight and convert it into electrical energy; or vibration energy harvesters that capture energy generated by mechanical vibrations from machines, bridges, buildings, and vehicles, and convert it into electrical energy.

[0049] As shown in Figure 2a, AIoT devices can harvest energy from environmental energy sources such as radio frequency signals, solar energy, geothermal energy, and kinetic energy, and use this energy as a power source. This application does not limit the type of AIoT device.

[0050] The communication systems shown in Figures 1a and 1b above are merely examples. In actual applications, the communication system may include more numbers or types of devices. This application does not limit the specific architecture of the communication system.

[0051] In practical applications, some environmental energy sources are quite weak. For example, radio frequency signals have limited transmission power and attenuation occurs during transmission, resulting in weak energy collection by AIoT devices. Some environmental energy sources are also unstable due to external environmental factors.

[0052] Taking solar energy as an example, AIoT devices are affected by external environmental factors such as time, weather, season, and geographical location. As shown in Figure 2b, AIoT devices collect more energy during the day and less energy at night, resulting in large fluctuations in the energy collected by AIoT devices.

[0053] Furthermore, the energy conversion rate from AIoT devices to electrical energy is relatively low. Also, the energy storage status of multiple AIoT devices can vary significantly, making it difficult to send task requests to multiple AIoT devices simultaneously. As shown in Figure 2c, the energy storage status of AIoT devices 1, 2, and 3 differs significantly. Taking a storage request as an example, assuming the network needs to send storage requests to AIoT devices 1 through 3 simultaneously, as shown in Figure 2c, if AIoT device 2 has insufficient stored energy, it may be unable to reach an active state. This means AIoT device 2 cannot receive the storage request, thus failing to respond and affecting the quality of the storage request task.

[0054] In the above situations, AIoT devices are prone to problems such as energy fluctuations, energy imbalances, and energy limitations. As shown in Figure 2d, the charging power of AIoT devices is much lower than the discharging power, resulting in a longer charging time than the discharging time. In other words, the electrical energy converted from the energy collected by the AIoT device is less than the amount of electrical energy it can generate, which is insufficient to support the fulfillment of task requests (such as inventory requests, read / write operation requests, etc.) sent by the network side (such as the core network, base stations, etc.). It is even possible that the electrical energy stored in the AIoT device is insufficient to keep it in an active state, resulting in the AIoT device being unable to receive task requests from the network side. This leads to a low task response rate and poor task completion quality for the AIoT device.

[0055] Therefore, the network side needs to understand the energy storage status of AIoT devices and initiate task requests when their energy storage status is good. However, the inventors' research revealed that the energy storage status of AIoT devices is dynamic, and determining its energy storage status at a particular moment does not significantly contribute to the quality of task completion. The inventors further discovered that AIoT devices can be charged beforehand to increase their stored energy. Since the network side is unaware of the AIoT device's energy storage status, it is necessary to determine the charging duration of the AIoT device, i.e., the additional energy required to activate the AIoT device. This allows the network to charge the AIoT device based on the determined charging duration when it is needed later, increasing the likelihood of the AIoT device reaching an activated state.

[0056] Based on this, this application provides a method for determining the charging duration. The purpose is to charge AIoT devices based on the determined charging duration, maximizing the energy stored in the AIoT devices to activate them, thereby improving the task response rate and task completion quality of the AIoT devices. In this method, the network side can charge the AIoT devices during a charging period. After the charging period ends, the network side can send information containing a query signal to the AIoT devices, and the charging duration is determined based on the AIoT devices' response time to this information; alternatively, the AIoT devices can autonomously record the charging duration and report it to the network side so that the network side can obtain the charging duration of the AIoT devices. Thus, before sending task requests, the network side can charge the AIoT devices based on the determined charging duration, increasing the energy stored in the AIoT devices. This can activate more AIoT devices, enabling more AIoT devices to receive and complete task requests sent by the network side, thereby improving the task response rate and task completion quality of the AIoT devices.

[0057] First, let's introduce the methods for charging AIoT devices. In some embodiments, AIoT devices can be charged (i.e., powered) through a base station or terminal device communicating with them in a communication system. In this application embodiment, devices that can communicate with AIoT devices and charge them, such as network layer devices (e.g., base stations) or terminal-side devices (e.g., terminal devices), can be referred to as readers / writers. That is, readers / writers can be responsible for receiving and sending uplink and downlink signaling or data in the communication system, and also for charging AIoT devices.

[0058] In this way, there is no need to add other power supplies; instead, the existing resources in the communication system are used to charge the AIoT devices, thus avoiding additional power consumption.

[0059] Next, we will introduce the main body for collecting the charging time of AIoT devices.

[0060] In one possible implementation of this application, the reader may first initiate device access to the AIoT device (i.e., initiate a connection to the AIoT device), and then the reader may determine the required charging time for the AIoT device based on the device access status of the AIoT device.

[0061] In another possible implementation of this application, the AIoT device may autonomously record and determine its required charging time, and then report the charging time.

[0062] Next, we will introduce the methods for determining the charging time for the two different subjects mentioned above.

[0063] It should be noted that the above two methods for determining the charging time are based on the architecture of the communication system shown in Figure 1a, that is, the base station is the reader / writer in Embodiment 1 and Embodiment 2. This method for determining the charging time can also be applied to other applicable communication systems (such as the communication system shown in Figure 1b), and this application does not limit it.

[0064] Example 1:

[0065] Referring to Figure 3, and taking the method of determining the charging time of an AIoT device based on the device access status of the AIoT device as an example, the method for determining the charging time provided in this application embodiment will be introduced. Referring to Figure 3, in this application embodiment, the core network may include AF network elements, AMF network elements, and Network Exposure Function (NEF) network elements.

[0066] As shown in Figure 3, the method for determining the charging time may include the following steps:

[0067] S301: The AF network element sends a task request signaling to the NEF network element.

[0068] Task request signaling is used to request AIoT devices to perform specific tasks. AF network elements can initiate various types of task request signaling based on business needs.

[0069] For example, the task request signaling can be an inventory request signaling, used to trigger the checking and recording of AIoT device inventory-related information to ensure that the stored AIoT device inventory information is consistent with the actual physical inventory of AIoT devices.

[0070] For example, the task request signaling can be read request signaling, used to obtain information or data from the AIoT device. This includes, for instance, querying the status or data of the AIoT device, or reading the configuration information of the AIoT device.

[0071] As another example, the task request signaling can be write request signaling, used to write information or data to the AIoT device. This could be used to update device parameters or configuration information of the AIoT device, or to control the behavior of the AIoT device.

[0072] In one possible implementation, the task request signaling may carry indication information, which indicates the charging duration of the AIoT device.

[0073] In this embodiment of the application, the indication information can indicate various aspects. For example, the indication information can be used to indicate the entity collecting the charging time of the AIoT device, and it can also be used to indicate whether to collect the charging time of the AIoT device. In addition, the indication information can also indicate the collection cycle for the charging time.

[0074] In some embodiments, the indication information can indicate the subject (also referred to as the subject) collecting the charging time of the AIoT device. For example, the indication information can be represented as Indi_coll_Einfo or Coll_Einfo_per, both of which indicate that the subject collecting the charging time of the AIoT device is the reader / writer; the indication information can be represented as Indi_repo_T, indicating that the subject collecting the charging time of the AIoT device is the AIoT device itself, that is, the AIoT device collects its own charging time.

[0075] In some embodiments, the indication information can be used to indicate whether to collect the charging time of the AIoT device during the current task request. For example, the indication information can be represented as Indi_coll_Einfo, where a value of 1 indicates that the charging time of the AIoT device needs to be collected during the current task request, and a value of 0 indicates that the charging time of the AIoT device does not need to be collected during the current task request.

[0076] It should be noted that the value of 1 or 0 for the indication information is only an example and can also be other values. It can be used to distinguish whether to collect the charging time of AIoT devices during this task request.

[0077] In some embodiments, the indication information may be used to indicate the collection cycle of the charging time of the AIoT device.

[0078] For example, when the indication information is represented as Coll_Einfo_per, it can indicate the collection time period of the charging time of the AIoT device, which is collected once every time period. For example, if its value is 1h, it means that the charging time of the AIoT device is collected once every 1h. This application does not limit this.

[0079] For example, when the indication information is represented as Coll_Einfo_per, it can also indicate the collection cycle of the charging time of the AIoT device. It is collected once every preset number of task cycles. For example, if its value is 5 task cycles, it means that the AF network element collects the charging time of the AIoT device once every five task requests. Or, if its value is 5 same task cycles, it means that the AF network element collects the charging time of the AIoT device once every three same task requests (e.g., three inventory requests).

[0080] It should be noted that when the indication information is Coll_Einfo_per, it can indicate both that the charging time of the AIoT device needs to be collected during the current task request process, and the collection cycle of the charging time of the AIoT device. Subsequently, the charging time of the AIoT device can be collected multiple times based on the collection cycle indicated by Coll_Einfo_per.

[0081] In this embodiment, the indication information carried in the task request signaling may be only Indi_coll_Einfo or only Coll_Einfo_per. Alternatively, the indication information may also include Indi_coll_Einfo and Coll_Einfo_per, used to indicate to the reader / writer the duration of multiple collections of the AIoT device's charging time based on the collection cycle.

[0082] Therefore, considering that the capacitors of AIoT devices will gradually age over time, affecting their energy storage capacity, the charging time of AIoT devices can be collected periodically to improve the real-time performance of the charging time and thus improve its accuracy.

[0083] Thus, when the core network needs AIoT devices to perform tasks, it can carry indication information along with the task request signaling to determine the charging time of the AIoT devices, without having to send a separate signaling message carrying the indication information, thereby reducing signaling overhead.

[0084] It should be noted that the above-mentioned AF network element sending task request signaling carrying indication information to determine the charging time of the AIoT device while enabling the AIoT device to perform the task is only an example. The AF network element may also send indication information only to the NEF network element. This application does not limit this.

[0085] For example, an AF network element can send first information to a NEF network element. The first information can be a task request signaling carrying indication information, or it can be the indication information itself. This application does not limit the content of the first information; it can be used to indicate the charging duration of the AIoT device.

[0086] In one possible implementation, the task request signaling may also carry AF authentication information and object selection information, etc.

[0087] AF authentication information refers to information used to authenticate AF network elements. For example, AF authentication information may include AF network element identifiers. AF network element identifiers are used to identify task requests initiated by AF network elements through task request signaling. This allows NEF network elements to identify specific AF network elements and the tasks they represent based on AF network element identifiers. In other words, NEF network elements can verify whether they correspond to a known and authorized AF network element based on AF network element identifiers.

[0088] Object selection information refers to information about the object in which the task request signaling initiated by the AF network element is sent. For example, object selection information may include a list of device identifiers for AIoT devices, task service area information, and device group identifiers for AIoT devices.

[0089] The device identifier list for AIoT devices refers to a list composed of device identifier IDs of multiple AIoT devices. The device ID is used to uniquely identify an AIoT device. In this embodiment, the device identifier list for AIoT devices is used to indicate the object of the task request signaling initiated by the AF network element.

[0090] For example, the device ID of an AIoT device can be its Electronic Product Code (EPC). The device ID can also be reset for each AIoT device; this application does not limit this. For instance, the device identifier list includes the device ID "EPC-1-1" for AIoT device 1, the device ID "EPC-1-96" for AIoT device 96, and the device ID "EPC-2-32" for AIoT device 32, indicating that the task request signaling initiated by the AF network element targets AIoT device 1, AIoT device 96, and AIoT device 32.

[0091] Task service area information refers to the actual geographical location information of AIoT devices, which is used to indicate the target of the task request signaling initiated by the AF network element.

[0092] For example, the task service area information includes the actual geographical location information of warehouses 1-3, which means that the task request signaling initiated by the AF network element is for all AIoT devices in warehouses 1-3.

[0093] The device group identifier of an AIoT device refers to the device group identifier that a device group has when multiple AIoT devices are divided into at least two device groups.

[0094] In some embodiments, the device ID of an AIoT device may include a device group identifier, that is, the identifier fragment of the device ID of an AIoT device is the device group identifier of the AIoT device.

[0095] Based on the example above, AIoT device 1 has a device ID of "EPC-1-1" and a device group identifier of "1", while AIoT device 32 has a device ID of "EPC-2-32" and a device group identifier of "2". For example, if the device group identifier of the AIoT devices carried in the task request signaling is "1", it indicates that the target of the task request signaling initiated by the AF network element includes AIoT device 1 and AIoT device 96 in the above example.

[0096] It should be noted that the device group identifier of an AIoT device is only an example of the identifier fragment of the device ID of the AIoT device. The device group identifier of an AIoT device can also be a separate device group ID, that is, an AIoT device has both a device ID and a device group ID. For example, the device ID of AIoT device 32 is "EPC-32", and the device group ID of AIoT device 32 is "2".

[0097] It should be noted that the task request signaling may carry at least one of the information in the examples above, or it may not carry any information, or it may carry more or more types of information than those mentioned above. This application does not limit this.

[0098] In some embodiments, assuming that the task request signaling initiated by the AF network element does not carry the above-mentioned object selection information, it can be said that the object of the task request signaling initiated by the AF network element is all AIoT devices within the communication range of the reader / writer.

[0099] S302: The NEF network element performs AF authentication on the AF network element and selects the AMF network element.

[0100] In some embodiments, in response to a task request signaling, the NEF network element can perform AF authentication on the AF network element that sends the task request signaling, ensuring that the AF network element is an authorized and verified external application (i.e., a third-party application), thereby maintaining the security and stability of the network.

[0101] For example, AF authentication can verify the identity, permissions, and legality of the task request signaling sent by the AF network element based on the AF identifier mentioned above for NEF network elements.

[0102] It should be noted that AF authentication is an optional step. If the AF network element is a trusted internal application, then the AF authentication step is not required.

[0103] In some embodiments, the NEF network element can parse the task request signaling, determine the network resources or functions it needs to access based on the content of the task request signaling, and identify the AMF network element responsible for handling the network resources or functions. For example, if the task request signaling is an inventory request signaling that involves device access management functions, then an AMF network element capable of handling device access management functions needs to be selected.

[0104] S303: The NEF network element sends a task request signaling to the AMF network element.

[0105] In the previous step, it was introduced that the NEF network element needs to select the AMF network element after performing AF authentication on the AF network element. In the following implementation of S303, the NEF network element sends a task request signaling to the AMF network element selected in S302.

[0106] S304: AMF network element selector / writer.

[0107] In some embodiments, after receiving a task request signaling, the AMF network element can analyze the task request signaling to determine the content of the task request and obtain relevant information about the currently available reader / writer responsible for processing the content of the task request.

[0108] For example, the relevant information about the reader / writer may include the reader / writer's location, coverage area, current load, and the functions or content it handles. The AMF network element can select an available reader / writer that meets the task request based on this information.

[0109] S305: The AMF network element sends N2 information to the reader.

[0110] N2 refers to the interface between the AMF network element and the reader / writer, and N2 information refers to the information exchanged between the AMF network element and the reader / writer.

[0111] In some embodiments, assuming that the reader needs to be able to read the task request signaling, the AMF network element can directly send the N2 information containing the task request signaling to the reader through the N2 interface. That is, the N2 information includes the task request signaling, and the reader can parse the N2 information to directly obtain the task request signaling.

[0112] In some embodiments, assuming that the reader / writer needs to be unable to read the task request signaling, the AMF network element can encapsulate the task request signaling into Non-Access Stratum (NAS) information, and then send the N2 information containing the NAS information to the reader / writer through the N2 interface. That is, the N2 information includes NAS information. The reader / writer can parse the N2 information to obtain the NAS information, but cannot parse the NAS information to obtain the task request signaling.

[0113] The following embodiments use N2 information including NAS information as an example to continue to introduce the method for determining the charging time provided by the embodiments of this application.

[0114] It should be noted that the above example of encapsulating task request signaling into NAS information is just that—an example. It can also be encapsulated into other information to make the task request signaling unreadable to the reader.

[0115] In one possible implementation of this application, if the task request signaling does not carry indication information, the indication information may be generated by the AMF network element. Subsequently, the AMF network element can encapsulate the task request signaling into NAS information and then send the N2 information containing the indication information and NAS information to the reader / writer. This application does not limit this implementation. A description of the indication information can be found in the embodiments above and will not be repeated here.

[0116] It should be noted that S304-S305 above are exemplary implementations when the base station is a reader / writer. When the method for determining the charging duration provided in this application is implemented based on the communication system shown in Figure 1b, that is, when the terminal device is a reader / writer, S304 can specifically be: the AMF network element selects the base station. The implementation of this step can be found in the description of S304 above, and will not be repeated here. Correspondingly, S305 can specifically include the AMF network element sending N2 information to the base station, and the base station sending Access Stratum (AS) information to the reader / writer. In some embodiments, the AS information includes NAS information.

[0117] In addition, in some embodiments, the core network may also include AF network elements, AIoTF network elements, and NEF network elements.

[0118] In one possible implementation, after receiving a task request signaling, the AIoTF network element, in response to the task request signaling, performs the steps of selecting a reader and sending N2 information to the reader. The implementation can be found in S304-S305, and will not be repeated here. The AIoTF network element can be a network element added to the core network. For example, the AIoTF network element can be a network element coexisting with the AMF network element. Also for example, the AIoTF network element can be an independent network element. This application does not limit this.

[0119] S306: The reader charges the AIoT device during the charging period.

[0120] To ensure that AIoT devices are active and can receive signaling from the reader (such as task request signaling), the reader can set a charging period (also known as a preset charging duration) to charge the AIoT device before sending signaling. During the charging process, if the voltage across the AIoT device's capacitor reaches the preset operating threshold, the AIoT device is activated, can begin operating, and can receive signaling from the reader.

[0121] In some embodiments, the reader can power the AIoT device by sending a continuous wave (CW) excitation signal to the AIoT device.

[0122] It should be noted that the CW excitation signal (hereinafter referred to as CW) is only an example, and the reader can also send communication protocol signals to the AIoT device to charge it. This application does not limit this.

[0123] In this embodiment, the charging period for the reader to send CW can be a preset default value, which can be dynamically adjusted after the charging duration of AIoT devices is subsequently collected. For example, the charging period can be preset to 20 seconds, but this application does not limit it.

[0124] It should be noted that, based on the execution of the charging duration determination method provided in this application embodiment, the charging duration of the AIoT device can be determined. Subsequently, the charging period can be adjusted based on the charging duration of the AIoT device to improve the accuracy of the charging period. This allows the reader to charge multiple AIoT devices within a more accurate charging period when a new signaling is received (hereinafter, task request signaling will be used as an example).

[0125] In one possible implementation, assuming the execution of a method for determining charging duration, after the reader determines the charging duration of all AIoT devices within its communication range, it can adjust the charging period based on the charging duration of all AIoT devices.

[0126] In some embodiments, the maximum charging duration among all AIoT devices can be used as the charging period of CW.

[0127] This ensures that all AIoT devices within the reader's communication range are successfully activated, preventing situations where AIoT devices cannot receive task request signals and improving the task response rate of AIoT devices.

[0128] It should be understood that in addition to charging AIoT devices during the charging period, the reader can also charge AIoT devices when sending other signals or data to them (such as query signals, ACKs, etc. mentioned later).

[0129] In some embodiments, the average charging time of all AIoT devices can be calculated and used as the charging period of the CW. Subsequently, other signaling or data sent by the reader to the AIoT devices can continue to charge them, activating any AIoT devices that were not activated after the charging period ends.

[0130] In this way, the task response rate of AIoT devices can be improved while saving the power consumption of the reader.

[0131] In another possible implementation, for AIoT devices without any prior information, a relatively long charging period can be preset. During the current task request process (i.e., during the current execution of the charging duration determination method), if a response from the AIoT device is received (i.e., the AIoT device is successfully activated), the charging period can be reduced in the next task request (i.e., during the next execution of the charging duration determination method). If no response from the AIoT device is received during the current task request process, the charging period can be increased, and so on. This process is repeated in multiple task requests (i.e., multiple executions of the charging duration determination method) until the charging period converges. The converged charging period can be denoted as DCW.

[0132] In some embodiments, a reduction value and an increase value for the charging period can be preset. For example, the reduction value can be a reduction factor, say 2 times, and the increase value can be the average of the charging period during the first task request process and the charging period during the current task request process. Assuming the preset longer charging period is 20 seconds, and during the current task request process, the reader first charges the AIoT device within 20 seconds, and then determines that a response has been received from the AIoT device, then the charging period can be reduced to 20 / 2 = 10 seconds.

[0133] In the next task request process, the reader first charges the AIoT device within 10 seconds. If no response is received from the AIoT device, the charging period can be increased to (20+10) / 2 = 15 seconds. In the next task request process, the reader first charges the AIoT device within 15 seconds. If no response is received from the AIoT device, the charging period can be increased to (20+15) / 2 = 17.5 seconds, and so on. The appropriate charging period DCW for the AIoT device is verified sequentially based on different charging periods.

[0134] In this way, through multiple verification processes, the appropriate charging time for AIoT devices can be determined.

[0135] In some embodiments, after determining the appropriate charging period DCW for the AIoT device, a protection period Δt can be added to it, that is, the charging period of the AIoT device is determined as DCW+Δt.

[0136] Thus, by extending the charging period by increasing the protection duration Δt, the task response rate of AIoT devices can be further improved.

[0137] In addition, in some embodiments, after the reader receives the N2 information, other devices (such as terminal devices) charge the AIoT device during the charging period, and after the charging period ends, the reader continues to execute S307.

[0138] For example, the reader can send a charging instruction message to the terminal device. In response to the charging instruction message, the terminal device charges the AIoT device during the charging period. After the charging period ends, the terminal device can send a charging end message to the reader, and the reader will then continue to execute S307.

[0139] S307: The reader sends AS information to the AIoT device.

[0140] After the reader finishes charging the AIoT device, the reader can send AS information to the AIoT device.

[0141] In some embodiments, the AS information includes initial trigger information (also known as second information), which refers to information used to trigger the AIoT device to send data to the reader (i.e., the return data mentioned later, also known as uplink data) to determine whether the AIoT device is activated.

[0142] In some embodiments, the initial trigger information may include NAS information encapsulating task request signaling and query signaling, etc.

[0143] It should be noted that, assuming the AF network element only sends indication information and does not send task request signaling, the initial trigger information may include query signaling.

[0144] The Query signaling is used to determine whether the AIoT device has been activated after the charging period ends. For example, assuming the AIoT device is activated, it can send return data in response to the Query signaling; assuming the AIoT device is not activated, it cannot receive the Query signaling and therefore cannot send return data to the reader.

[0145] In some embodiments, the Query signaling may carry a slot parameter Q value. The Query signaling carrying the Q value can be used to instruct the AIoT device to select a specific slot to send return data. For related information, please refer to the description of the slotted ALOHA protocol below.

[0146] In some embodiments, the returned data refers to the data returned by the AIoT device to the reader / writer upon receiving the Query signaling. For example, the returned data can be RN16, representing a 16-bit random number.

[0147] The reader responds to valid instructions in the NAS information, that is, instructions to collect information on the charging duration of AIoT devices. The reader can collect information on the charging duration of AIoT devices.

[0148] Based on the above introduction, the reader typically charges all AIoT devices within its communication range. To confirm whether an AIoT device has been activated, a query signal can be sent to the charged AIoT device.

[0149] However, if multiple AIoT devices are activated and at least two AIoT devices send return data simultaneously, it will cause a conflict, affecting the reader's ability to receive the return data, and thus the reader will be unable to determine which AIoT device is activated.

[0150] Therefore, in some embodiments, the Slotted ALOHA protocol can be used to control the data transmission of multiple AIoT devices. The Slotted ALOHA protocol divides time into multiple time slots (also called time slices), and the duration of each slot can be different. The time slot parameter Q mentioned above is used to dynamically adjust the number of time slots. For each AIoT device, a value can be randomly selected between [0, 2Q-1] based on the Q value as the value of the corresponding time slot counter. The value of the corresponding time slot counter decreases continuously as the number of time slots passes; that is, after each time slot, the value of the time slot counter decreases by 1. When the value of the corresponding time slot counter of the AIoT device decreases to 0, the AIoT device sends return data to the reader in the current time slot.

[0151] Assuming that at least two AIoT devices have the same time slot counter value, it indicates that these at least two AIoT devices will send return data to the reader in the same time slot, resulting in a conflict and data transmission failure. After this query round ends (i.e., after the multiple time slots corresponding to the Q value have ended), the Q value can be dynamically adjusted. In the next query round, based on the new Q value, a value is randomly selected between [0, 2Q-1] as the value of the time slot counter corresponding to the AIoT device (the AIoT device that failed to transmit data). This controls the AIoT device that failed to transmit data to send return data to the reader again in the time slot of the next query round until the conflict between the AIoT devices ends.

[0152] In some embodiments, the initial trigger information may also include a Q value, so that after receiving the initial trigger information, the AIoT device can determine the value of its corresponding time slot counter based on the Q value.

[0153] S308: The AIoT device sends return data to the reader.

[0154] The data sent back by an AIoT device (also known as uplink data) indicates that the AIoT device has been activated.

[0155] In some embodiments, the returned data can be RN16.

[0156] Next, the process of S306-S308 will be described with reference to the accompanying drawings. Figure 4 uses the AIoT device to send and return data using the time-slotted ALOHA protocol as an example.

[0157] It should be noted that the slotted ALOHA protocol is only an example, and other protocols may also be used; this application does not limit this.

[0158] Referring to Figure 4, the Reader first charges multiple AIoT devices within its communication range during the charging period. Assuming that the task request signaling carries object selection information, the required AIoT device can be determined from the multiple charged AIoT devices based on the task request object indicated by the object information.

[0159] In some embodiments, assuming the object selection information includes a device group identifier (Group ID), the reader can select an AIoT device with that group identifier based on the Group ID in the received N2 information.

[0160] Referring to Figure 4, assuming the reader selects three AIoT devices based on Group ID, namely Device1, Device2, and Device3 (referred to as D1, D2, and D3), the reader can send Query signaling to D1, D2, and D3 (that is, the reader sends initial trigger information containing Query signaling to D1, D2, and D3). Assuming the Q value of the first query round (Query Round 1) is 2, it indicates that Query Round 1 is divided into four time slots, Slot0-Slot3. A value can be randomly selected between [0, 3] as the value of the time slot counters corresponding to D1, D2, and D3, respectively. For example, the time slot counter value for D1 is 0, and the time slot counter values ​​for D2 and D3 are both 2.

[0161] In Slot 0 of Query Round 1, if the value of the time slot counter corresponding to D1 is 0, D1 can send return data (e.g., RN16 as shown in Figure 4) to the reader, indicating that D1 has returned a response and has been activated. Subsequently, the reader can send an acknowledgment character ACK to D1 to indicate that the reader has received the response returned by D1. In some embodiments, ACK can carry RN16.

[0162] As shown in Figure 4, in each time slot, the reader sends a QueryRep to D1-D3, which instructs the time slot counters corresponding to D1-D3 to decrement by 1. In Slot 3, the time slot counters corresponding to D2 and D3 both decrease from 2 to 0. A conflict occurs when D2 and D3 send data, causing their data transmission to fail, and they need to participate in the next query round. In the next query round, the value of Q can be updated, and based on the updated Q value, the time slot counter values ​​are sent to D2 and D3 so that D2 and D3 can continue sending return data when the time slot counter values ​​drop to 0. This process continues until all activated D1-D3 have sent return data, meaning all D1-D3 have successfully connected. As shown in Figure 4, in the third time slot (Slot 2) of the i-th query round i, D2 successfully sends return data.

[0163] In some embodiments, based on the above description, the reader can determine the charging time of the AIoT device.

[0164] In one possible implementation, the charging time of the AIoT device can be the time interval between the start time when the reader starts charging the AIoT device (which can be called the first start time of the preset charging time) and the time when the reader receives the return data (also referred to as data) sent by the AIoT device (e.g., the AIoT device sends RN16 in Figure 4).

[0165] The moment when the reader receives the return data sent by the AIoT device (which can be called the first reception moment of the uplink data) can be used as the time information of the uplink data.

[0166] Accordingly, the charging duration information for AIoT devices is formatted as a relative timestamp. For example, the ISO 8601 duration representation P(n)Y(n)M(n)DT(n)H(n)M(n)S can be used, where P is the duration indicator, T is the indicator indicating the start of the time element, and Y, M, T, H, M, and S represent year, month, day, hour, minute, and second, respectively. For instance, P0Y0M0DT0H0M25S indicates that the charging duration of the AIoT device is 25 seconds.

[0167] For example, the format ss:mm:μμ can be used, such as 30.500.123, which indicates that the charging time of the AIoT device is 30 seconds, 500 milliseconds, and 123 microseconds.

[0168] As another example, the time interval between the start time of the reader charging the AIoT device and the moment the reader receives the data returned by the AIoT device can be recorded directly in statistical units. For example, if the statistical unit is milliseconds, the charging time of the AIoT device can be obtained by starting the timer when the reader begins charging the AIoT device and stopping the timer when the reader receives the data returned by the AIoT device.

[0169] In this way, the reader can obtain the charging time of the AIoT device based on the recorded time interval.

[0170] In one possible implementation, the charging duration of an AIoT device can be determined based on relevant data from the time-slotted ALOHA protocol. Accordingly, the time information format for the charging duration of the AIoT device is a time-slot offset format.

[0171] Based on the above introduction, AIoT devices can send return data to the reader in time slots. Therefore, the number of time slots corresponding to the AIoT device sending return data in the entire query cycle (which can be called the time cycle) can be determined based on the query round (also known as the device access round) in which the AIoT device sends return data, the number of time slots in that query round (i.e., the time slot in which the AIoT device sends return data), and the number of time slots in each query round. (One query signal corresponds to one query cycle, and one query cycle includes multiple query rounds.)

[0172] Among them, the number of time slots (also known as time slots) corresponding to the return data sent by the AIoT device received by the reader during the entire query cycle can be used as the time information of the uplink data.

[0173] In some embodiments, the time slot during which the reader charges the AIoT device can be defined as time slot 0. Then, the number of time slots corresponding to the AIoT device in the entire query cycle can be determined based on the relevant data of the time slot ALOHA protocol. Subsequently, the charging duration of the AIoT device is determined based on the duration of the charging period and the duration of the time slots in each query round. That is, the charging duration of the AIoT device is determined by the sum of the duration between the start time of the first time slot in the query cycle (that is, the second start time of the start time slot of the time cycle) and the end time of the time slot in which the reader receives the data returned by the AIoT device in the entire query cycle, and the duration of the charging period.

[0174] For example, referring to Figure 4, if D1 sends the return data in time slot 1 of the first query round, then the number of time slots corresponding to D1 in the entire query cycle is 1. Referring to Figure 4, assuming D2 sends the return data in time slot 3 of the third query round, and the number of time slots corresponding to the first and second query rounds are both 4, then the number of time slots corresponding to D2 in the entire query cycle is 11. Assuming the charging period is 20 seconds, the duration of the first time slot in the first query round is 1 second, and the total duration of the first 11 time slots in the entire query cycle is 8 seconds, then the charging time for D1 is 21 seconds, and the charging time for D2 is 28 seconds.

[0175] S309: The reader sends an ACK to the AIoT device.

[0176] In the embodiments of this application, S307-S309 can be referred to as the process by which the reader initiates a random access process to the AIoT device, that is, the process by which the reader and the AIoT device exchange information to achieve a communication connection.

[0177] It should be noted that the random access process for devices may include more or fewer steps than those described above. This application does not limit this, and you can refer to the description of other random access processes for devices later. It will not be elaborated here.

[0178] It needs further explanation that whether the reader / writer knows the device ID of the AIoT device determines the reporting method (reporting to the AMF network element) for the charging duration (hereinafter referred to as charging duration information) of the AIoT device. Based on the above description, the N2 information received by the reader / writer includes NAS information encapsulated with task request signaling. Therefore, in this embodiment, we will first introduce the reporting method for the charging duration information when the reader / writer does not know the device ID of the AIoT device, in conjunction with steps S309-S312. The reporting method for the charging duration information when the reader / writer knows the device ID of the AIoT device will be explained in detail later and will not be described here.

[0179] Considering that the data returned by the AIoT device to the reader is RN16, and the RN16 returned by different AIoT devices is likely to be different, the reader can use RN16 as a temporary identifier of the AIoT device to obtain the device identifier of the AIoT device.

[0180] In some embodiments, the ACK carries the return information RN16 sent by the AIoT device and the charging duration information.

[0181] In some embodiments, the ACK packet may include a packet header, RN16, time format indication information, charging duration information, and check data.

[0182] For example, the ACK packet can use a fixed number of bits as the packet header, that is, use a fixed number of bits as the beginning of the ACK. The time format indication information can be a 1-bit field, with different values ​​indicating different time formats. The check data can be a CRC checksum, used to ensure the integrity of the charging duration information, and can be represented by 8 bits or 16 bits.

[0183] As shown in Figure 5, the data packet header is "01", followed by an adjacent 16-bit RN16. The time format indication information can be 0 or 1. When it is 0, it indicates that the time format used for the charging duration information is a relative timestamp format; when it is 1, it indicates that the time format used for the charging duration information is a timeslot offset format. This is followed by the charging duration information and an 8-bit or 16-bit CRC checksum.

[0184] S310: AIoT devices encapsulate EPC, charging duration information, and AIoT data into NAS information.

[0185] In some embodiments, AIoT data (also referred to as third-party information) refers to relevant data obtained by the AIoT device when executing a task based on task request signaling. After receiving AS information, the AIoT device can parse NAS information to obtain task request signaling and thus execute the task.

[0186] For example, when the task request signaling is an inventory request signaling, the AIoT data can be inventory data, such as the status information of the AIoT device.

[0187] S311: The AIoT device sends AS information to the reader / writer.

[0188] In some embodiments, the AS information includes encapsulated NAS information.

[0189] S312: The reader sends N2 information to the AMF network element.

[0190] In some embodiments, the N2 information includes encapsulated NAS information. The N2 information may also be referred to as fourth information.

[0191] In this way, by using RN16 as a temporary identifier for AIoT devices, the device ID of the AIoT devices can be obtained. Although the reader does not know the device ID, the AMF network element can obtain the device ID by parsing the NAS information, and thus accurately determine the AIoT device corresponding to the charging time, which can support subsequent optimization settings for charging time periods.

[0192] Next, we will introduce the reporting method for the charging duration determined by the reader when the reader knows the device ID of the AIoT device.

[0193] It should be noted that whether the device ID is exposed during the charging duration reporting process can also be divided into two different ways of reporting the charging duration of AIoT devices, which will be introduced in conjunction with Figures 6a and 6b below.

[0194] In one possible implementation, AIoT devices may not explicitly expose their device ID during the task request process, that is, they may not directly transmit the device ID when transmitting data.

[0195] Taking device ID EPC as an example, and referring to Figure 6a, the above S309-S312 can be replaced by the following steps:

[0196] Step 1: The reader sends an ACK to the AIoT device.

[0197] In some embodiments, the ACK includes only the packet header and RN16 shown in Figure 5.

[0198] Step 2: The AIoT device encapsulates the EPC and AIoT data into NAS information.

[0199] Step 3: The AIoT device sends AS information to the reader.

[0200] In some embodiments, the AS information includes encapsulated NAS information.

[0201] Step 4: The reader uses the EPC as an index for the charging duration information.

[0202] In some embodiments, EPC can be sent by the AMF network element to the reader / writer as N2 information. The N2 information includes the task request signaling. After receiving the N2 information, the reader / writer can parse it to obtain the task request signaling and thus obtain the EPC.

[0203] Step 5: The reader sends N2 information to the AMF network element.

[0204] In some embodiments, N2 information includes NAS information and charging duration information indexed by EPC.

[0205] In the embodiments of this application, S307, S308 and step 1 can be referred to as the reader initiating a random device access process to the AIoT device.

[0206] Furthermore, it should be noted that in some embodiments, the ACK sent by the reader to the AIoT device includes RN16. When this ACK does not contain charging duration information, this step is optional. That is, the device random access process initiated by the reader to the AIoT device may include S307 and S308. The same applies to the embodiments described below, and will not be repeated hereafter.

[0207] Therefore, avoiding the exposure of AIoT device IDs during task request can improve the security of the communication system.

[0208] In one possible implementation, AIoT devices can explicitly expose their device ID during the task request process, that is, the device ID is directly transmitted when transmitting data.

[0209] Taking device ID EPC as an example, and referring to Figure 6b, the above S309-S312 can be replaced by the following steps:

[0210] Step 6: The reader sends an ACK to the AIoT device.

[0211] In some embodiments, the ACK includes the packet header and RN16 shown in FIG5.

[0212] Step 7: The AIoT device sends an EPC to the reader.

[0213] Step 8: The reader uses the EPC as an index for the charging duration information.

[0214] Step 9: The reader sends N2 information to the AMF network element.

[0215] In some embodiments, N2 information includes charging duration information indexed by EPC.

[0216] In the embodiments of this application, steps S307, S308, 6 and 7 can be referred to as the reader initiating a random device access process to the AIoT device.

[0217] In this way, explicitly exposing the device ID of the AIoT device during the task request process can reduce the number of data transmissions and improve the speed of obtaining the charging time of the AIoT device.

[0218] S313: AMF network element stores and analyzes the charging time of AIoT devices.

[0219] In some embodiments, the AMF network element includes a Unified Data Management (UDM) module and a Network Data Analytics Function (NWDAF) module. The AMF network element can store charging duration information indexed by device ID to the UDM module. The NWDAF module can retrieve or subscribe to the charging duration information indexed by device ID from the UDM module for analysis.

[0220] It should be understood that in the above embodiments, the time-slotted ALOHA protocol is used to control the data transmission of multiple AIoT devices. The time when the AIoT device sends return data to the reader may be delayed based on a larger value of the acquired time-slot counter. When data transmission conflicts occur, the time when the AIoT device sends return data to the reader may also be delayed, meaning that the charging duration of the AIoT device determined by the reader may have some error. However, in the embodiments of this application, the reader can collect the charging duration of the same AIoT device multiple times based on the indication information in multiple task request signaling.

[0221] In one possible implementation, assuming the NWDAF module determines that there are multiple charging durations for AIoT devices indexed by the same device ID, the NWDAF module can determine the shortest charging duration from these multiple charging durations as the charging duration of the AIoT device.

[0222] This reduces the charging time error caused by the time-slotted ALOHA protocol, further improving the accuracy of the charging time of AIoT devices.

[0223] It should be understood that different AIoT devices may require different charging times. If the charging times of multiple AIoT devices included in a single task request differ significantly, using the maximum charging time among the multiple charging times corresponding to multiple AIoT devices as the charging period of CW may result in an excessively long charging time, wasting resources. On the other hand, using the average charging time among multiple charging times as the charging period of CW may result in fewer AIoT devices being activated, affecting the task response rate of AIoT devices.

[0224] In one possible implementation, the NWDAF module can divide the task batches based on the charging duration of the multiple AIoT devices stored in the UDM module, divide the multiple AIoT devices into different task batches based on the charging duration range, and send task request signaling to the multiple AIoT devices in order of charging duration from shortest to longest (or from longest to shortest) according to the charging duration range.

[0225] For example, using task request signaling as inventory request signaling, with a charging duration range of (0, 5s] and (5s, 10s], assuming the inventory request targets are AIoT devices 1-10, the charging duration of AIoT devices 1-3 is (0, 5s], and the charging duration of AIoT devices 4-10 is (5s, 10s], then they can be divided into two task batches. The AMF network element can first initiate an inventory request to AIoT devices 1-3, and then subsequently initiate an inventory request to AIoT devices 4-10.

[0226] By dividing multiple AIoT devices with varying charging times into different task batches and initiating task requests separately, the number of objects initiating each task request can be reduced, thereby decreasing the probability of data collisions between AIoT devices and improving task success rates. It also facilitates setting charging time periods, reducing resource waste.

[0227] Furthermore, in some embodiments, based on the charging duration of the AIoT devices confirmed by the reader (i.e., the execution of the method for determining the charging duration provided in the embodiments of this application), the number of AIoT devices activated after the charging period can be confirmed, thereby facilitating the setting of the Q value of the time-slot ALOHA protocol based on the number of activated AIoT devices.

[0228] In related technologies, when using the slotted ALOHA protocol, the Q value is usually set based on the number of devices that need to return a response. For example, if the number of objects of the task request signaling, i.e. the number of AIoT devices, is 16, then it is necessary to consider the case where all 16 AIoT devices are activated. The Q value needs to be set based on the total number of AIoT devices, for example, it can be set to 5 or 6, then the corresponding number of time slots is 2Q, that is, there will be 32 time slots or 64 time slots.

[0229] In this embodiment, when using the average charging time of multiple AIoT devices as the charging period of the CW, assuming the charging time of these multiple AIoT devices has been determined, the number of AIoT devices that can be activated can be determined, and the Q value is set based on the number of AIoT devices activated after the charging period. Based on the example above, assuming there are 16 AIoT devices, after the charging period, that is, before the first query round, only 5 AIoT devices can be activated, so the Q value can be reduced, for example, set to 4, then the number of time slots is 16.

[0230] Thus, reducing the Q value can shorten the waiting time and improve the speed of determining the charging time of AIoT devices.

[0231] As can be seen from the above, in this embodiment, the reader can determine the charging duration of the AIoT device based on the device access status. By leveraging the existing random access process for AIoT devices, the communication behavior between the reader and the AIoT device is correlated with the collected charging duration, without affecting task requests or incurring additional signaling overhead. Simultaneously, the core network can optimize the charging period based on the received charging duration of the AIoT device, ensuring that the AIoT device is in an active state and can successfully receive task request signaling. This improves the task response rate and task completion quality of the AIoT device while also saving resources.

[0232] Example 2:

[0233] Next, referring to Figure 7, the method for determining the charging time provided in this application embodiment will be introduced using the method of AIoT devices autonomously recording and determining their required charging time as an example. Referring to Figure 7, in this application embodiment, the core network may also include AF network elements, AMF network elements, and NEF network elements.

[0234] In some embodiments, the AIoT device is configured with a local clock so that it can timestamp the collected data to determine the data collection time; or, the AIoT device can perform tasks based on the local clock at specific events (such as periodically collecting data and periodically sending data); or, the AIoT device can synchronize time based on the local clock to ensure data consistency and coordination (for example, it can synchronize time with the reader based on the Network Time Protocol (NTP)).

[0235] For example, the local clock configured in an AIoT device can be a real-time clock chip, an internal clock of a microcontroller, a low-power oscillator, etc. This application does not limit this.

[0236] In some embodiments, AIoT devices may also periodically obtain time from other devices (such as servers, terminal devices, etc.) via network protocols and synchronize them; this application does not limit this.

[0237] S701: The AF network element sends a task request signaling to the NEF network element.

[0238] Based on the above description, in this embodiment of the application, the indication information carried by the task request signaling can be Indi_repo_T, indicating that the AIoT device is instructed to collect its own charging time.

[0239] In some embodiments, Indi_repo_T can be used to indicate whether the AIoT device collects the charging time of the AIoT device during the current task request process. For example, when its value is 1, it indicates that the AIoT device needs to collect the charging time of the AIoT device during the current task request process, and when its value is 0, it indicates that the AIoT device does not need to collect the charging time of the AIoT device during the current task request process.

[0240] In some embodiments, Indi_repo_T can also be used to indicate the collection cycle for the charging time of AIoT devices.

[0241] For example, Indi_repo_T can be used to indicate the collection period for the charging time of AIoT devices. For instance, a value of 1h indicates that the charging time of AIoT devices is collected every 1 hour.

[0242] For example, Indi_repo_T can be used to indicate the collection cycle of charging time for AIoT devices. For instance, a value of 5 task cycles means that the AIoT device collects its own charging time once every five task requests.

[0243] For other embodiments of S701, please refer to the description of the embodiments of S301, which will not be repeated here.

[0244] S702: The NEF network element performs AF authentication on the AF network element and selects the corresponding AMF network element based on the task request signaling.

[0245] S703: The NEF network element sends a task request signaling to the AMF network element.

[0246] S704: AMF network element selector / writer.

[0247] S705: The AMF network element sends N2 information to the reader / writer.

[0248] S706: The reader charges the AIoT device during the charging period.

[0249] S707: The reader sends AS information to the AIoT device.

[0250] AS information can also be called initial trigger information.

[0251] The implementation methods of S702-S707 can be found in the description of the implementation methods of S302-S307, and will not be repeated here.

[0252] It should be noted that in the embodiment shown in Figure 3, the initial trigger information (also known as the second information) may not contain indication information. However, in the embodiment shown in Figure 7, the difference from the embodiment shown in Figure 3 is that the initial trigger information must contain indication information carried by the task request signaling so that the AIoT device can receive the indication information. For example, in the Indi_repo_T mentioned above, the AIoT device responds to Indi_repo_T and executes the step S708 below to determine its own charging duration.

[0253] S708: AIoT devices record their own charging time.

[0254] In some embodiments, after the AIoT device determines that it has received a valid Indi_repo_T, that is, after receiving the instruction information instructing the AIoT device to collect its own charging time, the AIoT device can start timing based on its local clock from the moment it receives the CW sent by the reader (that is, start timing from the first start moment of the preset charging time) until it is activated. For example, the AIoT device may stop timing when the voltage across its capacitor reaches a pre-configured operating threshold (also called a threshold).

[0255] S709: The AIoT device sends return data to the reader.

[0256] It should be noted that, in this embodiment, the reader and writer have different methods for reporting charging duration information depending on whether the reader and writer know the device ID of the AIoT device. Here, we will first introduce the method for reporting charging duration information when the reader and writer do not know the device ID of the AIoT device (taking EPC as an example).

[0257] In some embodiments, the returned data may include RN16.

[0258] For other implementations of S709, please refer to the description of the implementation of S308, which will not be repeated here.

[0259] S710: The reader sends an ACK to the AIoT device.

[0260] In the embodiments of this application, S707, S709 and S710 can be referred to as the reader initiating a random access process for the AIoT device.

[0261] In some embodiments, the ACK carries the RN16 returned by the AIoT device.

[0262] S711: AIoT devices encapsulate EPC, charging duration information, and AIoT data into NAS information.

[0263] The implementation methods of S710-S711 can be found in the description of the implementation methods of S309-S310, and will not be repeated here.

[0264] Among them, the charging duration information sent by AIoT devices can be used as the time information of uplink data (i.e., returned data).

[0265] S712: AIoT devices send AS information to the reader / writer.

[0266] In some embodiments, the AS information includes encapsulated NAS information.

[0267] S713: The reader sends N2 information to the AMF network element.

[0268] In some embodiments, the N2 information includes encapsulated NAS information.

[0269] In this way, the device ID of the AIoT device does not need to be exposed during the task request process, thereby improving the security of the communication system.

[0270] Next, we will introduce the reporting method for the charging duration determined by the AIoT device when the reader knows the device ID of the AIoT device.

[0271] In some embodiments, when the reader knows the device ID of the AIoT device, there are two different ways to report the charging time of the AIoT device, which will be described in conjunction with Figures 8 and 9 below.

[0272] In one possible implementation, with device ID EPC, and referring to Figure 8, the above S709-S713 can be replaced by the following steps:

[0273] Step 10: The AIoT device sends the return data, EPC, and charging time information to the reader.

[0274] In some embodiments, the returned data includes RN16.

[0275] Step 11: The reader sends an ACK to the AIoT device.

[0276] In some embodiments, ACK includes a packet header and RN16.

[0277] Step 12: The reader uses the EPC as an index for the charging duration information.

[0278] Step 13: The reader sends N2 information to the AMF network element.

[0279] In some embodiments, N2 information includes charging duration information indexed by EPC.

[0280] In the embodiments of this application, S707, step 10 and step 11 can be referred to as the reader initiating a random access process for the AIoT device.

[0281] In this way, when an AIoT device sends back data, it also returns the device ID and charging duration information, which can reduce the number of data transmissions and improve the speed at which the charging duration of the AIoT device is obtained.

[0282] In one possible implementation, with device ID EPC, and referring to Figure 9, the above S709-S713 can be replaced by the following steps:

[0283] Step 14: The AIoT device sends the returned data to the reader.

[0284] In some embodiments, the returned data includes RN16.

[0285] Step 15: The reader sends an ACK to the AIoT device.

[0286] In some embodiments, ACK includes a packet header and RN16.

[0287] Step 16: The AIoT device sends EPC and charging duration information to the reader.

[0288] Step 17: The reader uses the EPC as an index for the charging duration information.

[0289] Step 18: The reader sends N2 information to the AMF network element.

[0290] In some embodiments, N2 information includes charging duration information indexed by EPC.

[0291] In this embodiment of the application, S707 and steps 14-16 can be referred to as the reader initiating a random access process for the AIoT device.

[0292] In this way, after the AIoT device receives the ACK, it returns the device ID and charging duration information. That is, it only transmits data after ensuring that the AIoT device has been successfully connected, thereby ensuring the accuracy of data transmission.

[0293] S714: AMF network element stores and analyzes the charging time of AIoT devices.

[0294] The implementation method of S714 can be found in the description of the implementation method of S313, and will not be repeated here.

[0295] As can be seen from the above, the embodiments of this application adopt the method of AIoT devices autonomously recording their own charging time. AIoT devices can record more accurate charging time, avoiding the charging time error caused by the time slot ALOHA protocol, which can improve the accuracy of the charging time of AIoT devices and avoid wasting resources.

[0296] Furthermore, in Embodiments 1 and 2, after the reader receives the charging duration of the AIoT device, it can continue to store and analyze the charging duration of the AIoT device. The implementation method for this step can be found in the description of the implementation method in S313, and will not be repeated here. This application does not limit the entity that stores and analyzes the charging duration of the AIoT device.

[0297] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, can implement one or more steps in any of the above-described methods for determining charging duration.

[0298] Computer-readable storage media can be non-transitory computer-readable storage media, such as ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage devices.

[0299] Another embodiment of this application provides a computer program product containing instructions. When executed by a computer, this computer program product can implement one or more steps in any of the above-described methods for determining the charging duration.

[0300] The electronic device, computer-readable storage medium, and computer program product provided in this embodiment are all used to execute the corresponding charging time determination method provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding charging time determination method provided above, and will not be repeated here.

[0301] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0302] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0303] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for determining a charging duration, characterized in that, Applied to a reader-writer, comprising: receiving first information; the first information is used to indicate the determination of the charging duration of an environmental Internet of Things (AIoT) device; sending second information to the AIoT device; the second information is used to trigger uplink data; receiving the uplink data sent by the AIoT device and obtaining the time information of the uplink data; based on the time information, obtaining the charging duration of the AIoT device.

2. The method of claim 1, wherein, The first information is used to indicate that the reader-writer determines the charging duration of the AIoT device; based on the time information, the charging duration of the AIoT device is obtained, comprising: based on the time information of receiving the uplink data, determine the charging duration of the AIoT device.

3. The method of claim 2, wherein, The time information is used to indicate the first receiving time when the reader-writer receives the uplink data; based on the time information of receiving the uplink data, determine the charging duration of the AIoT device, comprising: after the end of the preset charging duration, obtain the first starting time of the preset charging duration; based on the time information, obtain the first receiving time when the uplink data is received; the time interval between the first starting time and the first receiving time is determined as the charging duration of the AIoT device.

4. The method of claim 2, wherein, The time information is used to indicate the time slot when the reader-writer receives the uplink data in the time period after the AIoT device receives the second information; based on the time information of receiving the uplink data, determine the charging duration of the AIoT device, comprising: after the end of the preset charging duration, obtain the second starting time of the starting time slot of the time period; based on the time information, obtain the end time of the time slot when the uplink data is received; the sum of the second starting time and the end time and the preset charging duration is determined as the charging duration of the AIoT device.

5. The method of claim 1, wherein, The first information is used to indicate that the AIoT device determines its own charging duration; the second information is used to indicate that the AIoT device determines its own charging duration; the uplink data includes the time information, which is used to indicate the charging duration of the AIoT device.

6. The method of claim 5, wherein, The charging duration of the AIoT device is the time interval between the first starting time of the preset charging duration and the time when the voltage across the capacitor of the AIoT device reaches the threshold value.

7. The method according to any one of claims 1 to 6, characterized in that, The uplink data further comprises at least one of the device identifier and random data of the AIoT device.

8. The method according to any one of claims 1 to 7, characterized in that, The first information is also used to indicate that the AIoT device performs a task; the uplink data further comprises third information, which is used to indicate the execution result of the AIoT device performing the task.

9. The method according to any one of claims 1 to 8, characterized in that, Further comprising: sending fourth information to the core network; the fourth information includes the charging duration of the AIoT device.

10. A method for determining a charging duration, characterized in that Applied to an environmental Internet of Things (AIoT) device, comprising: receiving the second information sent by the reader-writer; the second information is used to trigger uplink data; the second information is sent by the reader-writer after receiving the first information, and the first information is used to indicate the determination of the charging duration of the AIoT device; The read-write device is sent uplink data, so that the read-write device obtains time information of the uplink data, and the read-write device obtains the charging duration of the AIoT device based on the time information.

11. A method for determining a charging duration, characterized in that The application is applied to a core network, and comprises: The read-write device is sent first information, so that the read-write device sends second information to an environmental AIoT device, the read-write device receives uplink data sent by the AIoT device and obtains time information of the uplink data, and the read-write device obtains the charging duration of the AIoT device based on the time information; the first information is used to indicate that the charging duration of the AIoT device is determined; and the second information is used to trigger uplink data.

12. A system for determining a charging duration, characterized by The charging duration determination system comprises a core network, a read-write device and an environmental AIoT device. The core network is configured to send first information to the read-write device; and the first information is used to indicate that the charging duration of the AIoT device is determined. The read-write device is configured to receive the first information sent by the core network and send second information to the AIoT device; and the second information is used to trigger uplink data. The AIoT device is configured to receive the second information sent by the read-write device and send uplink data to the read-write device. The read-write device is further configured to receive the uplink data sent by the AIoT device and obtain time information of the uplink data, and obtain the charging duration of the AIoT device based on the time information.

13. An electronic device, comprising: The electronic device comprises a memory and a processor; The memory is coupled to the processor, and the memory is configured to store computer program code, the computer program code comprises computer instructions, and one or more processors invoke the computer instructions to enable the electronic device to perform the charging duration determination method of any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer program is stored on the computer readable storage medium, and the computer program is executed by the processor to implement the charging duration determination method of any one of claims 1-11.

15. A computer program product, characterised in that, The computer program code is executed by the electronic device to implement the charging duration determination method of any one of claims 1-11.

Images