Method and apparatus for communicating with ambient internet of things (AIOT) device, message sending method and apparatus, and communication device

Abstract

The present application belongs to the technical field of communications. Disclosed are a method and apparatus for communicating with an AIoT device, a message sending method and apparatus, and a communication device. The method for communicating with an AIoT device in the embodiments of the present application comprises: a terminal receiving a first message from a first network device, wherein the first message is used for configuring communication-related parameters for an AIoT device; and on the basis of the first message, the terminal executing the process of communicating with the AIoT device.

Description

Methods, message sending methods, devices, and communication equipment for communicating with environmental IoT (AIoT) devices

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202410976217.X, filed in China on July 19, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application belongs to the field of communication technology, and specifically relates to a method, message sending method, apparatus and communication equipment for communicating with AIoT devices. Background Technology

[0004] Ambient Internet of Things (AIoT), also known as Ambient Power-enabled Internet of Things, is powered through energy harvesting. Related technologies involve two AIoT deployment scenarios: Topology 1, where the base station functions as an AIoT reader; and Topology 2, where intermediate nodes (e.g., user equipment, UE) function as AIoT readers. In Topology 2, the wireless interface includes two transmission interfaces: an AIoT interface (corresponding to the wireless interface between the UE reader and the AIoT device) and a Uu interface (corresponding to the wireless interface between the UE reader and the base station). How the terminal executes the communication process with the AIoT device remains unresolved. Summary of the Invention

[0005] This application provides a method, message sending method, apparatus, and communication device for communicating with AIoT devices, which can solve the problem of how a terminal executes the communication process with AIoT devices.

[0006] Firstly, a method for communicating with AIoT devices is provided, executed by a terminal, the method comprising:

[0007] The terminal receives a first message from the first network device, the first message being used to configure parameters related to AIoT device communication;

[0008] The terminal executes the communication process with the AIoT device based on the first message.

[0009] Secondly, a message sending method is provided, executed by a first network device, the method comprising:

[0010] The first network device sends a first message to the terminal, the first message being used to configure parameters related to AIoT device communication.

[0011] Thirdly, an apparatus for communicating with AIoT devices is provided, the apparatus comprising:

[0012] The first receiving module is configured to receive a first message from the first network device, wherein the first message is used to configure parameters related to communication of the AIoT device.

[0013] The processing module is used to execute the communication process with the AIoT device based on the first message.

[0014] Fourthly, a message sending device is provided, the device comprising:

[0015] The first sending module is used to send a first message to the terminal, the first message being used to configure parameters related to communication of AIoT devices in the environment.

[0016] Fifthly, an apparatus for communicating with AIoT devices is provided, the apparatus being configured to perform the steps of the method described in the first aspect.

[0017] In a sixth aspect, a message sending apparatus is provided, the apparatus being configured to perform the steps of the method described in the second aspect.

[0018] In a seventh aspect, a terminal is provided, the terminal including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method as described in the first aspect.

[0019] Eighthly, a terminal is provided, including a processor and a communication interface, wherein the communication interface is used to: receive a first message from a first network device, the first message being used to configure parameters related to AIoT device communication; and the processor is used to: execute a communication process with the AIoT device based on the first message.

[0020] In a ninth aspect, a network-side device is provided, the network-side device including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method as described in the second aspect.

[0021] In a tenth aspect, a network-side device is provided, including a processor and a communication interface, wherein the communication interface is used to: send a first message to a terminal, the first message being used to configure parameters related to communication of the AIoT device in the environment.

[0022] Eleventhly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect, or implement the steps of the method described in the second aspect.

[0023] In a twelfth aspect, a wireless communication system is provided, comprising: a terminal and a network-side device, wherein the terminal is configured to perform the steps of the method described in the first aspect, and the network-side device is configured to perform the steps of the method described in the second aspect.

[0024] In a thirteenth aspect, a chip is provided, the chip including a processor and a communication interface coupled to the processor, the processor being configured to run a program or instructions to implement the steps of the method described in the first aspect, or to implement the steps of the method described in the second aspect.

[0025] In a fourteenth aspect, a computer program / program product is provided, the computer program / program product being stored in a storage medium, the computer program / program product being executed by at least one processor to implement the steps of the method as described in the first aspect, or to implement the steps of the method as described in the second aspect.

[0026] In this embodiment, the terminal receives a first message from a first network device, the first message being used to configure parameters related to AIoT device communication; based on the first message, the terminal executes a communication process with the AIoT device. Thus, the terminal can execute a communication process with the AIoT device based on the AIoT device communication parameters configured by the first network device. Attached Figure Description

[0027] Figure 1 is a schematic diagram of a network structure applicable to the embodiments of this application;

[0028] Figure 2a is a schematic diagram of the deployment scenario of Topology 1 in the AIoT communication system;

[0029] Figure 2b is a schematic diagram of the deployment scenario of Topology 2 in the AIoT communication system;

[0030] Figure 3 is a flowchart of a method for communicating with an AIoT device according to an embodiment of this application;

[0031] Figure 4 is a flowchart of a message sending method provided in an embodiment of this application;

[0032] Figure 5 is a flowchart of Embodiment 1 provided in this application;

[0033] Figure 6a is a flowchart of Scheme 1 of Embodiment 2 provided in this application;

[0034] Figure 6b is a flowchart of Scheme 2 of Embodiment 2 provided in this application;

[0035] Figure 7 is a structural diagram of a device for communicating with AIoT devices according to an embodiment of this application;

[0036] Figure 8 is a structural diagram of a message sending device provided in an embodiment of this application;

[0037] Figure 9 is a structural diagram of a communication device provided in an embodiment of this application;

[0038] Figure 10 is a structural diagram of a terminal provided in an embodiment of this application;

[0039] Figure 11 is a structural diagram of a network-side device provided in an embodiment of this application. Detailed Implementation

[0040] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0041] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, the first object can be one or more. Furthermore, "or" in this application indicates at least one of the connected objects. For example, the scope of protection for "A or B" covers at least three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. In addition, the terms "A and / or B," "at least one of A and B," and "at least one of A or B" also cover at least the above three scenarios. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0042] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as one in which the sender explicitly informs the receiver of specific information, the operation to be performed, or the requested result, etc., in the instruction sent. An indirect instruction can be understood as one in which the receiver determines the corresponding information based on the instruction sent by the sender, or makes a judgment and determines the operation to be performed or the requested result, etc., based on the judgment result.

[0043] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), or other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used with the systems and radio technologies mentioned above, as well as with other systems and radio technologies. The following description describes New Radio (NR) systems for illustrative purposes, and the term NR is used in most of the following description; however, these technologies can also be applied to systems other than NR systems, such as 6th generation (6G) radio systems. th Generation 6G communication system.

[0044] Figure 1 shows a block diagram of a wireless communication system applicable to an embodiment of this application. The wireless communication system includes a terminal 11 and a network-side device 12. The terminal 11 can be a mobile phone, tablet computer, laptop computer, notebook computer, personal digital assistant (PDA), handheld computer, netbook, ultra-mobile personal computer (UMPC), mobile internet device (MID), augmented reality (AR), virtual reality (VR) device, robot, wearable device, flight vehicle, vehicle user equipment (VUE), shipboard equipment, pedestrian user equipment (PUE), smart home (home devices with wireless communication capabilities, such as refrigerators, televisions, washing machines, or furniture), game console, personal computer (PC), ATM, or self-service machine, etc. Wearable devices include: smartwatches, smart bracelets, smart headphones, smart glasses, smart jewelry (smart bracelets, smart chains, smart rings, smart necklaces, smart anklets, smart anklets, etc.), smart wristbands, smart clothing, etc. Among these, in-vehicle devices can also be referred to as in-vehicle terminals, in-vehicle controllers, in-vehicle modules, in-vehicle components, in-vehicle chips, or in-vehicle units, etc. It should be noted that the specific type of terminal 11 is not limited in this application embodiment. Network-side equipment 12 may include access network equipment or core network equipment, wherein access network equipment may also be referred to as Radio Access Network (RAN) equipment, radio access network function, or radio access network unit. Access network equipment may include base stations, Wireless Local Area Network (WLAN) access points (APs), or Wireless Fidelity (WiFi) nodes, etc.The term "base station" can be referred to as Node B (NB), Evolved Node B (eNB), Next Generation Node B (gNB), New Radio Node B (NR Node B), Access Point, Relay Base Station (RBS), Serving Base Station (SBS), Base Transceiver Station (BTS), Radio Base Station, Radio Transceiver, Basic Service Set (BSS), Extended Service Set (ESS), Home Node B (HNB), Home Evolved Node B, Transmit / Receive Point (TRP), or any other suitable term in the relevant field, as long as the same technical effect is achieved. The term "base station" is not limited to any specific technical terminology. It should be noted that this application embodiment only uses a base station in an NR system as an example for description and does not limit the specific type of base station.

[0045] Core network equipment, also known as core network nodes, core network functions, or core network elements, includes, but is not limited to, at least one of the following: Mobility Management Entity (MME), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Policy Control Function (PCF), Policy and Charging Rules Function (PCRF), Edge Application Server Discovery Function (EASDF), Unified Data Management (UDM), Unified Data Repository (UDR), Home Subscriber Server (HSS), Centralized network configuration (CNC), Network Repository Function (NRF), Network Exposure Function (NEF), Local NEF (or L-NEF), and Binding Support. The core network functions include: BSF (Block Network Function), Application Function (AF), Location Management Function (LMF), Gateway Mobile Location Centre (GMLC), and Network Data Analytics Function (NWDAF). It should be noted that this application embodiment only uses core network equipment in the NR system as an example and does not limit the specific type of core network equipment. If the name of the core network equipment mentioned in this application embodiment changes in subsequent protocol versions (e.g., 6G), it will still be within the scope of protection of this application.

[0046] Optionally, the core network equipment can be implemented by one or more functional modules in a single device, or by multiple devices working together; this application does not specifically limit this. It is understood that the aforementioned functional modules can be network elements in hardware devices, software functional modules running on dedicated hardware, or virtualized functional modules instantiated on a platform (e.g., a cloud platform).

[0047] Before describing the embodiments of this application, the relevant technologies are briefly introduced below:

[0048] I. Ambient IoT (AIoT) Enabled by Ambient Energy

[0049] AIoT is a new IoT technology under the 3rd Generation Partnership Project (3GPP) that is currently under investigation. AIoT devices are powered through energy harvesting; they either do not have batteries or have limited energy storage capacity (e.g., using a capacitor). Energy sources for energy harvesting include radio waves, light, motion, heat, or other suitable energy sources.

[0050] In 3GPP AIoT research, environmental IoT devices are characterized by their energy storage capacity and ability to generate and transmit radio frequency signals. AIoT devices include the following types:

[0051] Type A: No energy storage, no independent signal generation / amplification, i.e., backscatter transmission.

[0052] Type B: It has energy storage but no independent signal generation, i.e., backscatter transmission. The use of stored energy can include amplification of the reflected signal.

[0053] Type C: It has energy storage and independent signal generation, i.e., an active radio frequency component for transmission.

[0054] II. Information Transmission Between Reader and Tag in Radio-Frequency Identification (RFID)

[0055] RFID is a traditional backscatter communication system whose primary design goal is to identify and read data from Base Station Controller (BSC) devices (tags) within the coverage area of ​​a reader. Since RFID was initially used for automated inventory management of large quantities of goods, the process of identifying tags and reading data is also known as inventory management.

[0056] For example, the inventory process for a tag is as follows: After the reader sends a query command, the tag responds. Taking RN16 as an example, the tag generates a 16-bit random number and sends it to the reader. Then, the reader sends this sequence to the tag via an acknowledgment (ACK) command. After the tag successfully verifies the RN16 in the ACK, it sends subsequent data (such as Protocol Control (PC), Extended Protocol Control (XPC), or Electronic Product Code (EPC)) to the reader.

[0057] The instructions for Reader operations can be found in Table 1.

[0058] Table 1

[0059] III. Deployment Scenarios of Ambient IoT Communication

[0060] Migrating RFID to 3GPP AIoT communication systems is currently being discussed in two deployment scenarios:

[0061] Topology 1: The base station performs the AIoT Reader function, as shown in Figure 2a.

[0062] Topology 2: Intermediate nodes (e.g., UE) undertake the AIoT Reader function, as shown in Figure 2b.

[0063] IV. Business Requirements for Ambient IoT (Key Performance Indicators, KPIs)

[0064] 3GPP is discussing how to support inventory-type use cases and has given specific KPI requirements for services. The KPI requirements include the service's QoS requirements (such as the parameter "Max-allowed end-to-end latency").

[0065] 3GPP is also discussing how to support command-type use cases (such as sensor data acquisition scenarios through Read / Write operations), and has given specific KPI requirements for services. The KPI requirements include the QoS requirements of the service (such as the parameter "Max-allowed end-to-end latency").

[0066] For Topology 1, only the AIoT interface (i.e., the wireless air interface between the AIoT device and the base station) is involved. However, for Topology 2, the wireless air interface includes the transmission of two interfaces: one AIoT interface corresponds to the wireless air interface between the AIoT device and the UE Reader, and the other Uu interface corresponds to the wireless air interface between the UE Reader and the base station. How the terminal executes the communication process with the AIoT device, for example, how to break down the end-to-end requirements of an AIoT service into transmission requirements for the AIoT wireless air interface and transmission requirements for the Uu wireless air interface, is a problem to be solved in Topology 2.

[0067] In view of this, embodiments of this application provide a method, message sending method, apparatus, and communication device for communicating with AIoT devices, in order to solve the problem of how a terminal executes the communication process with AIoT devices in the related art.

[0068] The method for communicating with AIoT devices provided in this application will be described in detail below with reference to the accompanying drawings and through some embodiments and application scenarios.

[0069] Figure 3 shows a flowchart of a method for communicating with an AIoT device according to an embodiment of this application. As shown in Figure 3, the method for communicating with an AIoT device includes the following steps:

[0070] Step 301: The terminal receives a first message from the first network device, the first message being used to configure parameters related to AIoT device communication;

[0071] Step 302: The terminal executes the communication process with the AIoT device based on the first message.

[0072] This application's embodiments are applicable to topology 2 communication scenarios. The premise of this application's embodiments is that the network-side device executes a UE Reader node selection process to determine the establishment of a topology 2 communication scenario. According to the UE Reader node selection process, the core network (CN) node notifies a RAN node (i.e., the UE's serving RAN node) that "the UE is authorized to assume the UE Reader function," meaning the UE is the UE Reader.

[0073] In this embodiment of the application, the terminal can be understood as a node with UE Reader function, and the first network device can be, for example, a RAN node.

[0074] The first message is used to configure parameters related to AIoT device communication; therefore, it can be understood as an AIoT-specific configuration message. For the Topology 2 communication scenario, the parameters related to AIoT device communication can include the configuration of the AIoT wireless air interface (hereinafter referred to as the AIoT air interface) and the Uu wireless air interface (hereinafter referred to as the Uu air interface). The AIoT air interface can be understood as the wireless air interface between the AIoT device and the UE Reader, while the Uu air interface can be understood as the wireless air interface between the UE Reader and the base station.

[0075] The above-described communication process with AIoT devices can be understood as the execution of the AIoT wireless air interface process. This AIoT wireless air interface process is used to implement the AIoT services and / or AIoT operations requested by the network device (which may be a RAN node or a CN node).

[0076] In this embodiment, the terminal receives a first message from a first network device, the first message being used to configure parameters related to AIoT device communication; based on the first message, the terminal executes a communication process with the AIoT device. Thus, the terminal can execute a communication process with the AIoT device based on the AIoT device communication parameters configured by the first network device.

[0077] In some embodiments, the parameters related to AIoT device communication include at least one of the following:

[0078] The resource pool parameters for communication between the terminal and the AIoT device;

[0079] The power control parameters for communication between the terminal and AIoT devices;

[0080] At least one set of Uu wireless bearer parameters for transmitting AIoT device data to the terminal;

[0081] Latency budget value for AIoT air interface;

[0082] Uu air interface latency budget value.

[0083] The power control parameters for communication between the terminal and AIoT devices can be understood as the transmission power control parameters for communication between the terminal and AIoT devices.

[0084] Terminal transmission of AIoT device data can be understood as the terminal relaying AIoT device data, and Uu wireless bearer parameters can be understood as the wireless bearer parameters used by the terminal to transmit AIoT device data to the first network device.

[0085] In some embodiments, the resource pool parameters include at least one of the following:

[0086] The first cycle is used to identify the cycle of the resource pool in which the terminal communicates with the AIoT device;

[0087] A time-domain bitmap is used to identify at least one of the following: time units available for AIoT communication within a period of the resource pool, and time units unavailable for AIoT communication within a period of the resource pool;

[0088] The first physical channel information is used to identify the resource location that can be used for device-to-reader (D2R) communication within one cycle of the resource pool;

[0089] The second physical channel information is used to identify the resource location that can be used for reader-to-device (R2D) communication within one cycle of the resource pool;

[0090] First-time information is used to identify the time domain location at which the resource pool parameters take effect;

[0091] The second time information is used to identify the time domain location where the resource pool parameters become invalid (or no longer effective).

[0092] The aforementioned time units can be configured at granularities such as frame, subframe, and slot.

[0093] The first physical channel mentioned above can be called the Physical D2R Channel (Physical Device-to-Reader Channel, PDRCH), and the second physical channel mentioned above can be called the Physical R2D Channel (Physical Reader-to-Device Channel, PRDCH).

[0094] The first time information mentioned above can be understood as the start time information, and the second time information mentioned above can be understood as the end time information.

[0095] As one implementation, the resource pool parameters can be determined by the first network device based on the communication latency between the terminal and the AIoT device. The first network device can obtain the communication latency between the terminal and the AIoT device in advance.

[0096] In some embodiments, the Uu wireless bearer parameters include at least one of the following:

[0097] Radio bearer identity;

[0098] Radio Link Control (RLC) bearer ID;

[0099] RLC channel ID;

[0100] Logical Channel Group (LCG) Identifier (ID);

[0101] Logical Channel Identity (LCID);

[0102] Logical Channel Priority (LCH Priority).

[0103] As one implementation, the Uu wireless bearer parameters can be determined by the first network device based on at least one of the data size of the AIoT device to be relayed and the communication latency between the terminal and the AIoT device. The first network device can obtain the data size of the AIoT device to be relayed and the communication latency between the terminal and the AIoT device in advance.

[0104] In some embodiments, when there is more than one set of Uu wireless bearer parameters configured in the first message, the Uu wireless bearer parameters are associated with at least one of the identifier of the AIoT device and the latency budget value of the Uu air interface.

[0105] The number of Uu wireless bearer parameters can be one or more sets. When there is only one set of Uu wireless bearer parameters, all AIoT device data is transmitted through this single set. When there are multiple sets of Uu wireless bearer parameters, data from some AIoT devices with the same or similar Uu air interface latency budget values ​​can be transmitted through the same set of Uu wireless bearer parameters. That is, one set of multiple Uu wireless bearer parameters can be identified by associating it with at least one AIoT device identifier and / or at least one Uu air interface latency budget value. The AIoT device identifier can be a random number obtained from the AIoT device during inventory (e.g., 16-bit RN16) or a local identifier assigned to the AIoT device by the Reader (e.g., 8-bit local identity). When there is more than one set of Uu wireless bearer parameters, the terminal selects at least one set from the multiple configurations that matches the association information of the obtained AIoT device data (i.e., the AIoT device identifier and / or the Uu air interface latency budget value).

[0106] In some embodiments, the power control parameters include at least one of the maximum transmit power and the minimum transmit power.

[0107] In one implementation, the power control parameters can be determined by the first network device based on the communication range (or distance) between the terminal and the AIoT device. The first network device can obtain the channel range between the terminal and the AIoT device in advance.

[0108] As one implementation method, the terminal uses power control parameters in a manner that includes at least one of the following:

[0109] The terminal's transmit power on the AIoT wireless air interface is less than or equal to the maximum transmit power;

[0110] The terminal's transmit power on the AIoT wireless air interface is greater than or equal to the minimum transmit power.

[0111] In some embodiments, before the terminal receives a first message from the first network device, the method further includes:

[0112] The terminal receives a second message from a second network device, the second message being used to request AIoT services, and the second message containing at least one of the following:

[0113] The types of AIoT services mentioned;

[0114] The identifier of the AIoT device in the AIoT service;

[0115] The number of AIoT devices for the AIoT service;

[0116] The first Quality of Service (QoS) parameter of the AIoT service;

[0117] Based on the second message, the terminal sends a third message to the first network device, the third message containing at least one of the following:

[0118] The transmission parameters of the AIoT air interface of the AIoT service;

[0119] The transmission parameters of the Uu air interface of the AIoT service;

[0120] The transmission parameters of the AIoT air interface and the transmission parameters of the AIoT air interface are obtained by splitting the first QoS parameter.

[0121] The second network device can be understood as a CN node (such as an AMF node or an AIoT function node), and the second message can be understood as a service request message.

[0122] The type of AIoT service refers to the type of AIoT service and / or AIoT operation requested in the service request. Specifically, the AIoT service or AIoT operation can target one or more AIoT devices. AIoT services include inventory-type services (e.g., Inventory) and command-type services (e.g., sensor data collection). AIoT operations include inventory, read, write, enable, disable, and kill operations.

[0123] The identifier of the AIoT device in the AIoT service can consist of the identifiers of one or more AIoT devices.

[0124] The number of AIoT devices in the AIoT service can be a positive integer greater than or equal to 1.

[0125] In this implementation, the CN node initiates a service request, the terminal performs a splitting function based on the QoS parameters of the service request, and the terminal reports the splitting result to the RAN node via a third message. In this case, the terminal can be understood as a functional entity responsible for splitting an end-to-end service requirement into transmission requirements for the AIoT air interface and transmission requirements for the Uu air interface.

[0126] The third message can be understood as an AIoT information report message.

[0127] Accordingly, the RAN node determines the parameter configurations for the AIoT wireless air interface and the Uu wireless air interface based on the splitting results. In other words, the RAN node configures the AIoT device communication-related parameters for the terminal based on the third message sent by the terminal, and then sends this configuration to the terminal via the first message.

[0128] Optionally, the first QoS parameter includes: the first latency budget value of the AIoT service;

[0129] The transmission parameters of the AIoT air interface include: the latency budget value of the AIoT air interface;

[0130] The transmission parameters of the Uu air interface include: the latency budget value of the Uu air interface;

[0131] The latency budget values ​​for the AIoT air interface and the Uu air interface are obtained by splitting the first latency budget value.

[0132] The first latency budget value for AIoT services can be understood as the end-to-end latency budget value for AIoT services. The end-to-end latency budget value can be obtained from the "Max-allowed end-to-end latency" in the service KPI. Assuming that the service data has either ideal latency (0ms) or non-ideal latency (greater than 0ms) when routed on the network side, the required end-to-end latency value can correspond to a value that is equal to or less than the Max-allowed end-to-end latency.

[0133] Optionally, the first QoS parameter further includes at least one of the following:

[0134] The proportion of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0135] The data size of the AIoT service;

[0136] The communication range of the AIoT service;

[0137] The third message also includes at least one of the following:

[0138] The number of AIoT devices to be reached or discovered;

[0139] The size of the AIoT device data to be transferred;

[0140] The range of communication between the terminal and AIoT devices.

[0141] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service can be understood as the effectiveness of the communication service, which can be obtained from the "communication service availability" in the business KPI.

[0142] The size of the AIoT device data to be relayed can also be called the message size, which can be obtained from the "message size" in the business KPI.

[0143] The communication range between the terminal and the AIoT device can be understood as the communication distance between the AIoT device and the terminal. This communication range can be obtained from the "communication range" in the business KPI.

[0144] Regarding how the terminal performs QoS splitting, it can be based on pre-configured or network-side configured QoS mapping rules, or it can be implemented by the UE without configuring QoS mapping rules. Alternatively, how the terminal performs QoS splitting can be entirely dependent on the UE implementation. For example, QoS mapping rules are mainly used to standardize how to split the end-to-end requirements of a service into "AIoT air interface transmission requirements" and / or "Uu air interface transmission requirements." For instance, a 1-second end-to-end latency can be uniformly mapped to a 600ms "AIoT air interface latency budget" and a 400ms "Uu air interface latency budget." Alternatively, based on the number of AIoT devices to be reached / discovered, different latency budget ratios can be flexibly adjusted for the AIoT wireless air interface, such as allocating a higher latency budget to the AIoT wireless air interface. For example, when the number of devices is large, i.e. much greater than 1 (e.g., the number of devices equals 50), the 1s end-to-end latency is mapped to 800ms of "AIoT air interface latency budget" and 200ms of "Uu air interface latency budget" (i.e., the adjustment factor is 0.8); when the number of devices is 1 or small (e.g., the number of devices equals 5), the 1s end-to-end latency is mapped to 500ms of "AIoT air interface latency budget" and 500ms of "Uu air interface latency budget" (i.e., the adjustment factor is 0.5).

[0145] Optionally, the third message further includes at least one of the following:

[0146] The frequency at which the terminal communicates with AIoT devices;

[0147] The transmission bandwidth for communication between the terminal and AIoT devices;

[0148] AIoT devices support the following device types;

[0149] AIoT devices support various communication types.

[0150] The communication frequency between the terminal and AIoT devices can be reported separately based on the communication direction, namely the R2D communication frequency and / or D2R communication frequency. The R2D communication frequency is the Tx frequency of the UE Reader in the AIoT air interface or the Rx frequency of the Device in the AIoT air interface, and the D2R communication frequency is the Rx frequency of the UE Reader in the AIoT air interface or the Tx frequency of the Device in the AIoT air interface.

[0151] The transmission bandwidth for communication between the terminal and AIoT devices can be reported separately based on the communication direction, namely the transmission bandwidth for R2D communication and / or D2R communication. The transmission bandwidth for R2D communication is either the transmit bandwidth of the UE Reader on the AIoT air interface or the receive bandwidth of the Device on the AIoT air interface. The transmission bandwidth for D2R communication is either the receive bandwidth of the UE Reader on the AIoT air interface or the transmit bandwidth of the Device on the AIoT air interface.

[0152] AIoT devices support device types that may include at least one of device type 1, device type 2a, and device type 2b:

[0153] Device type 1: It has energy storage but no independent signal generation / amplification, i.e., backscatter transmission.

[0154] Device type 2a: It has energy storage but no independent signal generation, i.e., backscatter transmission. The use of stored energy can include amplification of the reflected signal.

[0155] Device type 2b: It has energy storage and independent signal generation, i.e., an active radio frequency component for transmission.

[0156] AIoT devices support communication types, for example, including at least one of the following:

[0157] Network-side data is transmitted to A-IoT devices (Device-terminated, DT).

[0158] AIoT devices autonomously initiate data transmission (DO-A), for example, by connecting to a large number of various sensors that collect information about the environment, devices, and organisms and proactively report such information when necessary.

[0159] The network side triggers AIoT devices to initiate data transmission (Device-originated by device-terminated trigger, DO-DTT), such as asset identification, status reporting, and tracking. The Reader collects data from the tag by triggering an inventory / command process. Since the data is generated / initiated within the AIoT device, this service should be considered as a DO service initiated by the tag and controlled by the Reader's command.

[0160] The content carried in the third message is information reported by the terminal in combination with its own wireless capabilities and / or the wireless capabilities of the AIoT device. The content carried in the third message does not depend on the content contained in the second message, and enables the first network device to obtain more multi-dimensional information, thereby enabling the first network device to better configure the communication-related parameters of the AIoT device, and thus enabling the terminal to better execute the communication process with the AIoT device.

[0161] In some embodiments, before the terminal receives a first message from the first network device, the method further includes:

[0162] The terminal receives a fourth message from the first network device, the fourth message being used to request AIoT services, and the fourth message including at least one of the following:

[0163] The types of AIoT services mentioned;

[0164] The identifier of the AIoT device in the AIoT service;

[0165] The number of AIoT devices for the AIoT service;

[0166] The second QoS parameter of the AIoT service.

[0167] In this implementation, the service request is initiated by the first network device.

[0168] The second QoS parameter can be the same as the first QoS parameter, or it can be determined based on the first QoS parameter. The second QoS parameter can be all or part of the first QoS parameter. This application does not limit this.

[0169] Optionally, the second QoS parameter includes: a second latency budget value for the AIoT service;

[0170] The transmission parameters of the AIoT air interface include: the latency budget value of the AIoT air interface;

[0171] The transmission parameters of the Uu air interface include: the latency budget value of the Uu air interface;

[0172] The latency budget values ​​for the AIoT air interface and the Uu air interface are obtained by splitting the second latency budget value.

[0173] The second delay budget value can be the same as the first delay budget value, or it can be determined based on the first delay budget value. When the second delay budget value is the same as the first delay budget value, the second delay budget value is the end-to-end delay budget value. When the second delay budget value is determined based on the first delay budget value, the second delay budget value can be the first delay budget value minus the delay of CN.

[0174] In this embodiment, the first network device performs a splitting function based on the QoS parameters of the service request, and determines the transmission parameter configurations for the AIoT air interface and the Uu air interface based on the splitting result, and sends them to the terminal via a first message. At this point, the first network device can be understood as a functional entity responsible for splitting the end-to-end requirements of a service into transmission requirements for the AIoT air interface and the Uu air interface.

[0175] It should be noted that whether the splitting function is performed by the terminal or by the first network device, the first network device can design the high-level processes of the AIoT wireless air interface and the Uu wireless air interface based on the splitting result, thereby ensuring that the overall transmission performance of the wireless air interface in the Topology 2 communication scenario meets the end-to-end requirements of the service.

[0176] Optionally, the second QoS parameter further includes at least one of the following:

[0177] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0178] The data size of the AIoT service;

[0179] The communication range of the AIoT service.

[0180] In some embodiments, the terminal performs a communication process with the AIoT device based on the first message, including at least one of the following:

[0181] The terminal determines the communication latency with the AIoT device based on the latency budget value of the AIoT air interface;

[0182] The terminal maintains a target counter, and the maximum count value of the target counter is determined based on the number of AIoT devices to be reached or discovered.

[0183] The terminal maintains a target timer, and the maximum runtime of the target timer is determined based on the latency budget value of the AIoT air interface.

[0184] The terminal executes the communication process with the AIoT device, which can be understood as the terminal executing the AIoT wireless air interface process. The AIoT wireless air interface process is used to support AIoT services and / or AIoT operations requested by the second network device or the first network device.

[0185] Optionally, the reset conditions for the target counter include at least one of the following:

[0186] The first message has been received;

[0187] The terminal sent the first message of the AIoT wireless air interface process.

[0188] Specifically, if the terminal receives an AIoT-specific configuration message (i.e., the first message), or if the terminal sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message), the terminal resets the target counter. The target counter increments by 1 each time the terminal receives data from an AIoT device.

[0189] Optionally, the activation conditions of the target timer include at least one of the following:

[0190] The first message has been received;

[0191] The terminal sent the first message of the AIoT wireless air interface process;

[0192] The stopping condition for the target timer includes at least one of the following:

[0193] The number of AIoT devices that have been reached or discovered reaches the maximum count value of the target counter;

[0194] The cumulative runtime of the target timer reaches the latency budget value of the AIoT air interface.

[0195] Specifically, if the terminal receives an AIoT-specific configuration message (i.e., the first message), or if the terminal sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message), the terminal starts the target timer.

[0196] The maximum runtime of the target timer is determined based on the aforementioned latency budget value for the AIoT air interface.

[0197] If the cumulative runtime of the target timer reaches the maximum runtime of the target timer, or if the number of reached / discovered AIoT devices equals the maximum count value of the target counter, then the terminal stops the target timer.

[0198] In some embodiments, the method further includes:

[0199] The terminal sends target data, which includes at least one of the following:

[0200] Data from AIoT devices that have been reached or discovered;

[0201] Information used to indicate whether the communication process with AIoT devices is successful or not.

[0202] In cases where the target data includes data from AIoT devices that have been reached or discovered, the target data can be understood as aggregated data from AIoT devices.

[0203] For inventory use cases, data from AIoT devices can include the identifier of the AIoT device.

[0204] For command use cases, the data of an AIoT device may include the results of the AIoT device's operation in response to the command. For example, for a Read operation, it may be the cached data read; for a Write operation, it may be an indication of whether the write was successful or failed.

[0205] The terminal sends target data, for example, the terminal sends target data to a second network-side device, or the terminal sends target data to a first network-side device, for example, the terminal sends target data to the first network-side device through a Radio Resource Control (RRC) message over the air interface.

[0206] When a terminal sends target data to a first network-side device, the first network-side device can forward the target data to a second network-side device.

[0207] In some embodiments, the terminal sends target data, including:

[0208] The terminal sends target data based on the Uu wireless bearer established by the Uu wireless bearer parameters.

[0209] In other words, the terminal establishes a Uu wireless bearer based on the Uu wireless bearer parameters carried in the first message, and sends aggregated AIoT device data on the Uu wireless bearer.

[0210] In some embodiments, if a first condition is met, the target data includes data from AIoT devices that have been reached or discovered; the first condition includes at least one of the following: the target counter reaches its maximum count value; the target timer stops or times out.

[0211] In some embodiments, if a second condition is met, the target data includes information indicating a successful communication process with the AIoT device; the second condition includes at least one of the following: the target counter reaches its maximum count value; the target timer stops.

[0212] In some embodiments, if a third condition is met, the target data includes information indicating a communication process failure with the AIoT device; the third condition includes at least one of the following: the target counter has not reached its maximum count value; or the target timer has timed out.

[0213] For example, in the case of a target timer timeout, the terminal may send the target data in two possible ways:

[0214] Method 1: The terminal sends data of the AIoT devices that have been reached or discovered, as well as an indication that the communication process with the AIoT devices has failed;

[0215] Method 2: The terminal only sends indication information indicating whether the communication process with the AIoT device is successful or not.

[0216] Method 1 is suitable for use cases involving multiple AIoT devices. If only data from a subset of the AIoT devices is obtained when the target timer expires, the data from those subsets can still be sent to the network-side device along with an additional failure indication.

[0217] Method 2 is suitable for use cases targeting a single AIoT device. For example, when the AIoT device ID is known or during a write operation, only a failure or success indication message can be sent.

[0218] In some embodiments, the method further includes:

[0219] The terminal sends a fifth message to the first network device, the fifth message being used to request the release of the configured parameters related to the communication of the AIoT device.

[0220] The fifth message can be understood as an AIoT information release message, used to request the release of at least one configuration carried in the first message.

[0221] The AIoT information release message (i.e., the fifth message) and the AIoT information report message (i.e., the third message) can be of the same type (e.g., both are UE assistance information) or different types. If the fifth and third messages are of the same type, a change or release of at least one piece of information carried in that message is triggered, implicitly indicating a request to release at least one configuration carried in the first message. If the fifth and third messages are of different types, different message types are triggered, explicitly indicating a request to release at least one configuration carried in the first message.

[0222] In some embodiments, the method further includes:

[0223] The terminal receives a sixth message from the first network device, the sixth message being used to indicate the release of the configured AIoT device communication-related parameters.

[0224] The sixth message can be understood as an AIoT-specific configuration release message.

[0225] It should be noted that when the terminal sends the target data to the first network device through the air interface RRC message, the first network device can know the time when the service is completed. Without the terminal requesting release, the first network device can actively release the parameters related to AIoT device communication.

[0226] The above are implementation examples of the method on the terminal side. The following describes implementation examples of the method on the first network device side.

[0227] Figure 4 shows a flowchart of a message sending method provided in an embodiment of this application. As shown in Figure 4, the message sending method includes the following steps:

[0228] Step 401: The first network device sends a first message to the terminal, the first message being used to configure parameters related to AIoT device communication.

[0229] In this embodiment of the application, the first network device configures AIoT device communication-related parameters, enabling the terminal to execute the communication process with the AIoT device based on the AIoT device communication-related parameters configured by the first network device.

[0230] In some embodiments, the parameters related to AIoT device communication include at least one of the following:

[0231] The resource pool parameters for communication between the terminal and the AIoT device;

[0232] The power control parameters for communication between the terminal and AIoT devices;

[0233] At least one set of Uu wireless bearer parameters for transmitting AIoT device data to the terminal.

[0234] In some embodiments, the resource pool parameters include at least one of the following:

[0235] The first cycle is used to identify the cycle of the resource pool in which the terminal communicates with the AIoT device;

[0236] A time-domain bitmap is used to identify time units available for AIoT communication within a period of the resource pool, and / or to identify time units unavailable for AIoT communication within a period of the resource pool;

[0237] The first physical channel information is used to identify the resource location that can be used for device-to-reader (D2R) communication within one cycle of the resource pool;

[0238] The second physical channel information is used to identify the resource location that can be used for reader-to-device R2D communication within one cycle of the resource pool;

[0239] First-time information is used to identify the time domain location at which the resource pool parameters take effect;

[0240] The second time information is used to identify the time-domain location where the resource pool parameters failed.

[0241] In some embodiments, the Uu wireless bearer parameters include at least one of the following:

[0242] Wireless bearer identifier;

[0243] Radio Link Control (RLC) bearer identifier;

[0244] RLC channel identifier;

[0245] Logical Channel Group (LCG) identifier ID;

[0246] Logical Channel Identifier (LCID);

[0247] Logical channel priority value.

[0248] In some embodiments, when there is more than one set of Uu wireless bearer parameters configured in the first message, the Uu wireless bearer parameters are associated with at least one of the identifier of the AIoT device and the latency budget value of the Uu air interface.

[0249] In some embodiments, the power control parameters include at least one of the maximum transmit power and the minimum transmit power.

[0250] In some embodiments, before the first network device sends the first message to the terminal, the method further includes:

[0251] The first network device receives a third message from the terminal, the third message containing at least one of the following:

[0252] The number of AIoT devices to be reached or discovered;

[0253] The size of the AIoT device data to be transferred;

[0254] The range of communication between the terminal and AIoT devices;

[0255] The latency budget value for the AIoT service;

[0256] The transmission parameters of the AIoT air interface of the AIoT service;

[0257] The transmission parameters of the Uu air interface of the AIoT service;

[0258] The frequency at which the terminal communicates with AIoT devices;

[0259] The transmission bandwidth for communication between the terminal and AIoT devices;

[0260] AIoT devices support the following device types;

[0261] AIoT devices support various communication types.

[0262] In some embodiments, the transmission parameters of the AIoT air interface include: the latency budget value of the AIoT air interface;

[0263] The transmission parameters of the Uu air interface include: the latency budget value of the Uu air interface;

[0264] The latency budget values ​​for the AIoT air interface and the Uu air interface are obtained by splitting the latency budget value for the AIoT service.

[0265] In some embodiments, before the first network device sends the first message to the terminal, the method further includes:

[0266] The first network device sends a fourth message to the terminal, the fourth message being used to request AIoT services, and the fourth message including at least one of the following:

[0267] The types of AIoT services mentioned;

[0268] The identifier of the AIoT device in the AIoT service;

[0269] The number of AIoT devices for the AIoT service;

[0270] The second QoS parameter of the AIoT service.

[0271] In this implementation, the first network device directly initiates a service request to the terminal, so that the terminal can perform the splitting function based on the second QoS parameters of the AIoT service.

[0272] In some embodiments, the second QoS parameter includes at least one of the following:

[0273] The second latency budget value for the AIoT service;

[0274] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0275] The data size of the AIoT service;

[0276] The communication range of the AIoT service.

[0277] In some embodiments, before the first network device sends a fourth message to the terminal, the method further includes:

[0278] The first network device receives a seventh message from the second network device, the seventh message being used to request AIoT services, and the seventh message containing at least one of the following:

[0279] The types of AIoT services mentioned;

[0280] The identifier of the AIoT device in the AIoT service;

[0281] The number of AIoT devices for the AIoT service;

[0282] The first QoS parameter of the AIoT service.

[0283] In this embodiment, the second network device directly sends the service request message (i.e., the seventh message) to the first network device. In this way, the first network device can directly perform the splitting function based on the first QoS parameter of the AIoT service.

[0284] In some embodiments, the first QoS parameter includes at least one of the following:

[0285] The first latency budget value for the AIoT service;

[0286] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0287] The data size of the AIoT service;

[0288] The communication range of the AIoT service.

[0289] In some embodiments, the parameters related to AIoT device communication also include at least one of the following:

[0290] Latency budget value for AIoT air interface;

[0291] Uu air interface latency budget value;

[0292] The latency budget values ​​of the AIoT air interface and the Uu air interface are obtained by splitting the first latency budget value or the second latency budget value.

[0293] It should be noted that, as one implementation method, the first network device first receives the seventh message from the second network device, and then sends the fourth message to the terminal. This implementation method can be understood as the CN node initiating a service request, and the RAN node forwarding the service request from the CN node. This implementation method can be applied to support third-party application services, where the service request first reaches the CN node.

[0294] As an alternative implementation, the first network device does not receive the seventh message from the second network device, but instead directly sends the fourth message to the terminal. This implementation can be understood as the RAN node initiating the service request itself. This approach can be applied to assisted cellular communication services, and the service initiation can be driven by the RAN node's own needs.

[0295] In some embodiments, the method further includes:

[0296] The first network device receives a fifth message from the terminal, the fifth message being used to request the release of configured parameters related to communication of the AIoT device.

[0297] In some embodiments, the method further includes:

[0298] The first network device sends a sixth message to the terminal, the sixth message being used to indicate the release of the configured AIoT device communication-related parameters.

[0299] For related descriptions of the embodiments of this application, please refer to the related descriptions of the method embodiments in Figure 3, which can achieve the same technical effects. To avoid repetition, they will not be described again.

[0300] The following provides several specific embodiments to illustrate the embodiments of this application.

[0301] Example 1: UE Reader-centric solution

[0302] The main idea of ​​this embodiment is as follows: The UE Reader performs a splitting function based on the end-to-end QoS requirements of the service request, and the UE Reader reports the splitting result to the RAN node. The RAN node determines the parameter configuration of the AIoT wireless air interface and the Uu wireless air interface based on the splitting result, and sends them to the UE Reader.

[0303] This embodiment uses Inventory-type business as an example, but it can also be extended to Command-type business.

[0304] As shown in Figure 5, the steps include the following:

[0305] Step 0 (Prerequisite for this embodiment): The network side executes the UE Reader selection procedure to determine the Topology 2 communication scenario. According to the UE Reader selection procedure, the CN node notifies a UE that it is "authorized to assume the UE Reader function," and the CN node notifies a RAN node (i.e., the UE's serving RAN node) that "the UE is authorized to assume the UE Reader function." Understandably, the UE is the UE Reader in Figure 5.

[0306] Step 1: The UE Reader receives a service request message (i.e., the second message) sent by the CN node (e.g., an AMF node or an AIoT Function node). The service request message carries at least one of the following pieces of information:

[0307] The business request refers to the type of AIoT service and / or AIoT operation. Specifically, the AIoT service or AIoT operation can target one or more AIoT devices. AIoT services include inventory-related services (e.g., Inventory) and command-related services (e.g., sensor data collection). AIoT operations include inventory, read, write, enable, disable, and kill operations.

[0308] The AIoT device identifier in the service request. Specifically, the AIoT device identifier may consist of the identifiers of one or more AIoT devices.

[0309] The number of AIoT devices requested in the service request. Specifically, the number of AIoT devices is a positive integer greater than or equal to 1.

[0310] The QoS parameters of the service request. The QoS parameters include at least one of the following:

[0311] End-to-end latency budget. Optionally, the end-to-end latency budget is obtained based on the "Max-allowed end-to-end latency in the business KPI". Assuming that the service data has ideal latency (0ms) or non-ideal latency (greater than 0ms) when routed on the network side, the value of the end-to-end latency requirement can correspond to a value equal to or less than the Max-allowed end-to-end latency.

[0312] Communication service availability. Communication service availability can be understood as the ratio of the number of AIoT devices to be reached / discovered to the total number of AIoT devices requested by the business. Optionally, the communication service availability can be obtained from the "communication service availability" in the business KPIs.

[0313] Message size. The message size can be understood as the data size of the AIoT device. Optionally, the message size can be obtained based on the "message size in business KPIs".

[0314] Communication range. The communication range can be understood as the communication distance between the AIoT device and the UE Reader. Optionally, the business communication range is obtained based on the "communication range in the business KPI".

[0315] Step 2: The UE Reader sends an AIoT information report message (i.e., the third message) to the RAN node. The AIoT information report message carries at least one of the following information:

[0316] Number of AIoT devices to be reached / discovered;

[0317] The data size of the AIoT devices to be relayed;

[0318] The range of communication with AIoT devices;

[0319] Latency budget for AIoT air interface;

[0320] Uu air interface latency budget.

[0321] Optionally, the "number of AIoT devices to be reached / discovered" is obtained based on the "number of AIoT devices" or "communication service effectiveness and number of AIoT devices" in step 1.

[0322] The “data size of the AIoT device to be relayed” is obtained based on the “message size” in step 1.

[0323] The “range of communication with AIoT devices” is obtained based on the “communication range” in step 1.

[0324] The latency budget for the AIoT air interface is obtained from the end-to-end latency budget in step 1.

[0325] The "Uu air interface latency budget" is obtained based on the "end-to-end latency budget" in step 1.

[0326] Optionally, before executing step 2, the UE Reader first performs a QoS splitting function to obtain at least one of the "AIoT air interface latency budget" and "Uu air interface latency budget". Specifically, regarding how the UE Reader performs the QoS splitting function, it can be performed according to pre-configured or network-side configured QoS mapping rules, or it can be performed based on the UE implementation without configuring QoS mapping rules. Alternatively, how the UE Reader performs the QoS splitting function depends entirely on the UE implementation. For example, QoS mapping rules are mainly used to uniformly standardize how to split the end-to-end requirements of a service into "AIoT air interface transmission requirements" and / or "Uu air interface transmission requirements". For example, a 1-second end-to-end latency can be uniformly mapped to a 600ms "AIoT air interface latency budget" and a 400ms "Uu air interface latency budget". Alternatively, by further considering the number of AIoT devices to be reached / discovered, different latency budget ratios can be flexibly adjusted for the AIoT wireless air interface. For example, a higher latency budget can be allocated to the AIoT wireless air interface. For instance, when the number of devices is large (e.g., 50 devices), a 1-second end-to-end latency is mapped to an 800ms "AIoT air interface latency budget" and a 200ms "Uu air interface latency budget" (i.e., an adjustment factor of 0.8). When the number of devices is 1 or less (e.g., 5 devices), a 1-second end-to-end latency is mapped to a 500ms "AIoT air interface latency budget" and a 500ms "Uu air interface latency budget" (i.e., an adjustment factor of 0.5).

[0327] Step 3: The UE Reader receives the AIoT-specific configuration message (i.e., the first message) sent by the RAN node. The AIoT-specific configuration message carries at least one of the following information:

[0328] Resource pool parameter configuration for communicating with AIoT devices

[0329] Uu wireless bearer parameter configuration for relaying AIoT device data

[0330] Configuration of transmit power control parameters for communication with AIoT devices

[0331] Optionally, the "resource pool parameters" in step 3 include at least one of the following parameters:

[0332] Period, used to identify the period of a resource pool;

[0333] A time-domain bitmap is used to identify time units within a period of the resource pool that can be used and / or not used for AIoT communication. For example, the time units can be configured based on granularity such as frame, subframe, slot, etc.

[0334] The PR2DCH channel configuration is used to identify the location of resources available for R2D (Reader-to-Device) communication within a period of the resource pool;

[0335] The PD2RCH channel configuration is used to identify the location of resources available for D2R (Reader-to-Device) communication within a period of the resource pool;

[0336] The start time is used to identify the time-domain position at which the resource pool parameter configuration takes effect.

[0337] The end time is used to identify the time-domain position where the resource pool parameter configuration is no longer effective (i.e., invalid).

[0338] Optionally, the “Uu radio bearer parameters” in step 3 include at least one of the following parameters: radio bearer identity, RLC bearer or RLC channel ID, logical channel group ID, logical channel ID, and logical channel priority value.

[0339] The number of "Uu wireless bearer parameter configurations" can be one or more sets. When there is only one set of "Uu wireless bearer parameter configurations," all AIoT device data is transmitted through that single set. When there are multiple sets of "Uu wireless bearer configurations," data from some AIoT devices that meet the condition of having the same or similar "Uu air interface latency budget" value are transmitted through the same set of "Uu wireless bearer parameter configurations." That is, one set of the multiple "Uu wireless bearer configurations" can be identified by associating at least one AIoT device identifier and / or at least one Uu air interface latency budget value. The AIoT device identifier can be a random number obtained from the AIoT device during inventory (e.g., 16-bit RN16) or a local identifier assigned to the AIoT device by the Reader (e.g., 8-bit local identity). When there are more than one set of Uu wireless bearer parameters, the terminal selects at least one set from the multiple configurations that matches the association information of the obtained AIoT device data (i.e., the AIoT device identifier and / or the Uu air interface latency budget value).

[0340] Optionally, the "transmission power control parameters for communicating with AIoT devices" in step 3 include at least one of the following parameters: maximum transmission power and minimum transmission power.

[0341] In step 2, the “range of communication with AIoT devices” can be used to assist the RAN node in configuring the “transmission power control parameters for communication with AIoT devices” in step 3.

[0342] As one implementation method, the terminal uses power control parameters in a manner that includes at least one of the following:

[0343] The terminal's transmit power on the AIoT wireless air interface is less than or equal to the maximum transmit power;

[0344] The terminal's transmit power on the AIoT wireless air interface is greater than or equal to the minimum transmit power.

[0345] Step 4: The UE Reader executes the AIoT wireless air interface procedure, which is used to support the "AIoT service and / or AIoT operation" requested in Step 1.

[0346] Optionally, the UE Reader determines the latency of the AIoT wireless air interface process based on the "AIoT air interface latency budget" in step 2.

[0347] Optionally, the UE Reader maintains a counter. The counter mechanism satisfies at least one of the following:

[0348] The counter is reset if the condition of step 3, "receiving an AIoT dedicated configuration message, which carries at least one piece of information", is met, or if the condition of step 4, "the UE Reader sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message)" is met, the counter is reset.

[0349] The maximum count value of the counter is determined based on the number of AIoT devices to be reached / discovered in step 2.

[0350] The counter stops when the number of AIoT devices reached / discovered in step 4 equals the maximum count value of the counter.

[0351] Optionally, the UE Reader maintains a timer. The timer mechanism satisfies at least one of the following:

[0352] The timer is started under the following conditions: if step 3, "receiving an AIoT dedicated configuration message, which carries at least one piece of information", is met, or if step 4, "the UE Reader sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message)", is met.

[0353] The maximum runtime of the timer is determined based on the "AIoT air interface latency budget" in step 2.

[0354] The timer stops when the number of AIoT devices reached / discovered in step 4 is equal to the maximum count value of the counter.

[0355] Step 5 (corresponding to the response of Step 1): The UE Reader sends the aggregated AIoT device data (i.e., target data) to the CN node, or the UE Reader sends information (i.e., target data) to the CN node indicating the success or failure of the communication process with the AIoT devices. The aggregated AIoT devices refer to the AIoT devices that were reached / discovered in Step 4.

[0356] For inventory use cases, data from AIoT devices can include the identifier of the AIoT device.

[0357] For command use cases, the data of an AIoT device may include the results of the AIoT device's operation in response to the command. For example, for a Read operation, it may be the cached data read; for a Write operation, it may be an indication of whether the write was successful or failed.

[0358] Optionally, the aggregated AIoT device data is sent to the CN node when the number of "reached / discovered AIoT devices equals the maximum count value of the counter" and / or "the timer stops or times out".

[0359] Optionally, before performing step 5, the UE Reader configures and establishes a Uu radio bearer according to the Uu radio bearer parameters in step 3, and transmits the data of the aggregated AIoT devices on the Uu radio bearer.

[0360] For example, in the case of a target timer timeout, the terminal may send the target data in two possible ways:

[0361] Method 1: The terminal sends data of the AIoT devices that have been reached or discovered, as well as an indication that the communication process with the AIoT devices has failed;

[0362] Method 2: The terminal only sends indication information indicating whether the communication process with the AIoT device is successful or not.

[0363] Method 1 is suitable for use cases involving multiple AIoT devices. If only data from a subset of the AIoT devices is obtained when the target timer expires, the data from those subsets can still be sent to the network-side device along with an additional failure indication.

[0364] Method 2 is suitable for use cases targeting a single AIoT device. For example, when the AIoT device ID is known or during a write operation, only a failure or success indication message can be sent.

[0365] Step 6: The UE Reader sends an AIoT information release message (i.e., the fifth message) to the RAN node. The AIoT information release message is used to request the release of at least one configuration item in step 3.

[0366] Optionally, the AIoT information release message and the AIoT information report message in step 2 can be the same message or different messages. If they are the same message, it triggers a change or release of at least one piece of information carried in the AIoT information report message, implicitly indicating a request to release at least one configuration in step 3. If they are different messages, different message types are triggered, explicitly indicating a request to release at least one configuration in step 3.

[0367] Step 7: The UE Reader receives an AIoT-specific configuration release message (i.e., the sixth message) sent by the RAN node. The AIoT-specific release message indicates the release of at least one piece of information carried in the AIoT-specific configuration message in step 3.

[0368] Optionally, the AIoT-specific configuration release message and the AIoT-specific configuration message in step 3 can be the same type of message or different types of messages. If they are the same type of message, the first indication field in the message distinguishes whether at least one piece of information carried in the AIoT information report message is being established or released. If they are different types of messages, different message types are triggered, corresponding to the establishment and release of at least one configuration in step 3, respectively.

[0369] Example 2: RAN node-centric solution

[0370] The main idea of ​​this embodiment is that, unlike Embodiment 1, the RAN node performs a splitting function based on the end-to-end QoS requirements of the service request. On one hand, the RAN node can send the splitting result to the UE Reader; on the other hand, the RAN node determines the parameter configurations of the AIoT radio interface and the Uu radio interface based on the splitting result and sends them to the UE Reader. Possible implementation schemes include Scheme 1 and Scheme 2.

[0371] Solution 1 is shown in Figure 6a. The figure uses the Inventory class as an example, but it can also be extended to Command class businesses. Solution 1 includes the following steps:

[0372] Step 0 (Prerequisites for this solution): Same as Step 0 in Implementation Example 1.

[0373] Step 1: Same as Step 1 in Example 1.

[0374] Step 2: The UE Reader sends an AIoT information report message (i.e., the third message) to the RAN node. The AIoT information report message carries at least one of the following information:

[0375] Number of AIoT devices to be reached / discovered;

[0376] The data size of the AIoT devices to be relayed;

[0377] The range of communication with AIoT devices;

[0378] End-to-end latency budget.

[0379] Optionally, the "number of AIoT devices to be reached / discovered" is obtained based on the "number of AIoT devices" or "communication service effectiveness and number of AIoT devices" in step 1.

[0380] The “data size of the AIoT device to be relayed” is obtained based on the “message size” in step 1.

[0381] The “range of communication with AIoT devices” is obtained based on the “communication range” in step 1.

[0382] The "end-to-end latency budget" is obtained from the "end-to-end latency budget" in step 1.

[0383] Step 3: The UE Reader receives the AIoT-specific configuration message (i.e., the first message) sent by the RAN node. The AIoT-specific configuration message carries at least one of the following information:

[0384] Resource pool parameter configuration for communication with AIoT devices;

[0385] Uu wireless bearer parameter configuration for relaying AIoT device data;

[0386] Configure transmit power control parameters for communication with AIoT devices;

[0387] Latency budget for AIoT air interface.

[0388] Optionally, the "resource pool parameters" in step 3 include at least one of the following parameters:

[0389] Period, used to identify the period of a resource pool;

[0390] A time-domain bitmap is used to identify time units within a period of the resource pool that can be used and / or not used for AIoT communication. For example, the time units can be configured based on granularity such as frame, subframe, slot, etc.

[0391] The PR2DCH channel configuration is used to identify the location of resources available for R2D (Reader-to-Device) communication within a period of the resource pool;

[0392] The PD2RCH channel configuration is used to identify the location of resources available for D2R (Reader-to-Device) communication within a period of the resource pool;

[0393] The start time is used to identify the time-domain position at which the resource pool parameter configuration takes effect.

[0394] The end time is used to identify the time-domain position where the resource pool parameter configuration is no longer effective (i.e., invalid).

[0395] Optionally, the “Uu radio bearer parameters” in step 3 include at least one of the following parameters: radio bearer identity, RLC bearer or RLC channel ID, logical channel group ID, logical channel ID, and logical channel priority value.

[0396] The number of "Uu wireless bearer parameter configurations" can be one or more sets. When there is only one set of "Uu wireless bearer parameter configurations," all AIoT device data is transmitted through that single set. When there are multiple sets of "Uu wireless bearer configurations," data from some AIoT devices that meet the condition of having the same or similar "Uu air interface latency budget" value are transmitted through the same set of "Uu wireless bearer parameter configurations." That is, one set of the multiple "Uu wireless bearer configurations" can be identified by associating at least one AIoT device identifier and / or at least one latency budget value. The AIoT device identifier can be a random number obtained from the AIoT device during inventory (e.g., 16-bit RN16) or a local identifier assigned to the AIoT device by the Reader (e.g., 8-bit local identity). When there are more than one set of Uu wireless bearer parameters, the terminal selects at least one set from the multiple configurations that matches the association information of the obtained AIoT device data (i.e., the AIoT device identifier and / or the Uu air interface latency budget value).

[0397] Optionally, the "transmission power control parameters for communicating with AIoT devices" in step 3 include at least one of the following parameters: maximum transmission power and minimum transmission power.

[0398] In step 2, the “range of communication with AIoT devices” can be used to assist the RAN node in configuring the “transmission power control parameters for communication with AIoT devices” in step 3.

[0399] As one implementation method, the terminal uses power control parameters in a manner that includes at least one of the following:

[0400] The terminal's transmit power on the AIoT wireless air interface is less than or equal to the maximum transmit power;

[0401] The terminal's transmit power on the AIoT wireless air interface is greater than or equal to the minimum transmit power.

[0402] Optionally, before executing step 3, the RAN node first performs a QoS splitting function to obtain at least one of the "AIoT air interface latency budget" and "Uu air interface latency budget". Specifically, regarding how the RAN node performs the QoS splitting function, it can be performed according to pre-configured or network-side configured QoS mapping rules, or it can be performed based on the RAN implementation without configuring QoS mapping rules. Alternatively, how the RAN node performs the QoS splitting function depends entirely on the RAN implementation. For example, QoS mapping rules are mainly used to uniformly standardize how to split the end-to-end requirements of a service into "AIoT air interface transmission requirements" and / or "Uu air interface transmission requirements". For example, a 1-second end-to-end latency can be uniformly mapped to a 600ms "AIoT air interface latency budget" and a 400ms "Uu air interface latency budget". Alternatively, by further considering the number of AIoT devices to be reached / discovered, different latency budget ratios can be flexibly adjusted for the AIoT wireless air interface, such as allocating a higher latency budget ratio to the AIoT wireless air interface. For example, when the number of devices is large, i.e., much greater than 1 (e.g., the number of devices equals 50), a 1-second end-to-end latency is mapped to an 800ms "AIoT air interface latency budget" and a 200ms "Uu air interface latency budget" (i.e., an adjustment factor of 0.8); when the number is 1 or less (e.g., the number of devices equals 5), a 1-second end-to-end latency is mapped to a 500ms "AIoT air interface latency budget" and a 500ms "Uu air interface latency budget" (i.e., an adjustment factor of 0.5).

[0403] Step 4: The UE Reader executes the AIoT wireless air interface procedure, which is used to support the "AIoT service and / or AIoT operation" requested in Step 1.

[0404] Optionally, the latency of the AIoT wireless air interface process can be determined based on the "latency budget of AIoT air interface" in step 3.

[0405] Optionally, the UE Reader maintains a counter. The counter mechanism satisfies at least one of the following:

[0406] The counter is reset if the condition of step 3, "receiving an AIoT dedicated configuration message, which carries at least one piece of information", is met, or if the condition of step 4, "the UE Reader sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message)" is met, the counter is reset.

[0407] The maximum count value of the counter is determined based on the number of AIoT devices to be reached / discovered in step 2.

[0408] The counter stops when the number of AIoT devices reached / discovered in step 4 equals the maximum count value of the counter.

[0409] Optionally, the UE Reader maintains a timer. The timer mechanism satisfies at least one of the following:

[0410] The timer is started under the following conditions: if step 3, "receiving an AIoT dedicated configuration message, which carries at least one piece of information", is met, or if step 4, "the UE Reader sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message)", is met.

[0411] The maximum runtime of the timer is determined based on the "AIoT air interface latency budget" in step 3.

[0412] The timer stops when the number of AIoT devices reached / discovered in step 4 is equal to the maximum count value of the counter.

[0413] Step 5 (corresponding to the response of step 1): Same as step 5 of embodiment 1.

[0414] Step 6: Same as step 6 in Example 1.

[0415] Step 7: Same as step 7 in Example 1.

[0416] Solution 2 is shown in Figure 6b. The figure uses the Inventory class as an example, but it can also be extended to Command class businesses. Solution 2 includes the following steps:

[0417] Step 0 (Prerequisite for this solution): Same as Step 0 of Implementation Example 1.

[0418] Step 1a: The RAN node receives a service request message (i.e., the seventh message) sent by the CN node (e.g., an AMF node or an AIoT Function node), the service request message carrying at least one of the following information:

[0419] The business request refers to the type of AIoT service and / or AIoT operation. Specifically, the AIoT service or AIoT operation can target one or more AIoT devices. AIoT services include inventory-related services (e.g., Inventory) and command-related services (e.g., sensor data collection). AIoT operations include inventory, read, write, enable, disable, and kill operations.

[0420] The AIoT device identifier in the service request. Specifically, the AIoT device identifier may consist of the identifiers of one or more AIoT devices.

[0421] The number of AIoT devices requested in the service request. Specifically, the number of AIoT devices is a positive integer greater than or equal to 1.

[0422] The QoS parameters of the service request. The QoS parameters include at least one of the following:

[0423] End-to-end latency budget. Optionally, the end-to-end latency budget is obtained based on the "Max-allowed end-to-end latency in the business KPI". Assuming that the service data has ideal latency (0ms) or non-ideal latency (greater than 0ms) when routed on the network side, the value of the end-to-end latency requirement can correspond to a value equal to or less than the Max-allowed end-to-end latency.

[0424] Communication service availability. Communication service availability can be understood as the ratio of the number of AIoT devices to be reached / discovered to the total number of AIoT devices requested by the business. Optionally, the communication service availability can be obtained from the "communication service availability" in the business KPIs.

[0425] Message size. The message size can be understood as the data size of the AIoT device. Optionally, the message size can be obtained based on the "message size in business KPIs".

[0426] Communication range. The communication range can be understood as the communication distance between the AIoT device and the UE Reader. Optionally, the business communication range is obtained based on the "communication range in the business KPI".

[0427] Step 1b: According to step 1a, the RAN node forwards the service request message or part of the information in the service request message (i.e., the fourth message) to the UE node.

[0428] It should be further noted that the difference between the two schemes in Embodiment 2, namely Scheme 1 (Figure 6a) and Scheme 2 (Figure 6b), is that in Scheme 1, the service request message in step 1 is a Non-Access Stratum (NAS) message (therefore, the message content is completely transparent to the RAN node). In Scheme 2, the service request message in step 1a is an N2 interface message, and the service request message in step 1b is an RRC message. (Therefore, the message content can be at least partially or fully visible to the RAN node). Based on this, the main difference between Scheme 2 and Scheme 1 is that the relevant steps reported by the UE Reader in Scheme 1 (steps 2 and 6 in Figure 6a) are not required in Scheme 2 and can be omitted.

[0429] Step 2: The UE Reader receives the AIoT-specific configuration message (i.e., the first message) sent by the RAN node. The AIoT-specific configuration message carries at least one of the following pieces of information:

[0430] Resource pool parameter configuration for communication with AIoT devices;

[0431] Uu wireless bearer parameter configuration for relaying AIoT device data;

[0432] Configure transmit power control parameters for communication with AIoT devices;

[0433] Latency budget for AIoT air interface.

[0434] Optionally, the "resource pool parameters" in step 2 include at least one of the following parameters:

[0435] Period, used to identify the period of a resource pool;

[0436] A time-domain bitmap is used to identify time units within a period of the resource pool that can be used and / or not used for AIoT communication; for example, the time units can be configured based on granularity such as frame, subframe, slot, etc.

[0437] The PR2DCH channel configuration is used to identify the location of resources available for R2D (Reader-to-Device) communication within a period of the resource pool;

[0438] The PD2RCH channel configuration is used to identify the location of resources available for D2R (Reader-to-Device) communication within a period of the resource pool;

[0439] The start time is used to identify the time-domain position at which the resource pool parameter configuration takes effect.

[0440] The end time is used to identify the time-domain position where the resource pool parameter configuration is no longer effective (i.e., invalid).

[0441] Optionally, the “Uu radio bearer parameters” in step 2 include at least one of the following parameters: radio bearer identity, RLC bearer or RLC channel ID, logical channel group ID, logical channel ID, and logical channel priority value.

[0442] The number of "Uu wireless bearer parameter configurations" can be one or more sets. When there is only one set of "Uu wireless bearer parameter configurations," all AIoT device data is transmitted through that single set. When there are multiple sets of "Uu wireless bearer configurations," data from some AIoT devices that meet the condition of having the same or similar "Uu air interface latency budget" value are transmitted through the same set of "Uu wireless bearer parameter configurations." That is, one set of the multiple "Uu wireless bearer configurations" can be identified by associating at least one AIoT device identifier and / or at least one latency budget value. The AIoT device identifier can be a random number obtained from the AIoT device during inventory (e.g., 16-bit RN16) or a local identifier assigned to the AIoT device by the Reader (e.g., 8-bit local identity). When there are more than one set of Uu wireless bearer parameters, the terminal selects at least one set from the multiple configurations that matches the association information of the obtained AIoT device data (i.e., the AIoT device identifier and / or the Uu air interface latency budget value).

[0443] Optionally, the "transmission power control parameters for communicating with AIoT devices" in step 2 include at least one of the following parameters: maximum transmission power and minimum transmission power.

[0444] In step 1a, the “range of communication with AIoT devices” can be used to assist the RAN node in configuring the “transmission power control parameters for communication with AIoT devices” in step 2.

[0445] As one implementation method, the terminal uses power control parameters in a manner that includes at least one of the following:

[0446] The terminal's transmit power on the AIoT wireless air interface is less than or equal to the maximum transmit power;

[0447] The terminal's transmit power on the AIoT wireless air interface is greater than or equal to the minimum transmit power.

[0448] Optionally, before executing step 2, the RAN node first performs a QoS splitting function to obtain at least one of the "AIoT air interface latency budget" and "Uu air interface latency budget". Specifically, regarding how the RAN node performs the QoS splitting function, it can be performed according to pre-configured or network-side configured QoS mapping rules, or it can be performed based on the RAN implementation without configuring QoS mapping rules. Alternatively, how the RAN node performs the QoS splitting function depends entirely on the RAN implementation. For example, QoS mapping rules are mainly used to uniformly standardize how to split the end-to-end requirements of a service into "AIoT air interface transmission requirements" and / or "Uu air interface transmission requirements". For example, a 1-second end-to-end latency can be uniformly mapped to a 600ms "AIoT air interface latency budget" and a 400ms "Uu air interface latency budget". Alternatively, by further considering the number of AIoT devices to be reached / discovered, different latency budget ratios can be flexibly adjusted for the AIoT wireless air interface, such as allocating a higher latency budget ratio to the AIoT wireless air interface. For example, when the number of devices is large, i.e., much greater than 1 (e.g., the number of devices equals 50), a 1-second end-to-end latency is mapped to an 800ms "AIoT air interface latency budget" and a 200ms "Uu air interface latency budget" (i.e., an adjustment factor of 0.8); when the number is 1 or less (e.g., the number of devices equals 5), a 1-second end-to-end latency is mapped to a 500ms "AIoT air interface latency budget" and a 500ms "Uu air interface latency budget" (i.e., an adjustment factor of 0.5).

[0449] Step 3: The UE Reader executes the AIoT wireless air interface procedure, which is used to support the "AIoT service and / or AIoT operation" requested in Step 1b.

[0450] Optionally, the latency of the AIoT wireless air interface process can be determined based on the "latency budget of AIoT air interface" in step 2.

[0451] Optionally, the UE Reader maintains a counter. The counter mechanism satisfies at least one of the following:

[0452] The counter is reset if the condition of step 2, "receiving an AIoT dedicated configuration message, which carries at least one piece of information", is met, or if the condition of step 3, "the UE Reader sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message)" is met, the counter is reset.

[0453] The maximum count value of the counter is determined based on the number of AIoT devices to be reached / discovered in step 3.

[0454] The counter stops when the number of AIoT devices reached / discovered in step 3 is equal to the maximum count value of the counter.

[0455] Optionally, the UE Reader maintains a timer. The timer mechanism satisfies at least one of the following:

[0456] The timer is started under the following conditions: if step 2, "receiving an AIoT dedicated configuration message, which carries at least one piece of information", is met, or if step 3, "the UE Reader sends the first message of the AIoT wireless air interface process (i.e., the Initial Trigger Message or the AIoT Paging Message)", is met.

[0457] The maximum runtime of the timer is determined based on the "AIoT air interface latency budget" in step 2.

[0458] The timer stops when the number of AIoT devices reached / discovered in step 3 is equal to the maximum count value of the counter.

[0459] Step 4a (corresponding to the response of step 1a): The UE Reader sends the aggregated AIoT device data (i.e., target data) to the RAN node, or the UE Reader sends information (i.e., target data) to the CN node indicating the success or failure of the communication process with the AIoT devices. The aggregated AIoT devices refer to the AIoT devices that were reached / discovered in step 3.

[0460] For inventory use cases, data from AIoT devices can include the identifier of the AIoT device.

[0461] For command use cases, the data of an AIoT device may include the results of the AIoT device's operation in response to the command. For example, for a Read operation, it may be the cached data read; for a Write operation, it may be an indication of whether the write was successful or failed.

[0462] Optionally, the aggregated AIoT device data is sent to the RAN node when the number of "reached / discovered AIoT devices equals the maximum count value of the counter" and / or "the timer stops or times out".

[0463] Optionally, before performing step 4a, the UE Reader configures and establishes a Uu radio bearer according to the Uu radio bearer parameters in step 2, and transmits the data of the aggregated AIoT devices on the Uu radio bearer.

[0464] For example, in the case of a target timer timeout, the terminal may send the target data in two possible ways:

[0465] Method 1: The terminal sends data of the AIoT devices that have been reached or discovered, as well as an indication that the communication process with the AIoT devices has failed;

[0466] Method 2: The terminal only sends indication information indicating whether the communication process with the AIoT device is successful or not.

[0467] Method 1 is suitable for use cases involving multiple AIoT devices. If only data from a subset of the AIoT devices is obtained when the target timer expires, the data from those subsets can still be sent to the network-side device along with an additional failure indication.

[0468] Method 2 is suitable for use cases targeting a single AIoT device. For example, when the AIoT device ID is known or during a write operation, only a failure or success indication message can be sent.

[0469] Step 4b: According to step 4a, the RAN node forwards the data of the aggregated AIoT devices to the CN node.

[0470] Step 5: According to step 4a, the UE Reader receives an AIoT-specific configuration release message (i.e., the sixth message) sent by the RAN node. The AIoT-specific release message indicates the release of at least one piece of information carried by the AIoT-specific configuration message in step 2.

[0471] In summary, the embodiments of this application solve the problem of how to decompose the end-to-end requirements of an AIoT service into transmission requirements for the AIoT wireless air interface and the Uu wireless air interface in the Topology 2 scenario, thereby ensuring that the overall transmission performance of the Topology 2 wireless air interface can meet the end-to-end requirements of the service.

[0472] The method for communicating with AIoT devices provided in this application can be executed by a device that communicates with AIoT devices. This application uses an example of a device that communicates with AIoT devices executing the method to illustrate the device for communicating with AIoT devices provided in this application.

[0473] This application provides an apparatus for communicating with AIoT devices. As an example, the apparatus for communicating with AIoT devices can be a communication device or a component within a communication device, such as a chip. The communication device can be a terminal, a network-side device, or a server, etc. Exemplarily, the terminal can be, but is not limited to, the type of terminal 11 listed above, and the network-side device can be, but is not limited to, the type of network-side device 12 listed above. This application does not impose specific limitations.

[0474] The device for communicating with AIoT devices includes a receiving module, a transmitting module, and a processing module. These modules can be implemented in software or hardware. When implemented in hardware, the processing module can be implemented by a processor. For example, the processor can include general-purpose processors, special-purpose processors, such as a Central Processing Unit (CPU), microprocessor, Digital Signal Processor (DSP), Artificial Intelligence (AI) processor, Graphics Processing Unit (GPU), Application Specific Integrated Circuit (ASIC), Network Processor (NP), Field Programmable Gate Array (FPGA), or other programmable logic devices, gate circuits, transistors, discrete hardware components, etc. The receiving and transmitting modules can be implemented by a communication interface, which can include one or more of the following: transceiver, pins, circuits, bus, radio frequency unit, etc.

[0475] Specifically, referring to Figure 7, when the device communicating with the AIoT device is a terminal or a component within a terminal, the device 700 communicating with the AIoT device includes:

[0476] The receiving module 701 is used to receive a first message from the first network device, the first message being used to configure parameters related to AIoT device communication.

[0477] The processing module 702 is used to execute a communication process with the AIoT device based on the first message.

[0478] Optionally, the AIoT device communication-related parameters include at least one of the following:

[0479] The resource pool parameters for communication between the terminal and the AIoT device;

[0480] The power control parameters for communication between the terminal and AIoT devices;

[0481] At least one set of Uu wireless bearer parameters for transmitting AIoT device data to the terminal;

[0482] Latency budget value for AIoT air interface;

[0483] Uu air interface latency budget value.

[0484] Optionally, the resource pool parameters include at least one of the following:

[0485] The first cycle is used to identify the cycle of the resource pool in which the terminal communicates with the AIoT device;

[0486] A time-domain bitmap is used to identify at least one of the following: time units available for AIoT communication within a cycle of the resource pool, and time units unavailable for AIoT communication within a cycle of the resource pool;

[0487] The first physical channel information is used to identify the resource location that can be used for device-to-reader (D2R) communication within one cycle of the resource pool;

[0488] The second physical channel information is used to identify the resource location that can be used for reader-to-device R2D communication within one cycle of the resource pool;

[0489] First-time information is used to identify the time domain location at which the resource pool parameters take effect;

[0490] The second time information is used to identify the time-domain location where the resource pool parameters failed.

[0491] Optionally, the Uu wireless bearer parameters include at least one of the following:

[0492] Wireless bearer identifier;

[0493] Radio Link Control (RLC) bearer identifier;

[0494] RLC channel identifier;

[0495] Logical Channel Group (LCG) identifier ID;

[0496] Logical Channel Identifier (LCID);

[0497] Logical channel priority value.

[0498] Optionally, if there is more than one set of Uu wireless bearer parameters configured in the first message, the Uu wireless bearer parameters are associated with at least one of the AIoT device identifier and the Uu air interface latency budget value.

[0499] Optionally, the power control parameters include at least one of the maximum transmission power and the minimum transmission power.

[0500] Optionally, the device further includes:

[0501] The second receiving module is configured to receive a second message from a second network device, the second message being used to request AIoT services, and the second message containing at least one of the following:

[0502] The types of AIoT services mentioned;

[0503] The identifier of the AIoT device in the AIoT service;

[0504] The number of AIoT devices for the AIoT service;

[0505] The first Quality of Service (QoS) parameter of the AIoT service;

[0506] A first sending module is configured to send a third message to the first network device based on the second message, the third message comprising at least one of the following:

[0507] The transmission parameters of the AIoT air interface of the AIoT service;

[0508] The transmission parameters of the Uu air interface of the AIoT service;

[0509] The transmission parameters of the AIoT air interface and the transmission parameters of the AIoT air interface are obtained by splitting the first QoS parameter.

[0510] Optionally, the device further includes:

[0511] The third receiving module is configured to receive a fourth message from the first network device, the fourth message being used to request AIoT services, and the fourth message including at least one of the following:

[0512] The types of AIoT services mentioned;

[0513] The identifier of the AIoT device in the AIoT service;

[0514] The number of AIoT devices for the AIoT service;

[0515] The second QoS parameter of the AIoT service.

[0516] Optionally, the first QoS parameter includes: a first latency budget value of the AIoT service; or, the second QoS parameter includes: a second latency budget value of the AIoT service.

[0517] The transmission parameters of the AIoT air interface include: the latency budget value of the AIoT air interface;

[0518] The transmission parameters of the Uu air interface include: the latency budget value of the Uu air interface;

[0519] The latency budget values ​​of the AIoT air interface and the Uu air interface are obtained by splitting the first latency budget value or the second latency budget value.

[0520] Optionally, the first QoS parameter further includes at least one of the following:

[0521] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0522] The data size of the AIoT service;

[0523] The communication range of the AIoT service;

[0524] The third message also includes at least one of the following:

[0525] The number of AIoT devices to be reached or discovered;

[0526] The size of the AIoT device data to be transferred;

[0527] The range of communication between the terminal and AIoT devices.

[0528] Optionally, the second QoS parameter further includes at least one of the following:

[0529] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0530] The data size of the AIoT service;

[0531] The communication range of the AIoT service.

[0532] Optionally, the third message further includes at least one of the following:

[0533] The frequency at which the terminal communicates with AIoT devices;

[0534] The transmission bandwidth for communication between the terminal and AIoT devices;

[0535] AIoT devices support the following device types;

[0536] AIoT devices support various communication types.

[0537] Optionally, the processing module 702 is specifically used for at least one of the following:

[0538] Based on the latency budget value of the AIoT air interface, the latency for communication with AIoT devices is determined;

[0539] Maintain a target counter, the maximum count value of which is determined based on the number of AIoT devices to be reached or discovered;

[0540] Maintain a target timer, the maximum runtime of which is determined based on the latency budget value of the AIoT air interface.

[0541] Optionally, the reset conditions for the target counter include at least one of the following:

[0542] The first message has been received;

[0543] The terminal sent the first message of the AIoT wireless air interface process.

[0544] Optionally, the activation conditions of the target timer include at least one of the following:

[0545] The first message has been received;

[0546] The terminal sent the first message of the AIoT wireless air interface process;

[0547] The stopping condition for the target timer includes at least one of the following:

[0548] The number of AIoT devices that have been reached or discovered reaches the maximum count value of the target counter;

[0549] The cumulative runtime of the target timer reaches the latency budget value of the AIoT air interface.

[0550] Optionally, the device further includes:

[0551] The second sending module is used to send target data, the target data including at least one of the following:

[0552] Data from AIoT devices that have been reached or discovered;

[0553] Information used to indicate whether the communication process with AIoT devices is successful or not.

[0554] Optionally, the second sending module is specifically used for:

[0555] Based on the Uu wireless bearer parameters, the Uu wireless bearer is established to transmit target data.

[0556] Optionally, if the first condition is met, the target data includes data from AIoT devices that have been reached or discovered; the first condition includes at least one of the following: the target counter reaches its maximum count value; the target timer stops or times out.

[0557] Optionally, if the second condition is met, the target data includes information indicating a successful communication process with the AIoT device; the second condition includes at least one of the following: the target counter reaches its maximum count value; the target timer stops.

[0558] Optionally, if the third condition is met, the target data includes information indicating a failure in the communication process with the AIoT device; the third condition includes at least one of the following: the target counter has not reached its maximum count value; the target timer has timed out.

[0559] Optionally, the device further includes:

[0560] The third sending module is used to send a fifth message to the first network device, the fifth message being used to request the release of the configured AIoT device communication-related parameters.

[0561] Optionally, the device further includes:

[0562] The fourth receiving module is configured to receive a sixth message from the first network device, the sixth message being used to indicate the release of the AIoT device communication-related parameters configured.

[0563] The apparatus for communicating with AIoT devices provided in this application embodiment can implement the various processes implemented in the method embodiment of FIG3 and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0564] The message sending method provided in this application can be executed by a message sending device. This application uses an example of a message sending device executing the message sending method to illustrate the message sending device provided in this application.

[0565] This application provides a message sending device. As an example, the message sending device may be a communication device or a component within a communication device, such as a chip. The communication device may be a terminal, a network-side device, or a server, etc. Exemplarily, the terminal may include, but is not limited to, the type of terminal 11 listed above, and the network-side device may include, but is not limited to, the type of network-side device 12 listed above. This application does not impose specific limitations.

[0566] The message sending device includes a receiving module, a sending module, and a processing module. These modules can be implemented in software or hardware. When implemented in hardware, the processing module can be implemented by a processor. For example, the processor can include general-purpose processors, special-purpose processors, such as a Central Processing Unit (CPU), microprocessor, Digital Signal Processor (DSP), Artificial Intelligence (AI) processor, Graphics Processing Unit (GPU), Application Specific Integrated Circuit (ASIC), Network Processor (NP), Field Programmable Gate Array (FPGA), or other programmable logic devices, gate circuits, transistors, discrete hardware components, etc. The receiving and sending modules can be implemented by a communication interface, which can include one or more of the following: transceiver, pins, circuits, bus, radio frequency unit, etc.

[0567] Specifically, referring to Figure 8, when the message sending device is a network-side device or a component within a network-side device, the message sending device 800 includes:

[0568] The first sending module 801 is used to send a first message to the terminal, the first message being used to configure parameters related to communication of the AIoT device in the environment.

[0569] Optionally, the AIoT device communication-related parameters include at least one of the following:

[0570] The resource pool parameters for communication between the terminal and the AIoT device;

[0571] The power control parameters for communication between the terminal and AIoT devices;

[0572] At least one set of Uu wireless bearer parameters for transmitting AIoT device data to the terminal.

[0573] Optionally, the resource pool parameters include at least one of the following:

[0574] The first cycle is used to identify the cycle of the resource pool in which the terminal communicates with the AIoT device;

[0575] A time-domain bitmap is used to identify time units available for AIoT communication within a period of the resource pool, and / or to identify time units unavailable for AIoT communication within a period of the resource pool;

[0576] The first physical channel information is used to identify the resource location that can be used for device-to-reader (D2R) communication within one cycle of the resource pool;

[0577] The second physical channel information is used to identify the resource location that can be used for reader-to-device R2D communication within one cycle of the resource pool;

[0578] First-time information is used to identify the time domain location at which the resource pool parameters take effect;

[0579] The second time information is used to identify the time-domain location where the resource pool parameters failed.

[0580] Optionally, the Uu wireless bearer parameters include at least one of the following:

[0581] Wireless bearer identifier;

[0582] Radio Link Control (RLC) bearer identifier;

[0583] RLC channel identifier;

[0584] Logical Channel Group (LCG) identifier ID;

[0585] Logical Channel Identifier (LCID);

[0586] Logical channel priority value.

[0587] Optionally, if there is more than one set of Uu wireless bearer parameters configured in the first message, the Uu wireless bearer parameters are associated with at least one of the AIoT device identifier and the Uu air interface latency budget value.

[0588] Optionally, the power control parameters include at least one of the maximum transmission power and the minimum transmission power.

[0589] Optionally, the device further includes:

[0590] A first receiving module is configured to receive a third message from the terminal, the third message comprising at least one of the following:

[0591] The number of AIoT devices to be reached or discovered;

[0592] The size of the AIoT device data to be transferred;

[0593] The range of communication between the terminal and AIoT devices;

[0594] The latency budget value for the AIoT service;

[0595] The transmission parameters of the AIoT air interface of the AIoT service;

[0596] The transmission parameters of the Uu air interface of the AIoT service;

[0597] The frequency at which the terminal communicates with AIoT devices;

[0598] The transmission bandwidth for communication between the terminal and AIoT devices;

[0599] AIoT devices support the following device types;

[0600] AIoT devices support various communication types.

[0601] Optionally, the transmission parameters of the AIoT air interface include: the latency budget value of the AIoT air interface;

[0602] The transmission parameters of the Uu air interface include: the latency budget value of the Uu air interface;

[0603] The latency budget values ​​for the AIoT air interface and the Uu air interface are obtained by splitting the latency budget value for the AIoT service.

[0604] Optionally, the device further includes:

[0605] The second sending module is configured to send a fourth message to the terminal, the fourth message being used to request AIoT services, and the fourth message including at least one of the following:

[0606] The types of AIoT services mentioned;

[0607] The identifier of the AIoT device in the AIoT service;

[0608] The number of AIoT devices for the AIoT service;

[0609] The second Quality of Service (QoS) parameter for the AIoT service.

[0610] Optionally, the second QoS parameter includes at least one of the following:

[0611] The second latency budget value for the AIoT service;

[0612] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0613] The data size of the AIoT service;

[0614] The communication range of the AIoT service.

[0615] Optionally, the device further includes:

[0616] The second receiving module is configured to receive a seventh message from the second network device, the seventh message being used to request AIoT services, and the seventh message including at least one of the following:

[0617] The types of AIoT services mentioned;

[0618] The identifier of the AIoT device in the AIoT service;

[0619] The number of AIoT devices for the AIoT service;

[0620] The first QoS parameter of the AIoT service.

[0621] Optionally, the first QoS parameter includes at least one of the following:

[0622] The first latency budget value for the AIoT service;

[0623] The proportion of the number of AIoT devices to be reached or discovered to the total number of AIoT devices in the AIoT service;

[0624] The data size of the AIoT service;

[0625] The communication range of the AIoT service.

[0626] Optionally, the AIoT device communication-related parameters may further include at least one of the following:

[0627] Latency budget value for AIoT air interface;

[0628] Uu air interface latency budget value;

[0629] The latency budget values ​​of the AIoT air interface and the Uu air interface are obtained by splitting the first latency budget value or the second latency budget value.

[0630] Optionally, the device further includes:

[0631] The third receiving module is used to receive a fifth message from the terminal, the fifth message being used to request the release of the configured AIoT device communication-related parameters.

[0632] Optionally, the device further includes:

[0633] The third sending module is used to send a sixth message to the terminal, the sixth message being used to indicate the release of the AIoT device communication-related parameters configured.

[0634] The message sending device provided in this application embodiment can implement the various processes implemented in the method embodiment of FIG4 and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0635] As shown in Figure 9, this application embodiment also provides a communication device 900, including a processor 901 and a memory 902. The memory 902 stores programs or instructions that can run on the processor 901. For example, when the communication device 900 is a terminal, the program or instructions executed by the processor 901 implement the various steps of the above-described terminal-side method embodiment and achieve the same technical effect. When the communication device 900 is a network-side device, the program or instructions executed by the processor 901 implement the various steps of the above-described first network device-side method embodiment and achieve the same technical effect. To avoid repetition, further details are omitted here.

[0636] This application also provides a terminal, including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the steps in the method embodiment shown in FIG3. This terminal embodiment corresponds to the above-described terminal-side method embodiment, and all implementation processes and methods of the above-described method embodiments can be applied to this terminal embodiment and can achieve the same technical effect. The terminal can be the device shown in FIG7 that communicates with AIoT devices. Specifically, FIG10 is a schematic diagram of the hardware structure of a terminal implementing an embodiment of this application.

[0637] The terminal 1000 includes, but is not limited to, at least some of the following components: radio frequency unit 1001, network module 1002, audio output unit 1003, input unit 1004, sensor 1005, display unit 1006, user input unit 1007, interface unit 1008, memory 1009, and processor 1010.

[0638] Those skilled in the art will understand that the terminal 1000 may also include a power supply (such as a battery) for powering various components. The power supply can be logically connected to the processor 1010 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The terminal structure shown in Figure 10 does not constitute a limitation on the terminal. The terminal may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0639] It should be understood that, in this embodiment, the input unit 1004 may include a graphics processor 10041 and a microphone 10042. The graphics processor 10041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 1006 may include a display panel 10061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 1007 includes a touch panel 10071 and at least one of other input devices 10072. The touch panel 10071 is also called a touch screen. The touch panel 10071 may include a touch detection device and a touch controller. Other input devices 10072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.

[0640] In this embodiment, after receiving downlink data from the network-side device, the radio frequency unit 1001 can transmit it to the processor 1010 for processing; in addition, the radio frequency unit 1001 can send uplink data to the network-side device. Typically, the radio frequency unit 1001 includes, but is not limited to, antennas, amplifiers, transceivers, couplers, low-noise amplifiers, duplexers, etc.

[0641] The memory 1009 can be used to store software programs or instructions, as well as various data. The memory 1009 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 1009 may include volatile memory or non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 1009 in this embodiment includes, but is not limited to, these and any other suitable types of memory.

[0642] The processor 1010 may include one or more processing units; optionally, the processor 1010 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor 1010.

[0643] The radio frequency unit 1001 is used for:

[0644] Receive a first message from a first network device, the first message being used to configure parameters related to AIoT device communication;

[0645] Processor 1010 is used for:

[0646] Based on the first message, the communication process with the AIoT device is executed.

[0647] In this embodiment, the terminal receives a first message from a first network device, the first message being used to configure parameters related to AIoT device communication; based on the first message, the terminal executes a communication process with the AIoT device. Thus, the terminal can execute a communication process with the AIoT device based on the AIoT device communication parameters configured by the first network device.

[0648] It is understood that the implementation process of each implementation method mentioned in this embodiment can refer to the relevant description of the method embodiment for communicating with AIoT devices, and achieve the same or corresponding technical effects. To avoid repetition, it will not be described again here.

[0649] This application also provides a network-side device, including a processor and a communication interface. The communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the steps of the method embodiment shown in FIG4. This network-side device embodiment corresponds to the first network device method embodiment described above. All implementation processes and methods of the above method embodiments can be applied to this network-side device embodiment and can achieve the same technical effect.

[0650] Specifically, this application embodiment also provides a network-side device, which may be the message sending device shown in FIG8. As shown in FIG11, the network-side device 1100 includes: an antenna 111, a radio frequency device 112, a baseband device 113, a processor 114, and a memory 115. The antenna 111 is connected to the radio frequency device 112. In the uplink direction, the radio frequency device 112 receives information through the antenna 111 and sends the received information to the baseband device 113 for processing. In the downlink direction, the baseband device 113 processes the information to be sent and sends it to the radio frequency device 112. The radio frequency device 112 processes the received information and sends it out through the antenna 111.

[0651] The method executed by the network-side device in the above embodiments can be implemented in the baseband device 113, which includes a baseband processor.

[0652] The baseband device 113 may include at least one baseband board, on which multiple chips are disposed, as shown in FIG11. One of the chips is, for example, a baseband processor, which is connected to the memory 115 via a bus interface to call the program in the memory 115 and execute the network device operation shown in the above method embodiment.

[0653] The network-side device may also include a network interface 116, such as a Common Public Radio Interface (CPRI).

[0654] Specifically, the network-side device 1100 in this application embodiment further includes: instructions or programs stored in memory 115 and executable on processor 114. Processor 114 calls the instructions or programs in memory 115 to execute the methods executed by each module shown in FIG8 and achieve the same technical effect. To avoid repetition, it will not be described in detail here.

[0655] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described method embodiments for communicating with AIoT devices, or the various processes of the above-described message sending method embodiments, and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0656] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. In some examples, the readable storage medium may be a non-transient readable storage medium.

[0657] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described method embodiment for communicating with AIoT devices, or to implement the various processes of the above-described message sending method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0658] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0659] This application also provides a computer program / program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described method embodiment for communicating with AIoT devices, or to implement the various processes of the above-described message sending method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0660] This application also provides a communication system, including: a terminal and a network-side device, wherein the terminal can be used to perform the steps of the method for communicating with an AIoT device as described above, and the network-side device can be used to perform the steps of the message sending method as described above.

[0661] Optionally, the communication system may further include a second network-side device.

[0662] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0663] From the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of computer software products plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disk, optical disk, etc.) and includes several instructions to cause the terminal or network-side device to execute the methods described in the various embodiments of this application.

[0664] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other implementations under the guidance of this application without departing from the spirit and scope of the claims. All of these implementations are within the protection scope of this application.

Claims

1. A method of communicating with an ambient Internet of Things, AIoT, device, comprising: receiving, by a terminal, a first message from a first network device, the first message being used to configure AIoT device communication related parameters; performing, by the terminal, a communication procedure with the AIoT device based on the first message.

2. The method of claim 1, wherein, The AIoT device communication related parameters comprise at least one of: a resource pool parameter for the terminal to communicate with the AIoT device; a power control parameter for the terminal to communicate with the AIoT device; at least one set of Uu radio bearer parameters for the terminal to transmit AIoT device data; a latency budget value of an AIoT air interface; a latency budget value of a Uu air interface.

3. The method of claim 2, wherein, The resource pool parameter comprises at least one of: a first periodicity, used to identify a periodicity of a resource pool for the terminal to communicate with the AIoT device; a time domain bitmap, used to identify at least one of: time units in a periodicity of the resource pool that can be used for AIoT communication, time units in the periodicity of the resource pool that cannot be used for AIoT communication; first physical channel information, used to identify resource locations in the periodicity of the resource pool that can be used for device-to-reader, D2R, communication; second physical channel information, used to identify resource locations in the periodicity of the resource pool that can be used for reader-to-device, R2D, communication; first time information, used to identify a time domain location at which the resource pool parameter takes effect; second time information, used to identify a time domain location at which the resource pool parameter ceases to be effective.

4. The method of claim 2, wherein, The Uu radio bearer parameter comprises at least one of: a radio bearer identifier; a radio link control, RLC, bearer identifier; an RLC channel identifier; a logical channel group, LCG, identifier, ID; a logical channel identifier, LCID; a logical channel priority value.

5. The method of claim 4, wherein, In a case where a quantity of the Uu radio bearer parameters configured by the first message is more than one set, the Uu radio bearer parameter is associated with at least one of an identifier of the AIoT device and a latency budget value of the Uu air interface.

6. The method of claim 2, wherein, The power control parameter comprises at least one of a maximum transmission power and a minimum transmission power.

7. The method of any one of claims 1 to 6, wherein, Before the terminal receives the first message from the first network device, the method further comprises: receiving, by the terminal, a second message from a second network device, the second message being used to request an AIoT service, the second message comprising at least one of: a type of the AIoT service; an identifier of an AIoT device of the AIoT service; a quantity of AIoT devices of the AIoT service; a first quality of service, QoS, parameter of the AIoT service; sending, by the terminal, a third message to the first network device based on the second message, the third message comprising at least one of: a transmission parameter of an AIoT air interface of the AIoT service; a transmission parameter of a Uu air interface of the AIoT service; wherein the transmission parameter of the AIoT air interface of the AIoT service and the transmission parameter of the Uu air interface of the AIoT service are obtained by splitting based on the first QoS parameter; or, Before the terminal receives the first message from the first network device, the method further comprises: The terminal receives a fourth message from the first network device, the fourth message being used for requesting an AIoT service, and the fourth message comprising at least one of the following: a type of the AIoT service; an identifier of an AIoT device of the AIoT service; a number of AIoT devices of the AIoT service; a second QoS parameter of the AIoT service.

8. The method of claim 7, wherein, The first QoS parameter comprises a first latency budget value of the AIoT service, or the second QoS parameter comprises a second latency budget value of the AIoT service. A transmission parameter of the AIoT air interface, comprising a latency budget value of the AIoT air interface. A transmission parameter of the Uu air interface, comprising a latency budget value of the Uu air interface. The latency budget value of the AIoT air interface and the latency budget value of the Uu air interface are obtained by splitting the first latency budget value or the second latency budget value.

9. The method of claim 7 or 8, wherein, The first QoS parameter further comprises at least one of the following: a proportion of a number of AIoT devices to be reached or discovered to a number of AIoT devices of the AIoT service; a data size of the AIoT service; a communication range of the AIoT service. The third message further comprises at least one of the following: a number of AIoT devices to be reached or discovered; a data size of AIoT device data to be relayed; a range of communication between the terminal and the AIoT device. Or, The second QoS parameter further comprises at least one of the following: a proportion of a number of AIoT devices to be reached or discovered to a number of AIoT devices of the AIoT service; a data size of the AIoT service; a communication range of the AIoT service.

10. The method of any one of claims 7 to 9, wherein, The third message further comprises at least one of the following: a frequency of communication between the terminal and the AIoT device; a transmission bandwidth of communication between the terminal and the AIoT device; a device type supported by the AIoT device; a communication type supported by the AIoT device.

11. The method of claim 2 or 8 or 9, wherein, The terminal performs a communication process with the AIoT device based on the first message, comprising at least one of the following: The terminal determines a latency of communication with the AIoT device based on the latency budget value of the AIoT air interface. The terminal maintains a target counter, and a maximum count value of the target counter is determined based on the number of AIoT devices to be reached or discovered. The terminal maintains a target timer, and a maximum running duration of the target timer is determined based on the latency budget value of the AIoT air interface.

12. The method of claim 11, wherein, A reset condition of the target counter comprises at least one of the following: receiving the first message; sending, by the terminal, a first message of the process of the AIoT wireless air interface. And / or, A start condition of the target timer comprises at least one of the following: receiving the first message; sending, by the terminal, a first message of the process of the AIoT wireless air interface. A stop condition of the target timer comprises at least one of the following: a number of AIoT devices that have been reached or discovered reaches a maximum count value of the target counter; an accumulated running duration of the target timer reaches the latency budget value of the AIoT air interface.

13. The method of any one of claims 7-12, further comprising: the terminal sending target data, the target data comprising at least one of: data of the AIoT device that has been reached or discovered; information indicating success or failure of a communication procedure with the AIoT device.

14. The method of claim 13, wherein, the terminal sending target data, comprising: the terminal sending target data based on a Uu radio bearer established by the Uu radio bearer parameter.

15. The method of claim 13 or 14, wherein, in a case where a first condition is met, the target data comprising data of the AIoT device that has been reached or discovered; the first condition comprising at least one of: the target counter reaching a maximum count value of the target counter; the target timer stopping or timing out; or, in a case where a second condition is met, the target data comprising information indicating success of a communication procedure with the AIoT device; the second condition comprising at least one of: the target counter reaching a maximum count value of the target counter; the target timer stopping; or, in a case where a third condition is met, the target data comprising information indicating failure of a communication procedure with the AIoT device; the third condition comprising at least one of: the target counter not reaching a maximum count value of the target counter; the target timer timing out.

16. The method of any one of claims 13-15, further comprising: the terminal sending a fifth message to the first network device, the fifth message being used to request release of the configured AIoT device communication related parameter.

17. The method of any one of claims 13-16, further comprising: the terminal receiving a sixth message from the first network device, the sixth message being used to indicate release of the configured AIoT device communication related parameter.

18. A message sending method, comprising: a first network device sending a first message to a terminal, the first message being used to configure an Ambient Internet of Things (AIoT) device communication related parameter.

19. The method of claim 18, wherein, the AIoT device communication related parameter comprising at least one of: a resource pool parameter for the terminal to communicate with an AIoT device; a power control parameter for the terminal to communicate with an AIoT device; at least one set of Uu radio bearer parameter for the terminal to transmit AIoT device data.

20. The method of claim 19, wherein, the resource pool parameter comprising at least one of: a first periodicity, used to identify a periodicity of a resource pool for the terminal to communicate with an AIoT device; a time domain bitmap, used to identify a time unit available for AIoT communication within a periodicity of the resource pool, and / or used to identify a time unit unavailable for AIoT communication within the periodicity of the resource pool; first physical channel information, used to identify a resource location available for a Device-to-Reader (D2R) communication within a periodicity of the resource pool; second physical channel information, used to identify a resource location available for a Reader-to-Device (R2D) communication within a periodicity of the resource pool; first time information, used to identify a time domain location at which the resource pool parameter takes effect; second time information, used to identify a time domain location at which the resource pool parameter ceases to be effective.

21. The method of claim 19, wherein, The Uu radio bearer parameter comprises at least one of: a radio bearer identifier; a radio link control (RLC) bearer identifier; an RLC channel identifier; a logical channel group (LCG) identifier (ID); a logical channel identifier (LCID); a logical channel priority value.

22. The method of claim 21, wherein, In a case where a quantity of the Uu radio bearer parameters configured by the first message is more than one set, the Uu radio bearer parameter is associated with at least one of an identifier of the AIoT device and a latency budget value of the Uu air interface.

23. The method of claim 19, wherein, The power control parameter comprises at least one of a maximum transmission power and a minimum transmission power.

24. The method of any one of claims 18-23, wherein, Before the first network device sends the first message to the terminal, the method further comprises: The first network device receives a third message from the terminal, the third message comprising at least one of: a quantity of AIoT devices to be reached or discovered; a size of AIoT device data to be relayed; a range of communication of the terminal with the AIoT device; a latency budget value of the AIoT service; a transmission parameter of the AIoT air interface of the AIoT service; a transmission parameter of the Uu air interface of the AIoT service; a frequency of communication of the terminal with the AIoT device; a transmission bandwidth of communication of the terminal with the AIoT device; a device type supported by the AIoT device; a communication type supported by the AIoT device.

25. The method of claim 24, wherein, The transmission parameter of the AIoT air interface comprises a latency budget value of the AIoT air interface. The transmission parameter of the Uu air interface comprises a latency budget value of the Uu air interface. The latency budget value of the AIoT air interface and the latency budget value of the Uu air interface are obtained by splitting the latency budget value of the AIoT service.

26. The method of any one of claims 18-23, wherein, Before the first network device sends the first message to the terminal, the method further comprises: The first network device sends a fourth message to the terminal, the fourth message being used to request the AIoT service, and the fourth message comprising at least one of: a type of the AIoT service; an identifier of an AIoT device of the AIoT service; a quantity of AIoT devices of the AIoT service; a second quality of service (QoS) parameter of the AIoT service.

27. The method of claim 26, wherein, The second QoS parameter comprises at least one of: a second latency budget value of the AIoT service; a proportion of a quantity of AIoT devices to be reached or discovered in a quantity of AIoT devices of the AIoT service; a data size of the AIoT service; a communication range of the AIoT service.

28. The method of claim 26 or 27, wherein, Before the first network device sends the fourth message to the terminal, the method further comprises: The first network device receives a seventh message from a second network device, the seventh message being used to request the AIoT service, and the seventh message comprising at least one of: a type of the AIoT service; an identifier of an AIoT device of the AIoT service; a quantity of AIoT devices of the AIoT service; a first QoS parameter of the AIoT service.

29. The method of claim 28, wherein, The first QoS parameter comprises at least one of: a first latency budget value of the AIoT service; a proportion of a number of AIoT devices to be reached or to be discovered in a number of AIoT devices of the AIoT service; a data size of the AIoT service; a communication range of the AIoT service.

30. The method of claim 27 or 29, wherein, the AIoT device communication related parameters further comprise at least one of: a latency budget value of an AIoT air interface; a latency budget value of a Uu air interface; wherein the latency budget value of the AIoT air interface and the latency budget value of the Uu air interface are obtained based on the first latency budget value or the second latency budget value.

31. The method of any one of claims 18-30, further comprising: receiving, by the first network device, a fifth message from the terminal, the fifth message being used to request releasing the configured AIoT device communication related parameters.

32. The method of any one of claims 18-31, further comprising: sending, by the first network device, a sixth message to the terminal, the sixth message being used to indicate releasing the configured AIoT device communication related parameters.

33. An apparatus for communicating with AIoT devices, the apparatus comprising: a first receiving module configured to receive a first message from a first network device, the first message being used to configure AIoT device communication related parameters; a processing module configured to perform a communication procedure with an AIoT device based on the first message.

34. The apparatus of claim 33, wherein, the AIoT device communication related parameters comprise at least one of: a resource pool parameter for the terminal to communicate with an AIoT device; a power control parameter for the terminal to communicate with an AIoT device; at least one set of Uu radio bearer parameters for the terminal to transmit AIoT device data; a latency budget value of an AIoT air interface; a latency budget value of a Uu air interface.

35. The apparatus of claim 33 or 34, further comprising: a second receiving module configured to receive a second message from a second network device, the second message being used to request an AIoT service, the second message comprising at least one of: a type of the AIoT service; an identity of an AIoT device of the AIoT service; a number of AIoT devices of the AIoT service; a first quality of service (QoS) parameter of the AIoT service; a first sending module configured to send, based on the second message, a third message to the first network device, the third message comprising at least one of: a transmission parameter of an AIoT air interface of the AIoT service; a transmission parameter of a Uu air interface of the AIoT service; wherein the transmission parameter of the AIoT air interface of the AIoT service and the transmission parameter of the Uu air interface of the AIoT service are obtained based on the first QoS parameter; or, the apparatus further comprising: a third receiving module configured to receive a fourth message from the first network device, the fourth message being used to request an AIoT service, the fourth message comprising at least one of: a type of the AIoT service; an identity of an AIoT device of the AIoT service; a number of AIoT devices of the AIoT service; a second QoS parameter of the AIoT service.

36. The apparatus of claim 34 or 35, wherein, The processing module is specifically configured to perform at least one of the following: determining a latency for communication with the AIoT device based on the latency budget of the AIoT air interface; maintaining a target counter, a maximum count value of the target counter being determined based on a number of the AIoT devices to be reached or discovered; maintaining a target timer, a maximum running duration of the target timer being determined based on the latency budget of the AIoT air interface.

37. The apparatus of claim 35, further comprising: a second sending module configured to send target data, the target data including at least one of the following: data of the AIoT devices that have been reached or discovered; and information indicating success or failure of a communication process with the AIoT device.

38. The apparatus of claim 37, further comprising: a third sending module configured to send a fifth message to the first network device, the fifth message being used to request release of the configured AIoT device communication related parameters.

39. The apparatus of claim 37 or 38, further comprising: a fourth receiving module configured to receive a sixth message from the first network device, the sixth message being used to indicate release of the configured AIoT device communication related parameters.

40. A message sending apparatus, the apparatus comprising: a first sending module configured to send a first message to a terminal, the first message being used to configure AIoT device communication related parameters.

41. The device of claim 40, wherein, The AIoT device communication related parameters include at least one of the following: a resource pool parameter for communication between the terminal and the AIoT device; a power control parameter for communication between the terminal and the AIoT device; at least one set of Uu radio bearer parameters for the terminal to transmit AIoT device data.

42. The apparatus of claim 40 or 41, further comprising: a first receiving module configured to receive a third message from the terminal, the third message including at least one of the following: a number of AIoT devices to be reached or discovered; a size of AIoT device data to be relayed; a range for communication between the terminal and the AIoT device; a latency budget value of AIoT service; a transmission parameter of an AIoT air interface of the AIoT service; a transmission parameter of a Uu air interface of the AIoT service; a frequency for communication between the terminal and the AIoT device; a transmission bandwidth for communication between the terminal and the AIoT device; a device type supported by the AIoT device; and a communication type supported by the AIoT device.

43. The apparatus of any one of claims 40 to 42, further comprising: a second sending module configured to send a fourth message to the terminal, the fourth message being used to request AIoT service, the fourth message including at least one of the following: a type of the AIoT service; an identity of an AIoT device of the AIoT service; a number of AIoT devices of the AIoT service; and a second quality of service (QoS) parameter of the AIoT service.

44. The apparatus of claim 43, further comprising: a second receiving module, configured to receive a seventh message from a second network device, the seventh message being used to request an AIoT service, the seventh message comprising at least one of the following: a type of the AIoT service; an identity of an AIoT device of the AIoT service; a number of AIoT devices of the AIoT service; a first QoS parameter of the AIoT service.

45. The apparatus of any one of claims 40-44, further comprising: a third receiving module, configured to receive a fifth message from the terminal, the fifth message being used to request releasing the configured AIoT device communication related parameters.

46. The apparatus of any one of claims 40-45, further comprising: a third sending module, configured to send a sixth message to the terminal, the sixth message being used to indicate releasing the configured AIoT device communication related parameters.

47. A communication device, comprising a processor and a memory, the memory storing programs or instructions executable on the processor, the programs or instructions being executed by the processor to implement steps of the method for AIoT device communication according to any one of claims 1-17, or to implement steps of the method for message sending according to any one of claims 18-32.

48. A readable storage medium, the readable storage medium storing programs or instructions executable on a processor, the programs or instructions being executed by the processor to implement steps of the method for AIoT device communication according to any one of claims 1-17, or to implement steps of the method for message sending according to any one of claims 18-32.

49. A computer program product, comprising computer instructions executable by a processor to implement steps of the method for AIoT device communication according to any one of claims 1-17, or to implement steps of the method for message sending according to any one of claims 18-32.

Images