Wireless communication method and communication device

Abstract

The invention provides a wireless communication method and a communication device, and provides a clear scheme for how to select a command sending process. The method is applied to a first device, and comprises: receiving a first message sent by a first network element, the first message comprising inventory related information or command related information; and sending a second message to a second device, the second message being used for an inventory process or a command process, the process directed by the second message being related to the information included in the first message and / or the first device and / or the context corresponding to the second device maintained by the first network element.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a wireless communication method and communication device. Background Technology

[0002] Use cases for Internet of Things (IoT) communication systems include inventory and command processing. When application functions need to inventory devices, this can be achieved through an inventory process; when application functions need to send commands to devices, this can be achieved through a command process.

[0003] To reduce signaling overhead, a scheme has been introduced where inventory management and command execution occur in the same process (referred to as the first process). If an application needs to send commands to the device, it can do so through either the command process or the first process. Currently, there is no clear solution for choosing the appropriate process to send commands. Summary of the Invention

[0004] This application provides a wireless communication method and communication device, offering a clear scheme for how to select the process of sending commands.

[0005] In a first aspect, a wireless communication method is provided, the method being applied to a first device, comprising: receiving a first message sent by a first network element, the first message including inventory-related information or command-related information; sending a second message to a second device, the second message being used for an inventory process or a command process, the process targeted by the second message being related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element.

[0006] By determining the process initiated to the second device based on the information included in the first message and / or the context corresponding to the second device, the first device can explicitly select the method of the process.

[0007] In some implementations, if the first message includes inventory-related information, then the second message is used in the inventory process.

[0008] If the first message includes inventory-related information, the first device can directly initiate the inventory process to the second device without needing to perform additional checks, which can reduce the processing overhead of the first device.

[0009] In some implementations, the first message may also include first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to a command.

[0010] By sending a first instruction message to the first device, the first device can determine that the current process is an inventory + command process, thus distinguishing it from the traditional inventory process. Furthermore, if the first message includes the first instruction message, the first device can continue to receive or listen to the third message after sending the second message to the second device, which is beneficial for the implementation of the inventory + command process.

[0011] In some implementations, if the first message includes information related to the command, then the second message is used for inventory or command processes.

[0012] In some implementations, if the first message includes command-related information and second indication information, the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent R2D transmission, and the service type is inventory and command; or if the first message includes command-related information and third indication information, the second message is used for the command process, wherein the third indication information indicates one or more of the following: the command process is executed directly, there is no subsequent R2D transmission, and the service type is inventory.

[0013] If the first message includes command-related information, the first network element can also carry an indication message in the first message to indicate which process the first device needs to initiate to the second device, thus enabling the first device to clearly define the process to initiate to the second device. Furthermore, by carrying command-related information in the first message, even if the first device needs to initiate an inventory process to the second device first, after the inventory is completed, the first device can directly initiate the command process to the second device without needing to request command-related information from the first network element again, thereby saving signaling steps.

[0014] In some implementations, the indication information included in the first message is related to a first time, which is determined based on the time when the first network element and the second device complete communication.

[0015] In some implementations, the time when the first network element and the second device complete communication is any one of the following times: the time when the first network element receives the device identifier of the second device; the time when the first network element sends the first security configuration information; the time when the first network element receives the reply message for the first security configuration information; wherein, the first security configuration information is security configuration information for the second device.

[0016] In some implementations, if the first message includes command-related information and the first device stores a valid context of the second device, then the second message is used for the command flow; or if the first message includes command-related information and the first device does not store a valid context of the second device, then the second message is used for the inventory flow.

[0017] In some implementations, whether the first device stores a valid context of the second device is related to a second time, which is determined based on the time when the first device and the second device complete communication.

[0018] In some implementations, the time when the first device and the second device complete communication is: the time when the first device receives the device identifier of the second device.

[0019] In some implementations, if the first device stores a valid context of the second device, the second message includes the AS ID assigned by the first device to the second device; or if the first device does not store a valid context of the second device, the second message includes the device identifier of the second device.

[0020] By identifying the second device using AS ID or device identifier, the second device can determine whether the second message is specific to it based on the identifier information in the second message after receiving it. This can prevent the second device from making invalid responses and help reduce the overhead of the second device.

[0021] In some implementations, if the second message includes inventory-related information, then the second message also includes security configuration information for the second device.

[0022] By carrying security configuration information in the second message, the second device can use the security configuration information to perform security-related processing on the message in subsequent processes, thereby ensuring the security of communication.

[0023] In a second aspect, a wireless communication method is provided, the method being applied to a first network element, comprising: sending a first message to a first device, the first message being used to trigger the first device to send a second message to a second device; wherein the first message includes inventory-related information or command-related information, the second message being used for inventory procedures or command procedures, and the procedure targeted by the second message being related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element.

[0024] In some implementations, if the first message includes inventory-related information, then the second message is used in the inventory process.

[0025] In some implementations, the first message may also include first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to a command.

[0026] In some implementations, if the first message includes information related to the command, then the second message is used for inventory or command processes.

[0027] In some implementations, if the first message includes command-related information and second indication information, the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent R2D transmission, and the service type is inventory and command; or if the first message includes command-related information and third indication information, the second message is used for the command process, wherein the third indication information indicates one or more of the following: the command process is executed directly, there is no subsequent R2D transmission, and the service type is inventory.

[0028] In some implementations, the indication information included in the first message is related to a first time, which is determined based on the time when the first network element and the second device complete communication.

[0029] In some implementations, the time when the first network element and the second device complete communication is any one of the following times: the time when the first network element receives the device identifier of the second device; the time when the first network element sends the first security configuration information; the time when the first network element receives the reply message for the first security configuration information; wherein, the first security configuration information is security configuration information for the second device.

[0030] In some implementations, if the first message includes command-related information and the first device stores a valid context of the second device, then the second message is used for the command flow; or if the first message includes command-related information and the first device does not store a valid context of the second device, then the second message is used for the inventory flow.

[0031] In some implementations, whether the first device stores a valid context of the second device is related to a second time, which is determined based on the time when the first device and the second device complete communication.

[0032] In some implementations, the time when the first device and the second device complete communication is: the time when the first device receives the device identifier of the second device.

[0033] In some implementations, if the first device stores a valid context of the second device, the second message includes the AS ID assigned by the first device to the second device; or if the first device does not store a valid context of the second device, the second message includes the device identifier of the second device.

[0034] In some implementations, if the second message includes inventory-related information, then the second message also includes security configuration information for the second device.

[0035] Fourthly, a communication device is provided, comprising a unit (or module) composed of software and / or hardware, the unit being used to perform any one of the methods described in the first aspect.

[0036] Fifthly, a communication device is provided, comprising a unit (or module) composed of software and / or hardware, the unit being used to perform any one of the methods described in the second aspect.

[0037] In a sixth aspect, a communication device is provided, comprising a unit (or module) composed of software and / or hardware, the unit being used to perform any one of the methods described in the third aspect.

[0038] In a seventh aspect, a chip is provided, including a processor; the processor is configured to read and execute a computer program stored in a memory to perform any of the methods described in the first aspect.

[0039] Optionally, the chip further includes a memory, which is connected to the processor via a circuit or wire.

[0040] Alternatively, the chip may further include a communication interface.

[0041] Eighthly, a chip is provided, including a processor; the processor is configured to read and execute a computer program stored in a memory to perform any of the methods described in the second aspect.

[0042] Optionally, the chip further includes a memory, which is connected to the processor via a circuit or wire.

[0043] Alternatively, the chip may further include a communication interface.

[0044] In a ninth aspect, a chip is provided, including a processor; the processor is configured to read and execute a computer program stored in a memory to perform any of the methods described in the third aspect.

[0045] Optionally, the chip further includes a memory, which is connected to the processor via a circuit or wire.

[0046] Alternatively, the chip may further include a communication interface.

[0047] In a tenth aspect, a first device is provided, the first device comprising: a processor, a memory, and an interface; the processor, the memory, and the interface cooperate with each other to enable the first device to execute any one of the technical solutions described in the first aspect; or to include any one of the chips described in the seventh aspect.

[0048] In the eleventh aspect, a first network element is provided, the first network element comprising: a processor, a memory, and an interface; the processor, memory, and interface cooperate with each other to enable the first network element to execute any one of the technical solutions described in the second aspect; or to include any one of the chips described in the eighth aspect.

[0049] In a twelfth aspect, a second device is provided, the second device comprising: a processor, a memory, and an interface; the processor, memory, and interface cooperate with each other to enable the second device to perform any one of the methods described in the third aspect; or to include any one of the chips described in the ninth aspect.

[0050] In a thirteenth aspect, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, the processor performs any one of the methods of the technical solutions described in any one of the first to third aspects.

[0051] In a fourteenth aspect, a computer program product is provided, the computer program product comprising: computer program code, which, when executed on a communication device, causes the communication device to perform any one of the technical solutions described in any one of the first to third aspects. Attached Figure Description

[0052] Figure 1 This is the architecture of a communication system applicable to the embodiments of this application;

[0053] Figure 2 The structure of an IoT communication system is shown;

[0054] Figure 3 This illustrates a network structure for an IoT communication system;

[0055] Figure 4 An architecture of an AIoT communication system is shown;

[0056] Figure 5 This is a schematic diagram of an inventory process provided in an embodiment of this application;

[0057] Figure 6 This is a schematic diagram of another inventory process provided in an embodiment of this application;

[0058] Figure 7 This is a schematic diagram of another inventory process provided in the embodiments of this application;

[0059] Figure 8 This is a schematic diagram of the interaction process between a reader and a device provided in an embodiment of this application;

[0060] Figure 9 This is a flowchart illustrating a wireless communication method provided in an embodiment of this application.

[0061] Figure 10 This is a flowchart illustrating a method for sending command-related information, as provided in an embodiment of this application.

[0062] Figure 11 This is a schematic diagram of another process for sending command-related information provided in an embodiment of this application;

[0063] Figure 12 This is a schematic diagram of another method for sending command-related information provided in an embodiment of this application;

[0064] Figure 13 This is a schematic diagram of another method for sending command-related information provided in an embodiment of this application;

[0065] Figure 14 This is a schematic block diagram of a communication device provided in an embodiment of this application;

[0066] Figure 15 This is a schematic block diagram of another communication device provided in the embodiments of this application;

[0067] Figure 16 This is a schematic block diagram of another communication device provided in the embodiments of this application;

[0068] Figure 17 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0069] Figure 1 This is a schematic diagram of the architecture of the communication system 10 used in an embodiment of this application. Figure 1As shown, the communication system includes a radio access network (RAN) 100, wherein the RAN 100 includes at least one RAN node (e.g., Figure 1 110a and 110b, collectively referred to as 110, may also include at least one terminal device (such as...). Figure 1 RAN100, denoted as RAN100, comprises RAN nodes 120a-120j, collectively referred to as RAN120. RAN100 may also include other RAN nodes, such as wireless relay equipment and / or wireless backhaul equipment. Figure 1 (Not shown in the image). Terminal device 120 is wirelessly connected to RAN node 110. Terminal devices and RAN nodes can be interconnected via wired or wireless means. Communication system 10 may also include core network 200. RAN node 110 is connected to core network 200 via wireless or wired means. The core network equipment in core network 200 and RAN node 110 in RAN 100 can be independent physical devices, or they can be the same physical device integrating the logical functions of core network equipment and RAN node. Communication system 10 may also include Internet 300.

[0070] RAN 100 can be an evolved universal terrestrial radio access (E-UTRA) system, a new radio (NR) system, or a future radio access system as defined in the 3rd generation partnership project (3GPP). RAN 100 can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system. RAN 100 can also include two or more of the above-mentioned different radio access systems.

[0071] RAN nodes, also known as radio access network equipment, RAN entities, or access nodes, are used to help terminal devices access communication systems wirelessly. In one application scenario, an RAN node can be a base station, an evolved NodeB (eNodeB), a transmission reception point (TRP), a next-generation NodeB (gNB) in 5G mobile communication systems, a next-generation base station in 6G mobile communication systems, or a base station in future mobile communication systems. RAN nodes can also be macro base stations (such as...) Figure 1 110a in the text), can also be a micro base station or an indoor station (such as... Figure 1 110b in the middle can also be a relay node or a donor node.

[0072] In another application scenario, multiple RAN nodes can collaborate to help terminal devices achieve wireless access, with different RAN nodes implementing different functions of the base station. For example, a RAN node can be a central unit (CU), a distributed unit (DU), or a radio unit (RU). Here, the CU performs the functions of the base station's Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP), and can also perform the functions of the Service Data Adaptation Protocol (SDAP). The DU performs the functions of the base station's Radio Link Control (RANC) and Medium Access Control (MAC) layers, and can also perform some or all of the physical layer functions. For specific descriptions of these protocol layers, refer to the relevant 3GPP technical specifications. The RU can be used to implement radio frequency signal transmission and reception. The CU and DU can be two independent RAN nodes, or they can be integrated into the same RAN node, such as within a baseband unit (BBU). RUs can be included in radio frequency equipment, such as remote radio units (RRUs) or active antenna units (AAUs). CUs can be further divided into two types of RAN nodes: CU-control plane and CU-user plane.

[0073] In different systems, RAN nodes may have different names. For example, in an O-RAN system, a CU can be called an open CU (O-CU), a DU can be called an open DU (O-DU), and an RU can be called an open RU (O-RU). The RAN nodes in the embodiments of this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules. For example, a RAN node can be a server loaded with the corresponding software modules. The embodiments of this application do not limit the specific technology or device form used in the RAN nodes. For ease of description, a base station is used as an example of a RAN node in the following description.

[0074] A terminal device is a device with wireless transceiver capabilities, capable of sending signals to or receiving signals from a base station. Terminal devices can also be referred to as terminals, user equipment (UE), mobile stations, mobile terminals, etc. They can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), the Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, and smart cities. Terminal devices can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, airplanes, ships, robots, robotic arms, smart home devices, etc. The embodiments of this application do not limit the specific technologies or device forms used in the terminal devices.

[0075] Base stations and terminal equipment can be fixed or mobile. They can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can be deployed on aircraft, balloons, and satellites. The embodiments of this application do not limit the application scenarios of the base stations and terminal equipment.

[0076] The roles of base stations and terminal devices can be relative, for example, Figure 1The helicopter or drone 120i can be configured as a mobile base station. For terminal devices 120j accessing the wireless access network 100 via 120i, 120i is a base station; however, for base station 110a, 120i is a terminal device, meaning that 110a and 120i communicate via a wireless air interface protocol. Of course, 110a and 120i can also communicate via a base station-to-base station interface protocol; in this case, 120i is also a base station relative to 110a. Therefore, both base stations and terminal devices can be collectively referred to as communication devices. Figure 1 The 110a and 110b in the text can be referred to as communication devices with base station functions. Figure 1 The 120a-120j in the text can be referred to as communication devices with terminal functions.

[0077] Communication between base stations and terminal devices, between base stations, and between terminal devices can be conducted using licensed spectrum, unlicensed spectrum, or both simultaneously. Communication can be conducted using spectrum below 6 gigahertz (GHz), spectrum above 6 GHz, or both simultaneously. The embodiments of this application do not limit the spectrum resources used for wireless communication.

[0078] In the embodiments of this application, the functions of the base station can be executed by modules (such as chips) within the base station, or by a control subsystem that includes base station functions. This control subsystem, including base station functions, can be a control center in the aforementioned application scenarios such as smart grids, industrial control, intelligent transportation, and smart cities. Similarly, the functions of the terminal device can be executed by modules (such as chips or modems) within the terminal device, or by a device that includes terminal device functions.

[0079] IoT technology

[0080] The rise of IoT technology has presented new challenges to communication systems. Use cases for IoT terminal devices can include logistics, warehousing, factory automation, and animal husbandry. IoT terminal devices and network devices can engage in intermittent, simple communication or coarse location tracking. Even the simplest IoT terminal devices, such as NB-IoT devices used for electricity metering, require batteries for power. However, despite their low energy consumption, the batteries inside IoT terminal devices can only last for a few years before eventually running out of power. Therefore, the batteries of IoT terminal devices need to be replaced regularly, which consumes a significant amount of manpower. Furthermore, some industrial scenarios are inherently dangerous and unsuitable for manual operation. Therefore, battery-free IoT terminal devices have emerged.

[0081] Battery-free IoT devices are numerous and inexpensive, generally requiring no further manual maintenance after installation. Radio Frequency Identification (RFID) devices can, to some extent, meet the demand for battery-free IoT devices. However, the operation of RFID systems still requires human intervention. For example, some RFID systems require manual handheld readers. Moreover, the wireless coverage of a single RFID reader is limited (within 10 meters), so large-scale RFID systems require more human intervention. For instance, using an RFID system to inventory goods in a large supermarket requires significant manpower, resources, and time.

[0082] IoT communication system

[0083] Transplanting systems like RFID into cellular networks can effectively solve the problem of limited coverage. This is because cellular networks (such as 4G and 5G systems) have already achieved nationwide coverage or at least coverage of major cities in some countries or regions (such as China and Europe and the United States). Based on this wider network coverage, communication or positioning between IoT terminal devices and network devices can be achieved without human intervention. Therefore, IoT terminal devices can operate continuously and efficiently. Furthermore, IoT terminal devices can even operate efficiently in environments unsuitable for human intervention (such as open fields, mines, and factories). Therefore, when applying IoT terminal devices, aside from the initial association between the IoT terminal device and a specific object, subsequent data reading, writing, and maintenance can be performed via an app such as a smartphone, which is very convenient and efficient. Such a communication system can be called an IoT communication system (or AIoT communication system) or a zero-power communication system.

[0084] like Figure 2As shown, the IoT communication system may include a network device 210 and a terminal device 220. The terminal device 220 may also be a zero-power terminal device. The network device 210 can be referred to as a reader, and the terminal device 220 can be referred to as a tag or device. The IoT communication system employs energy harvesting and backscatter communication technologies. The network device 210 can send wireless power signals and downlink communication signals to the terminal device 220, and receive backscatter signals from the terminal device 220. A basic terminal device 220 may include an energy harvesting module 221, a backscatter communication module 222, and a low-power computing module 223. Furthermore, the terminal device 220 may also include a memory module (not shown) for storing basic information (such as item identification). Alternatively, the terminal device 220 may also include a sensor module 224 for acquiring sensor data such as ambient temperature and humidity.

[0085] Use cases for IoT communication systems can be broadly categorized into four types: inventory, sensors, tracking, and commands. Inventory refers to checking for missing or damaged goods when they enter or leave a warehouse. Common sensors include those for temperature, pressure, and humidity. Sensors can be used in industry, agriculture, and smart cities. The information collected by sensors can be uploaded to a third-party application (App) for monitoring and management via the IoT system. Tracking generally refers to periodically obtaining the approximate location of objects; for example, users can use their smartphones to track the real-time location of their packages. Commands refer to operating a servo mechanism through the IoT system. These servo mechanisms can be connected to IoT terminal devices. For example, people can water their backyard plants using a mobile app while working or resting in the office; the watering servo mechanism can be connected to an IoT terminal device.

[0086] The network structure of an IoT communication system can be as follows: Figure 3 As shown, it includes four network topologies. Figure 3 As shown in Figure (a), AIoT devices can communicate directly with base stations for uplink and downlink communication. Figure 3 In Figure (b) shown, AIoT devices can communicate with the base station via uplink and downlink through intermediate nodes. AIoT devices can communicate bidirectionally with intermediate nodes, and intermediate nodes can communicate with the base station via Uu communication. Figure 3 In Figure (c) shown, AIoT devices can communicate uplink with the base station, and the base station can communicate downlink with IoT devices through auxiliary nodes. Figure 3 As shown in Figure (d), AIoT devices can communicate uplink and downlink with other terminal devices.

[0087] Figure 4 This illustrates the interaction flow between the AIoT CN, AIoT RAN, and AIoT devices. The AIoT RAN has general reader / writer functionality as well as AIoT RAN node functionality. Alternatively, the AIoT RAN can include... Figure 3 The intermediate node and base station in diagram (b).

[0088] AIoT CN can receive service requests sent by application functions (AFs). Based on the service request, AIoT CN initiates the corresponding process to AIoT RAN, and AIoT RAN can send wireless signals or signaling to AIoT devices.

[0089] The embodiments of this application mainly involve command service requests. Correspondingly, the AIoT CN can initiate a command process to the AIoT RAN, that is, the AIoT CN can send command messages to the AIoT RAN, and further, the AIoT RAN sends command messages to the AIoT devices.

[0090] Regarding the inventory process, there are currently three inventory processes depending on the reader, such as... Figures 5-7 As shown.

[0091] Figure 5 The inventory process shown is the communication process between the AIoT core network, AIoT RAN nodes, and AIoT devices, with the reader being the AIoT RAN node.

[0092] In step S510, the AIoT core network sends an inventory request to the AIoT RAN node.

[0093] In step S520, the AIoT RAN node sends an inventory response to the AIoT core network.

[0094] In step S530, the AIoT RAN node and AIoT device execute an inventory process. The AIoT RAN node and AIoT device can interact via the AIoT interface to execute the inventory process. For details on the inventory process, please refer to [link to relevant documentation]. Figure 8 The description.

[0095] In step S540, the AIoT RAN node sends an inventory report to the AIoT core network.

[0096] In step S550, if the inventory results change subsequently, the AIoT RAN node can send an updated inventory report to the AIoT core network.

[0097] Figure 6 and Figure 7 The inventory process shown is the communication process between the AIoT core network, AIoT-enabled UE, AIoT-enabled base station, and AIoT devices.

[0098] See Figure 6 In step S610, the AIoT core network sends an inventory request to the AIoT enabled base station.

[0099] In step S620, the AIoT-enabled base station sends an inventory response to the AIoT core network.

[0100] In step S630, the AIoT-enabled base station and the AIoT device execute an inventory process. The AIoT-enabled base station and the AIoT device can interact via the AIoT interface and the Uu interface to execute the inventory process. For details of the inventory process, please refer to [link to relevant documentation]. Figure 8 The description.

[0101] In step S640, the AIoT-enabled base station sends an inventory report to the AIoT core network.

[0102] In step S650, if the subsequent inventory results change, the AIoT-enabled base station can send an updated inventory report to the AIoT core network.

[0103] See Figure 7 In step S710, the AIoT core network sends an inventory request to the AIoT-enabled UE.

[0104] In step S720, the AIoT-enabled UE sends an inventory response to the AIoT core network.

[0105] In step S730, the AIoT-enabled UE and AIoT device execute an inventory process. The AIoT-enabled UE and AIoT device can interact via the AIoT interface to execute the inventory process. For details on the inventory process, please refer to [link to relevant documentation]. Figure 8 The description.

[0106] In step S740, the AIoT-enabled UE sends an inventory report to the AIoT core network.

[0107] In step S750, if the inventory results change subsequently, the AIoT-enabled UE can send an updated inventory report to the AIoT core network.

[0108] IoT terminal devices are powered by the surrounding environment, including radio waves (RF), solar energy, thermal energy, mechanical vibration, and wind power. IoT terminal devices can be categorized into three types: Type A, Type B, and Type C. Type A and Type B devices can only communicate by reflecting and modulating received radio waves, a communication method known as backscattering. This means that Type A and Type B devices cannot actively transmit radio signals, and their power ranges from 1 to 10 microwatts (μW). Type A devices have the lowest transmission power and the lowest hardware complexity, essentially approaching the level of RFID devices. Type B devices have slightly more complex hardware, including signal amplification devices and some energy storage devices, resulting in a longer communication distance between Type B devices and network devices compared to Type A devices. Type C devices have the ability to actively transmit radio waves, with a transmission power of approximately 1 to 10 milliwatts (mW), and can store a certain amount of energy. All three types of terminal devices can obtain energy from the environment and can operate continuously for several years or even more than 10 years. Furthermore, to conserve energy, Type A and Type B terminal devices are essentially in a dormant state until a network device triggers a communication process with them. They only begin operating after being activated by the network device's wireless signal.

[0109] Figure 8 The interaction flow between the reader and the device is illustrated. This flow can be divided into three stages: the AIoT paging stage, the D2R data transmission stage, and the data transmission stage.

[0110] The AIoT paging phase includes step S810, where the reader sends an AIoT paging message to the device to page the device. The paging message can be understood as an (initial) trigger message.

[0111] The D2R data transmission phase includes steps S820 and S830. In step S820, the device initiates a random connection with the reader. The device can initiate a random connection with the reader after receiving an AIoT paging message sent by the reader.

[0112] The random access procedure in this application can be a four-step random access procedure or a two-step random access procedure; the embodiments of this application do not specifically limit it in this way.

[0113] In some implementations, if there is already a context between the reader and the device, step S820 can be skipped, i.e., the random access procedure is not performed.

[0114] In step S830, after random access is completed, the device sends D2R data to the reader. In some implementations, the D2R data may include the device's identifier, and the device can send its own device identifier (device ID) to the reader. By sending the device's identifier to the reader, the reader can perform inventory checks on the device.

[0115] The data transmission phase includes steps S840 and S850. In step S840, the reader sends reader-to-device (R2D) data to the device.

[0116] In step S850, the device sends device-to-reader (D2R) data to the reader.

[0117] In some implementations, if the reader needs to initiate a command flow, it can be done through steps S840 and S850.

[0118] For the two use cases of inventory and command mentioned above, there are currently three types: inventory only, command only, and inventory plus command.

[0119] Inventory use cases can be implemented through an inventory process. For example, if a reader initiates an inventory process to a device, the reader can page the device, and the device can send its device identifier to the reader. The process ends after the inventory is complete. Figure 8 For example, for a single inventory process, the process may include steps S810 and S830. After step S830 is completed, the inventory process ends.

[0120] Command use cases can be implemented through disk-to-command flows and command flows. For example, in a disk-to-command flow, the reader can initiate a page to the device, receive the device identifier after a random access procedure, and then send a command message to the device. The flow ends after the operation corresponding to the command is completed. Figure 8 For example, in a disk-to-command process, this process may include steps S810 to S850. The reader can send a command message to the device in step S840, and the device can respond to the command message in step S840. After step S840, the command process ends. For a command-only process, this process may only include steps S810 and S850. The reader sends a command message to the device via a paging message, and the device sends a response to the reader in step S850.

[0121] For the inventory and command use case, a scheme is introduced where inventory and command are implemented in the same process, i.e., the inventory and command processes are carried out through the same procedure. It should be noted that inventory and command being in the same process does not mean that the reader / writer receives both inventory and command messages simultaneously, nor does it mean that the paging message includes both inventory search and command messages.

[0122] If the disk entry and command are in the same process, the process may include steps S810 to S850. In step S830, the device may send a device identifier to the reader to complete the disk entry for the device. In step S840, the reader may send a command message to the device, and in step S850, the device may respond to the command message.

[0123] As mentioned above, after the AF sends a command service request to the core network, the core network can send command messages to the reader. Furthermore, the reader can send command messages to the device. However, with the introduction of disk storage and commands in the same process, the reader can send command messages through either a command-only process or a disk storage plus command process (i.e., the reader needs to trigger a disk storage process first). Currently, there is no clear solution regarding which process to use for sending command messages.

[0124] The above describes the problem to be solved by the embodiments of this application, using a reader and a device as examples. However, the embodiments of this application are not limited to this; for any two devices that need to be implemented according to... Figure 8 Devices that communicate in the manner shown (such as the first device and the second device) will have similar problems.

[0125] Based on this, embodiments of this application provide a wireless communication method and a communication device. A first device can determine the process to be initiated to a second device based on the content carried by a first message sent by a first network element, thereby providing a clear scheme for the first device to determine the initiated process.

[0126] The following is combined Figure 9 The wireless communication method provided in the embodiments of this application will be described in detail.

[0127] Figure 9 The method illustrated is a description from the perspective of device interaction. The specific forms and quantities of the devices shown are merely examples and should not be construed as limiting the implementation of the method provided in this application. The communication method of this application embodiment will be described in detail below, using the first and second devices as examples.

[0128] The first device in this embodiment can refer to a device capable of communicating with the second device. The first device can be a wireless device. For example, the first device can be an AIoT wireless node, or it can include an AIoT-enabled base station and / or an AIoT-enabled terminal device. An AIoT wireless node can be, for example, a RAN node, and a RAN node can be, for example, a base station. An AIoT-enabled base station can communicate with an AIoT-enabled terminal device via a Uu interface.

[0129] In some implementations, the first device may be, for example, a reader, a base station, or a terminal device.

[0130] The second device in this application embodiment can be an Internet of Things (IoT) device, such as an AIoT device, device, or tag mentioned above.

[0131] The device in the embodiments of this application can be the device itself, or a chip, chip system or processor that supports the device to implement the communication method, or a logic module or software that can implement all or part of the device.

[0132] See Figure 9 In step S910, the first device sends a second message to the second device. This second message is used for an inventory process or a command process.

[0133] The second message used in the inventory process can refer to the second message including inventory-related information, the second message being used in the inventory process, the second message being used to collect the device identifier of the second device, the second message being used to instruct the second device to reply with the device identifier, the second message being an inventory message, the second message including an inventory instruction, the second message including an inventory request, or the second message being used to indicate that a response from the second device is required.

[0134] The inventory process in this embodiment refers to the inventory process in the inventory plus command process described above. For the inventory plus command process, the first device needs to execute the inventory process, and then the command process needs to be executed by the second device. The inventory plus command process includes steps S810 to S850 described above. The inventory process includes steps S810 and S830.

[0135] The second message used in the command process can refer to the following: the second message includes relevant information about the command; the second message is used in the command process; the second message is a command message; the second message includes command instructions; the second message includes command requests; the second message is used to instruct the second device to execute a command; or the second message is used to instruct the second device to respond to a command.

[0136] The command flow in this application embodiment may refer to the command-only flow mentioned above. The command flow may include steps S840 and S850 mentioned above, or may include steps S810 and S850.

[0137] In some implementations, the second message can be a paging message (such as an AIoT paging message) or an R2D message.

[0138] In some implementations, the process targeted by the second message is related to the context corresponding to the second device maintained by the first device and / or the first network element. In other words, the process targeted by the second message can be determined based on the context corresponding to the second device maintained by the first device and / or the first network element. The process targeted by the second message can be an inventory process or a command process.

[0139] The first network element can be a core network element. For example, the first network element can include one or more of the following: AIoT function (AIoT-F) network element, AF, user plane function (UPF), and authentication management function (AMF).

[0140] The context corresponding to the second device may include one or more of the following: access stratum (AS) context and core network (CN) context. The AS context may include one or more of the following: the AS identifier (ID) corresponding to the second device, a list of second devices associated with the first device, and a first period. This first period is similar to the period in DRX mode. The second device can wake up to transmit messages during the active period of the first period, and not transmit messages during the sleep period of the first period.

[0141] The CN context may include one or more of the following: authentication information, authorization information, security information, device identifier, and the correspondence between a first device and a second device. Security information may include, for example, a key that can be used to encrypt messages during communication to ensure communication security. This key may be a non-permanent key, or it may not be a fixed key.

[0142] For example, the context corresponding to the second device maintained by the first device can refer to the AS context. Similarly, the context corresponding to the second device maintained by the first network element can refer to the CN context.

[0143] The second device maintained by the first device may include one or more of the following: a second device that has recently communicated with the device, or a second device to which an AS ID has been assigned.

[0144] The context corresponding to the second device maintained by the first device may include: the first device storing a valid context of the second device, or the first device not storing a valid context of the second device.

[0145] The first device storing a valid context of the second device can mean either that the first device stores the context of the second device, or that the first device stores the context of the second device and that the stored context of the second device is valid. If the first device stores a valid context of the second device, then the second device is considered reachable.

[0146] The absence of a valid context for the second device in the first device can mean that the first device does not store the context for the second device, or that the first device stores the context for the second device, but the stored context for the second device is invalid. If the first device does not store a valid context for the second device, then the second device is considered unreachable.

[0147] The second device maintained by the first network element may include one or more of the following: a second device that has recently communicated with it, or a second device to which security configuration information has been assigned. The security configuration information may, for example, include a key.

[0148] The context corresponding to the second device maintained by the first network element may include: the first network element storing a valid context of the second device, or the first network element not storing a valid context of the second device.

[0149] The first network element storing a valid context of the second device can mean that the first network element stores the context of the second device, or that the first network element stores the context of the second device and the stored context of the second device is valid.

[0150] The absence of a valid context for the second device in the first network element can mean that the first network element does not store the context for the second device, or that the first network element stores the context for the second device, but the stored context for the second device is invalid.

[0151] In some implementations, the process targeted by the second message is related to the state of the second device maintained by the first device and / or the first network element. The state of the second device can also be referred to as the reachability state of the second device. The state of the second device can include a first state and a second state, where the first state indicates that the second device is reachable, and the second state indicates that the second device is unreachable. In some implementations, the state of the second device can also be referred to as the reachability state of the second device.

[0152] If the state of the second device maintained by the first device is in the first state, it means that the first device can directly send commands to the second device; if the state of the second device maintained by the first device is in the second state, it means that the first device cannot directly send commands to the second device.

[0153] If the state of the second device maintained by the first network element is the first state, it means that the first network element can directly send commands to the second device; if the state of the second device maintained by the first network element is the second state, it means that the first network element cannot directly send commands to the second device.

[0154] In some implementations, the state of the second device maintained by the first device is related to the context corresponding to the second device maintained by the first device. If the first device stores a valid context of the second device, the state of the second device maintained by the first device is a first state; if the first device does not store a valid context of the second device, the state of the second device maintained by the first device is a second state.

[0155] In some implementations, the state of the second device maintained by the first network element is related to the context corresponding to the second device maintained by the first network element. If the first network element stores a valid context of the second device, the state of the second device maintained by the first network element is the first state; if the first network element does not store a valid context of the second device, the state of the second device maintained by the first network element is the second state.

[0156] In some implementations, whether the first device stores a valid context of the second device is related to a second time. If the second time has passed, it means that the first device does not store a valid context of the second device; if the second time has not passed, it means that the first device stores a valid context of the second device.

[0157] The second time can be determined based on the time when the first device and the second device complete communication. Assuming the time when the first device and the second device complete communication is time 1, then the second time can be the time after time 1 has elapsed for a certain period of time.

[0158] For example, the second time can be the time after a preset duration has elapsed since time 1. Alternatively, the second time can be an absolute time, which is located after time 1. Or, the second time can be the expiration time of the first timer, whose start time can be time 1.

[0159] In some implementations, after the first device completes communication with the second device, it can start a first timer. Before the first timer expires, the first device maintains the valid context of the second device. After the first timer expires, the first device deletes the context of the second device or sets the context of the second device to invalid.

[0160] In some implementations, the duration of the first timer is related to the type of the second device. Different second devices may correspond to different durations of the first timer. For example, for devices with faster movement speeds, the duration of the first timer is shorter, while for devices with slower movement speeds, the duration of the first timer is longer.

[0161] In some implementations, the second device can also maintain its own context, which may include an ASID. For example, the first device can assign an AS ID to the second device, and the second device can maintain that AS ID.

[0162] The second device may maintain the AS ID within a third period. If the third period is exceeded and the second device no longer maintains the AS ID, the second device may delete the AS ID or invalidate the AS ID.

[0163] The third time can be determined based on the time when the second device and the first device complete communication. Assuming the time when the second device and the first device complete communication is time 2, then the third time can be the time after time 2 has elapsed for a certain period of time.

[0164] For example, the third time can be the time after a preset duration has elapsed since time 2. Alternatively, the third time can be an absolute time, located after time 2. Or, the third time can be the expiration time of the second timer, whose start time can be time 2.

[0165] In some implementations, after the first device completes communication with the second device, it can start a first timer. Before the first timer expires, the first device maintains the valid context of the second device. After the first timer expires, the first device deletes the context of the second device or sets the context of the second device to invalid.

[0166] In some implementations, after the second device completes communication with the first device, it can start a second timer. Before the second timer expires, the second device maintains the AS ID assigned to it. After the second timer expires, the second device deletes the AS ID or sets the AS ID to invalid.

[0167] In some implementations, the second and third times can be the same or different. Taking the second and third times as a time interval as an example, the duration of the second time can be equal to the duration of the third time, or the duration of the second time can be greater than the duration of the third time, or the duration of the second time can be less than the duration of the third time. Taking the second and third times as absolute times as an example, the second time can be the same as the third time, or the second time can be later than the third time, or the second time can be earlier than the third time.

[0168] In some implementations, the duration of the second timer can be the same as or different from the duration of the first timer; this application does not specifically limit this. For example, the duration of the first timer can be greater than the duration of the second timer to avoid wasting resources when the second device has already released the AS ID by the time the first device sends a message to the second device. Furthermore, considering the signaling transmission time involved in the first device sending the AS ID to the second device, the duration of the first timer can be greater than the duration of the second timer to ensure that the time the first device spends maintaining the context of the second device is consistent with the time the second device spends maintaining the AS ID.

[0169] Of course, in some implementations, the second device may not maintain the AS ID assigned to it by the first device.

[0170] In some implementations, the time when the first device completes communication with the second device can be: the time when the first device receives the device identifier of the second device. In some implementations, the time when the first device completes communication with the second device can be: the time when the first device sends a paging message to the second device. In some implementations, the time when the first device completes communication with the second device can be: the time when the first device sends an inventory request to the second device. In some implementations, the time when the first device completes communication with the second device can be: the time when the first device sends a command to the second device. In some implementations, the time when the first device completes communication with the second device can be: the time when the first device receives a response message from the second device. In some implementations, the time when the first device completes communication with the second device can be: the time when the first device sends its AS ID to the second device.

[0171] In some implementations, the time it takes for the second device to complete communication with the first device is the same as the time it takes for the first device to complete communication with the second device. For example, the time it takes for the second device to complete communication with the first device could be the time when the second device sends its device identifier. Another example is the time it takes for the second device to complete communication with the first device to receive a message sent by the first device. Yet another example is the time it takes for the second device to complete communication with the first device to send a message to the first device.

[0172] It should be noted that the above is merely an example illustrating the time when the first device and the second device complete communication. Of course, the time when the first device and the second device complete communication can be the sending time of any message between them. For example, the time when the first device and the second device complete communication can be the sending time of the last message between them. Similarly, the time when the first device and the second device complete communication can also be the sending time of the first message between them.

[0173] In some implementations, the indication information included in the first message is related to a first time. If the first time has elapsed, the first message includes second indication information; if the first time has not elapsed, the first message includes third indication information. In some implementations, if the first time has elapsed, it indicates that the first network element does not store a valid context of the second device or the second device is unreachable; if the first time has not elapsed, it indicates that the first network element stores a valid context of the second device or the second device is reachable.

[0174] The first time can be determined based on the time when the first network element and the second device complete communication. Assuming the time when the first network element and the second device complete communication is time 3, then the first time can be the time after time 3 has elapsed for a certain period of time.

[0175] For example, the first time can be the time after a preset duration following time 3. Alternatively, the first time can be an absolute time, located after time 3. Or, the first time can be the expiration time of the third timer, whose start time can be time 3.

[0176] In some implementations, after the first network element completes communication with the second device, it can start a third timer. Before the third timer expires, the first network element maintains the valid context of the second device. After the third timer expires, the first network element deletes the context of the second device or sets the context of the second device to invalid.

[0177] In some implementations, the duration of the third timer is related to the type of the second device. Different second devices may correspond to different durations of the third timer. For example, for devices with faster movement speeds, the duration of the third timer is shorter, while for devices with slower movement speeds, the duration of the third timer is longer.

[0178] In some implementations, the second device can also maintain its own context, which may include first security configuration information, which is security configuration information specific to the second device. The first security configuration information can be configured by the first network element.

[0179] The second device may maintain the first security configuration information within a fourth time period. If the second device does not maintain the first security configuration information after the fourth time period, the second device may delete the first security configuration information or invalidate the first security configuration information.

[0180] The fourth time can be determined based on the time when the second device and the first network element complete communication. Assuming the time when the second device and the first network element complete communication is time 4, then the fourth time can be the time after time 4 has elapsed for a certain period of time.

[0181] For example, the fourth time can be the time after a preset duration following time 4. Alternatively, the fourth time can be an absolute time, located after time 4. Or, the fourth time can be the expiration time of the fourth timer, whose start time can be time 4.

[0182] In some implementations, after the first network element completes communication with the second device, it can start a third timer. Before the third timer expires, the first network element maintains the valid context of the second device. After the third timer expires, the first network element deletes the context of the second device or sets the context of the second device to invalid.

[0183] In some implementations, after the second device completes communication with the first network element, it can start a fourth timer. Before the fourth timer expires, the second device maintains the first security configuration information assigned to it. After the fourth timer expires, the second device deletes the first security configuration information or sets the first security configuration information to invalid.

[0184] In some implementations, the first time and the fourth time can be the same or different. Taking the first time and the fourth time as a time interval as an example, the duration of the first time can be equal to the duration of the fourth time, or the duration of the first time can be greater than the duration of the fourth time, or the duration of the first time can be less than the duration of the fourth time. Taking the first time and the fourth time as absolute times as an example, the first time can be the same as the fourth time, or the first time can be later than the fourth time, or the first time can be earlier than the fourth time.

[0185] The duration of the fourth timer can be the same as or different from the duration of the third timer; this application embodiment does not specifically limit this. For example, the duration of the third timer can be greater than the duration of the fourth timer to avoid wasting resources when the second device has already released the security configuration information by the time the first network element sends a message to the second device. Furthermore, considering the signaling transmission time involved in sending security configuration information from the first network element to the second device, the duration of the third timer can be greater than the duration of the fourth timer to ensure that the time taken by the first network element to maintain the context of the second device is consistent with the time taken by the second device to maintain the security configuration information.

[0186] Of course, in some implementations, the second device may not maintain the first security configuration information assigned to it by the first network element.

[0187] In some implementations, the time when the first network element completes communication with the second device can be: the time when the first network element receives the device identifier of the second device. In some implementations, the time when the first network element completes communication with the second device can be: the time when the first network element sends the first security configuration information. In some implementations, the time when the first network element completes communication with the second device can be: the time when the first network element receives the reply message for the first security configuration information. In some implementations, the time when the first network element completes communication with the second device can be: the time when the first network element sends a command for the second device. In some implementations, the time when the first network element completes communication with the second device can be: the time when the first network element sends an inventory request for the second device. In some implementations, the time when the first network element completes communication with the second device can be: the time when the first network element receives the response message from the second device.

[0188] In some implementations, the time it takes for the second device to complete communication with the first network element is the same as the time it takes for the first network element to complete communication with the second device. For example, the time it takes for the second device to complete communication with the first network element could be the time when the second device sends its device identifier. Another example is the time it takes for the second device to complete communication with the first network element to receive the first security configuration information. Yet another example is the time it takes for the second device to reply to the first security configuration information.

[0189] The first security configuration information refers to the security configuration information for the second device. This first security configuration information may include the key configured for the second device.

[0190] It should be noted that the above is merely an example illustrating the time it takes for the first network element and the second device to complete communication. Of course, the time it takes for the first network element and the second device to complete communication can be the sending time of any message between them. For example, the time it takes for the first network element and the second device to complete communication can be the sending time of the last message between them. Similarly, the time it takes for the first network element and the second device to complete communication can also be the sending time of the first message between them.

[0191] In some implementations, the first device can determine whether to store the valid context of the second device based on whether the second device is within the coverage area of ​​the first device. If the second device is not within the coverage area of ​​the first device, the first device does not store the valid context of the second device, such as deleting the context of the second device or setting the context of the second device to invalid; if the second device is within the coverage area of ​​the first device, the first device maintains the valid context of the second device.

[0192] Whether the second device is within the coverage area of ​​the first device can be related to the movement speed of the second device. The first device can determine whether the second device is within its coverage area based on the first timer mentioned above. If the first timer expires, the second device is not within the coverage area of ​​the first device; if the first timer has not expired, the second device is within the coverage area of ​​the first device. The start time of the first timer can be found in the previous description.

[0193] In some implementations, the first network element can determine whether to store the valid context of the second device based on whether the second device is within the coverage area of ​​the first device. If the second device is not within the coverage area of ​​the first device, the first network element does not store the valid context of the second device, such as deleting the context of the second device or setting the context of the second device to invalid; if the second device is within the coverage area of ​​the first device, the first network element maintains the valid context of the second device.

[0194] Whether the second device is within the coverage area of ​​the first device can be related to the movement speed of the second device. The first network element can determine whether the second device is within the coverage area of ​​the first device based on the third timer mentioned above. If the first timer expires, the second device is not within the coverage area of ​​the first device; if the first timer has not expired, the second device is within the coverage area of ​​the first device. The start time of the third timer can be found in the previous description.

[0195] The following describes the process for determining the target of the second message.

[0196] In some implementations, the process targeted by the second message may be related to the information included in the first message. The first message is sent from the first network element to the first device. For example, Figure 9 The method shown also includes step S905, in which the first network element sends a first message to the first device, the first message of which may include relevant information stored or relevant information of commands.

[0197] In some implementations, in response to the first message, the first device sends a second message to the second device. In other words, the second message is a message corresponding to the first message.

[0198] The inclusion of inventory-related information in the first message can mean that the first message includes an inventory request, the first message is used in the inventory process, or the first message includes an inventory instruction.

[0199] The first message including command-related information can mean that the first message includes a command request, or the first message is used in a command flow, or the first message includes a command.

[0200] In some implementations, if the first message includes inventory-related information, then the second message is used in the inventory process. For example, if the first network element sends an inventory request to the first device, then the first device sends an inventory request to the second device.

[0201] In some implementations, if the first message includes inventory-related information, it may also include first instruction information to distinguish it from a simple inventory process. This first instruction information instructs the first device to receive or listen to the third message. The third message includes command-related information. The first instruction information may be an instruction followed by a command. After receiving the first message, the first device can receive or listen to the third message.

[0202] In some implementations, if the first message includes inventory-related information, then to distinguish it from a process that only involves inventory, the first message may also include command-related information, such as including both inventory and command in the first message.

[0203] In some implementations, if the first network element does not store a valid context for the second device, the first message includes inventory-related information. If the first network element does not store a valid context for the second device, it cannot directly send commands to the second device; instead, it must first instruct the first device to perform an inventory check on the second device before sending commands to it.

[0204] The following is combined Figure 10 The interaction process between the first network element, the first device, and the second device is described.

[0205] See Figure 10 In step S1010, the first network element sends a first message to the first device, which includes relevant information stored in the inventory.

[0206] In step S1020, after receiving the first message, the first device can send a second message to the second device. The second message includes relevant inventory information. The second message can be AIoT paging.

[0207] The second message may be scrambled using the device identifier of the second device, or the second message may include the device identifier of the second device.

[0208] In step S1030, in response to the second message, the second device sends its device identifier to the first device.

[0209] In step S1040, the first device sends the device identifier of the second device to the first network element.

[0210] In step S1050, after the first network element receives the identification information of the second device, it can send a third message to the first device. The third message includes relevant information about the command.

[0211] In step S1060, in response to the third message, the first device sends relevant information about the command to the second device.

[0212] In some implementations, if the first message includes information related to the command, the second message can be used in the inventory process or the command process.

[0213] As an example, if the first message includes command-related information and also includes second instruction information, the second instruction information indicates one or more of the following: the inventory process is executed first, there is a subsequent R2D transfer, and the service type is inventory and command. The service type being inventory and command can refer to a use case being inventory plus command, or a business type being inventory plus command.

[0214] For example, the second indication information is used to indicate that the first network element does not store a valid context of the second device, or the second indication information is used to indicate that the second device is unreachable.

[0215] In some implementations, if the first network element does not store a valid context for the second device, the first network element can send command-related information and second instruction information to the first device. In other implementations, the first network element can determine, based on its implementation, the command-related information and second instruction information to be sent to the first device.

[0216] If the first network element does not store a valid context for the second device or the second device is unreachable, the first network element can directly send command-related information to the first device. In this way, after the first device completes its inventory of the second device, it can directly send commands to the second device based on the command-related information, thereby saving signaling processes and reducing overhead. Furthermore, to ensure the first device can trigger the correct process, the first network element can carry second indication information in the first message, allowing the first device to determine that the triggered process is an inventory plus command process.

[0217] The following is combined Figure 11 The interaction process between the first network element, the first device, and the second device is described.

[0218] See Figure 11 In step S1110, the first network element sends relevant information about the command and second instruction information to the first device. The second instruction information is used to indicate that an inventory process needs to be performed first.

[0219] In step S1120, after receiving the second instruction information, the first device determines that an inventory process needs to be performed first. The first device then sends a second message to the second device, which includes inventory-related information. The second message can be an AIoT paging message.

[0220] The second message may be scrambled using the device identifier of the second device, or the second message may include the device identifier of the second device.

[0221] In step S1130, in response to the second message, the second device may send the device identifier of the second device to the first device.

[0222] In step S1140, after the first device receives the device identifier of the second device, it can send relevant information about the command to the second device.

[0223] As another example, if the first message includes command-related information and also includes third instruction information, the third instruction information indicates one or more of the following: direct execution of the command flow, no subsequent R2D transmission, or service type is inventory. Service type inventory can refer to a use case of inventory or a business type of inventory.

[0224] For example, the third indication information can be used to indicate that the first network element stores a valid context of the second device, or the third indication information can be used to indicate that the second device is reachable.

[0225] In some implementations, if the first network element stores a valid context of the second device or the second device is reachable, the first network element can send command-related information and third indication information to the first device. In other implementations, the first network element can determine, based on its implementation, the command-related information and third indication information to be sent to the first device.

[0226] If the first network element stores a valid context of the second device, it can directly send command-related information to the first device. This command-related information can be used to trigger a command-only process. To distinguish it from the inventory-plus-command process, the first network element can send a third instruction to the first device so that the first device can trigger the correct process.

[0227] The following is combined Figure 12 The interaction process between the first network element, the first device, and the second device is described.

[0228] See Figure 12 In step S1210, the first network element sends a first message to the first device. The first message includes relevant information about the command and third instruction information, which is used to instruct the direct execution of the command process.

[0229] In step S1220, after receiving the third indication information, the first device can send a second message to the second device, which includes relevant information about the command. The second message can be AIoT paging.

[0230] The second message may be scrambled with an AS ID, or may carry an AS ID to identify the second device. This AS ID is specific to the second device.

[0231] If the second message carries an AS ID or the second message is scrambled with an AS ID, the second device responds to the second message; if the second message does not carry the AS ID, or the second device cannot correctly decode the second message using the AS ID, the second device may not respond to the second message.

[0232] As another example, if the first message includes information related to the command and the first device stores a valid context of the second device, then the second message is used in the command flow.

[0233] As another example, if the first message includes information related to the command and the first device does not store a valid context for the second device, then the second message is used in the inventory process.

[0234] After receiving the command-related information sent by the first network element, the first device can also combine the context of the second device maintained by the first device to determine the process to be initiated to the second device, so as to ensure that the correct process can be initiated to the second device.

[0235] The following is combined Figure 13 The interaction process between the first network element, the first device, and the second device is described.

[0236] See Figure 13 In step S1310, the first network element sends a first message to the first device, which includes relevant information about the command.

[0237] In step S1320, after receiving the first message, the first device can determine the information included in the second message based on whether the first device stores a valid context of the second device.

[0238] For example, if the first device does not store a valid context for the second device, then steps S1330 to S1350 are executed; if the first device stores a valid context for the second device, then step S1360 is executed.

[0239] In step S1330, the first device sends a second message to the second device, which includes inventory-related information. The second message can be AIoT paging. The second message may include the device identifier of the second device, or the second message may be scrambled using the device identifier of the second device.

[0240] The second message may be scrambled using the device identifier of the second device, or the second message may include the device identifier of the second device.

[0241] In step S1340, after receiving the relevant information stored in the inventory, the second device can send the device identifier of the second device to the first device.

[0242] In step S1350, after the first device receives the device identifier of the second device, it can send relevant information about the command to the second device.

[0243] In step S1360, the first device sends a second message to the second device, which includes information related to the command. The second message can be AIoT paging.

[0244] The second message may be scrambled using the AS ID of the second device, or the second message may include the AS ID of the second device.

[0245] In some implementations, if the first device stores a valid context of the second device, the second message may include an AS ID assigned by the first device to the second device, or the second message may be scrambled using the AS ID assigned by the first device to the second device.

[0246] In some implementations, if the first device does not store a valid context for the second device, the second message may include the device identifier of the second device, or the second message may be scrambled using the device identifier of the second device.

[0247] In some implementations, the information related to the command sent by the first network element to the first device can be determined by the first network element based on the context of the second device it maintains. As mentioned earlier, if the first network element stores a valid context of the second device, then the information related to the command sent by the first network element to the first device is determined.

[0248] In some implementations, after receiving a service request for a command, the first network element can determine the information included in the first message to be sent to the first device based on whether the first network element stores a valid context of the second device. After receiving the first message, the first device can determine the process targeted by the second message based on the information included in the first message and whether the first device stores a valid context of the second device.

[0249] In some implementations, the first network element may send command-related information to the first device directly after receiving a service request related to the command. That is, after receiving a service request for a command, the first network element directly sends the command-related information to the first device without needing to determine whether it stores a valid context for the second device. In this case, the first network element does not need to maintain a valid context for the second device. After receiving the command-related information sent by the first network element, the first device can determine the process to which the second message pertains based on whether it stores a valid context for the second device.

[0250] In some implementations, if the second message is used in the inventory process, it may also include security configuration information for the second device. This security configuration information can be used to securely process subsequent command-related information. For example, the security configuration information may include a key used to encrypt command-related information.

[0251] In some implementations, the security configuration information for the second device can be sent from the first network element to the first device. For example, the first network element can carry the security configuration information for the second device in the first message.

[0252] In some implementations, if the second device receives a paging message scrambled with an AS ID, or a paging message carrying an AS ID, and the second device stores the AS ID, then the second device will reply to the paging message; if the second device receives a paging message scrambled with an AS ID, or a paging message carrying an AS ID, and the second device does not store the AS ID, then the second device may not reply to the paging message.

[0253] In some implementations, the type of the second message is related to the context in which the second device exists within the first device; that is, the type of the second message can be determined based on the context in which the second device exists within the first device. The context of the second device included in the first device can refer to an AS-based context.

[0254] In some implementations, the first device can maintain the context of the second device after receiving the device identifier of the second device, and may stop maintaining the context of the second device after a certain period of time.

[0255] In some implementations, the type of the second message is related to the context of whether a second device exists in the first network element; that is, the type of the second message can be determined based on the context of whether a second device exists in the first network element. The context of the second device included in the first network element can refer to a key-based context.

[0256] The type of the second message can refer to either the second message containing inventory-related information or the second message containing command-related information.

[0257] The first network element can maintain the correspondence between the first device, the second device, and the timer, as shown in Table 1.

[0258] Table 1

[0259]

[0260] Taking the second device 1 as an example, assuming that the duration of timer 1 is 10 minutes, if the first network element and the second device 1 complete communication at 10 o'clock (such as the first network element receiving the device identifier of the second device 1 or the first network element allocating a key to the second device 1), timer 1 is started for 10 minutes. After timer 1 expires at 10:10, the first network element deletes the context of the second device 1 or sets the context of the second device 1 to invalid.

[0261] Taking the second device 2 as an example, assuming that the duration of timer 2 is 10 minutes, if the first network element and the second device 2 complete communication at 10:05 (such as the first network element receiving the device identifier of the second device 2 or the first network element allocating a key to the second device 2), timer 1 with a duration of 10 minutes is started. At 10:10, timer 2 still has 5 minutes remaining, and the first network element continues to maintain the context of the second device 2.

[0262] By maintaining the correspondence between the second device and the first device, the first network element can clearly specify which first device to send the message to when it needs to send a message to a certain second device. For example, if the first network element needs to send a message to the second device 1, according to the correspondence shown in Table 1, the first network element can first send a message to the first device 2, and then the first device 2 will send the message to the second device 1.

[0263] In some implementations, the first device shown in Table 1 can refer to the last device that communicated with the second device. Taking the second device 1 as an example, the second device 1 may have communicated with multiple first devices, and the last first device that communicated with the second device 1 is the first device 2. Of course, as the second device 1 moves, it may also communicate with the next first device. If the last first device that communicated with the second device 1 changes, the correspondence shown in Table 1 also needs to be updated accordingly.

[0264] In some implementations, the first network element can maintain the correspondence between the second device and the timer, as well as the correspondence between the region and the first device. The correspondence between the device and the timer can be shown in Table 2, and the correspondence between the region and the first device can be shown in Table 3.

[0265] Table 2

[0266]

[0267] Table 3

[0268]

[0269] Based on the correspondence shown in Table 2, the first network element can determine which first device contexts need to be maintained, and which first device contexts need to be deleted (or whose first device context information is set to invalid). Based on the correspondence shown in Table 3, the first network element can determine which first devices to send messages to. For example, if the AF requests to send a command to a device in area 1, the first network element can send messages to first device 1, first device 3, and first device 5.

[0270] In some implementations, the first device can maintain the correspondence between the second device and the timer, as shown in Table 4.

[0271] Table 4

[0272]

[0273] Based on the correspondence shown in Table 4, the first device can determine which contexts of the first device need to be maintained, and which contexts of the first devices need to be deleted (or which context information of the first devices needs to be set to invalid).

[0274] Taking the second device 1 as an example, assuming that the duration of timer 1 is 10 minutes, if the first device and the second device 1 complete communication at 10 o'clock (such as the first device receiving the device identifier of the second device 1), timer 1 is started for 10 minutes. After timer 1 expires at 10:10, the first device deletes the context of the second device 1 or sets the context of the second device 1 to invalid.

[0275] Taking the second device 2 as an example, assuming that the duration of timer 2 is 10 minutes, if the first device and the second device 2 complete communication at 10:05 (e.g., the first device receives the device identifier sent by the second device 2), the 10-minute timer 1 is started. At 10:10, timer 2 still has 5 minutes remaining, and the first device continues to maintain the context of the second device 2.

[0276] In some implementations, the first network element sending the first message to the first device can be triggered by receiving a service request, which can be a service request for a command. Taking AIoT-F as an example, AIoT-F can receive a service request sent by AF, and in response to the service request, AIoT-F sends the first message to the first device.

[0277] In some implementations, the service request may include identification information of the second device and / or a target area. The identification information of the second device and / or the target area can be used by the first network element to determine which first device to send the first message to.

[0278] For example, the service request may include identification information of the second device, such as a device identifier and / or AS ID. Based on the identification information of the second device and the correspondence between the first and second devices shown in Table 1, the first network element can determine which first device to send the first message to. For instance, if the first network element determines the second device to be second device 1 based on its identification information, and determines that second device 1 corresponds to first device 2 according to the correspondence shown in Table 2, then the first network element can send the first message to first device 2.

[0279] For example, a service request may include a target area. This target area is the area where the target second device is located; that is, the target area indicates which area the command needs to be sent to the second device. The first network element can determine which first device to send the first message to based on the correspondence shown in Table 3. For example, if the target area includes area 1, then according to the correspondence shown in Table 3, the first network element can determine to send the first message to first devices 1, 3, and 5.

[0280] In some implementations, the service request may include information related to the command (such as a command request) to indicate that the service request is a service request for a command.

[0281] In some implementations, the service request may include identification information for one or more second devices. This identification information could be, for example, a device ID. For instance, the service request could include a list of second devices. Upon receiving the service request, the first device can determine whether to send a second message based on the list of second devices. If the list of second devices includes a device context it maintains, then the first device needs to send a second message.

[0282] In some implementations, the service request may include information about the first device, such as a list of the first devices. Based on the list of the first devices, the first device can determine whether it needs to send a second message to the second device; only the first devices in the list need to send a second message to the second device.

[0283] In some implementations, the first network element may carry a list of target second devices in the first message, so that the first device can determine whether it needs to send a second message.

[0284] The second message can be triggered by an AF command service request.

[0285] The following three examples provide a detailed description of the solutions in the embodiments of this application. It should be noted that the following three examples are merely illustrative of the embodiments of this application for ease of understanding and should not be construed as limiting the embodiments of this application.

[0286] It should be noted that, in the absence of conflict, the content described below can be used in conjunction with the content described above.

[0287] The following three examples illustrate the concept of the first network element as the core network, the first device as the reader, and the second device as the device.

[0288] Example 1

[0289] Example 1 illustrates the embodiments of this application using the context of core network maintenance equipment as an example.

[0290] The context of a core network maintenance device may specifically include one or more of the following information: the reachability status of the device, the reader associated with the device (such as the reader of the last communication), and the correspondence between the reader and the area. The context of a core network maintenance device may include the correspondence shown in Table 1, or the correspondence shown in Tables 2 and 3.

[0291] A device's reachability state can be of two types: key-based reachability state and mobility-based reachability state.

[0292] For key-based reachable states, after the core network assigns a key to the device, it can start a timer. During the timer's execution, the key can be used to encrypt the command. After receiving the key, the device can also maintain a timer, and can use the key to decrypt the command before the timer expires.

[0293] For mobility-based reachability states, the core network can maintain reachability states for a certain period of time after communicating with the device. For example, the core network can start running a timer after receiving the device ID. Before the timer expires, it is assumed that the device is still in the same reader or at least in the original area, and the core network can directly send a command to the device.

[0294] The device may or may not maintain the key sent by the reader.

[0295] The duration of timers maintained by the core network and those maintained by the device can be the same or different. For example, considering the signaling transmission time involved in commands sent from the core network to the device, the duration of the timer maintained by the core network can be longer than that of the timer maintained by the device. Conversely, to avoid wasting resources when the device releases its key before the core network sends a message, the duration of the timer maintained by the core network can be shorter than that of the timer maintained by the device.

[0296] The core network receives service requests for a target device sent by the AF. The service request may include one or more of the following information: command, relevant index of the target device, and target area.

[0297] The core network determines the reachability of the target device. The core network can send messages to the reader in two ways, A and B.

[0298] During maintenance time T, if the core network considers the target device to be reachable, the core network can send a command and reachability indication to the reader corresponding to the target device or the reader corresponding to the target area, or send a command.

[0299] Outside of maintenance time T, if the core network considers the target device unreachable, it can send a command, unreachable indication, and related key to the reader corresponding to the target device or the reader corresponding to the target area, or send an inventory and an indication that there will be subsequent commands.

[0300] The reader corresponding to the target device can refer to the last reader that communicated with the target device.

[0301] The reader can perform the following operations based on instructions from the core network:

[0302] If the reader receives an inventory and subsequent command instructions, it can first trigger a paging process containing the inventory and a key (optional). After receiving the device ID from the target device, the reader can report the device ID to the core network and wait for the core network to send the corresponding command.

[0303] When a reader receives a command, it can initiate different processes based on the reachability indication.

[0304] If the core network sends a reachability indication for the target device, the reader sends a command in AIoT paging;

[0305] If the core network sends an unreachable indication for the target device, the reader sends inventory in AIoT paging and sends command to the target device after inventory is completed.

[0306] If the target device receives an AIoT paging message scrambled with the AS ID, or a message carrying the AS ID, within the validity period, the target device will respond to the message or send a reply message to the reader. If the target device receives an AIoT paging message scrambled with the AS ID, or a message carrying the AS ID, outside the validity period, the target device will not respond to the message or send a reply message to the reader.

[0307] The validity period can be determined based on a timer maintained by the target device. During the validity period, the target device stores the AS ID corresponding to this device. If the timer expires, the target device deletes the AS ID corresponding to this device.

[0308] Example 2

[0309] The core network maintains the context of devices, including whether the device is registered and the correspondence between readers and regions.

[0310] The core network receives service requests sent by the AF. The service request may include one or more of the following information: command, relevant index of the target device, and target area.

[0311] The core network sends a command to the reader. This reader can be the reader corresponding to the target device or the reader corresponding to the target area.

[0312] The reader maintains a list of device contexts. A device's context includes the AS ID assigned to the device by the reader. After communicating with a device, the reader can maintain its reachability state for a certain period T. The devices maintained by the reader can include those for which the reader has assigned an AS ID. For example, the reader can maintain the mapping shown in Table 4.

[0313] The reachability state maintained by the reader is a mobility-based reachability state. After communicating with the device, the reader can maintain the reachability state of that device for a certain period of time T. For example, after receiving the device ID, the reader can start running a reachability timer. Before the reachability timer expires, the reader considers the device to still be under its control and can directly send commands to the device.

[0314] Optionally, after the reader assigns an AS ID to the device, the device can maintain the AS ID for a certain period of time (e.g., retain the AS ID), or the device can choose not to maintain the AS ID.

[0315] During the maintenance period T, the reader can assume the device is reachable. Upon receiving a command for that device, the reader can directly send the command to that device. This command can be carried in a paging message. The paging message can be scrambled with an AS ID, or it can include the AS ID, which can be used to identify the target device.

[0316] Outside of maintenance time T, the reader may consider the device unreachable. Upon receiving a command for that device, the reader can first trigger a disk read / write process. For example, the reader can send a paging message to the device, which includes disk read / write information. This paging message carries the device ID. After receiving the device ID from the device, the reader sends the corresponding command to the device.

[0317] Optionally, a message carrying a command can be scrambled with the AS ID corresponding to the device ID, or the message carrying a command can include the AS ID corresponding to the device ID.

[0318] If the target device receives an AIoT paging message scrambled with the AS ID, or a message carrying the AS ID, within the validity period, the target device will respond to the message or send a reply message to the reader. If the target device receives an AIoT paging message scrambled with the AS ID, or a message carrying the AS ID, outside the validity period, the target device will not respond to the message or send a reply message to the reader.

[0319] The validity period can be determined based on a timer maintained by the target device. During the validity period, the target device stores the AS ID corresponding to this device. If the timer expires, the target device deletes the AS ID corresponding to this device.

[0320] Example 3

[0321] Example 3 illustrates the embodiments of this application by taking the example of both the core network and the reader maintaining the device's context.

[0322] The core network provides the RAN side with a list of readers and a list of devices to be paged. After receiving the list information, the readers in the list can select the device with the context part to send the command.

[0323] The core network maintains the context of a device, which may include one or more of the following information: the reachability status of the device, the reader associated with the device (such as the reader of the last communication), and the correspondence between the reader and the area. For example, the core network may maintain the correspondence shown in Table 1, or the correspondence shown in Tables 2 and 3.

[0324] The reachability state of a device maintained by the core network can be key-based. After the core network assigns a key to a device, it can start a timer. During the timer's execution, the key can be used directly to encrypt the command. After receiving the key, the device can also maintain a timer, and can use the key to decrypt the command before the timer expires.

[0325] The core network receives a command service request initiated by the AF for at least one target device. The service request carries the command and the relevant index of the target device (such as the device ID).

[0326] The core network determines the reachability of the target device and the list of readers associated with the target area or the target device.

[0327] During maintenance time T, if the core network considers the device reachable, it can send a command and a list of target devices to the reader corresponding to the device or to a reader in the reader list.

[0328] Outside of maintenance time T, if the core network considers a device unreachable, it can send an inventory message with subsequent commands, a command message with an unreachable indication, or an inventory message with a command to the reader corresponding to that device or a reader in the reader list. Additionally, the core network can also send a list of target devices to the reader.

[0329] The reader maintains the device context, including the devices the reader has recently communicated with, and the reachability state of the devices.

[0330] The reachability state of a device maintained by the reader can be mobility-based. After communicating with a device, the reader can maintain the reachability state of that device for a certain period of time T. For example, after receiving the device ID, the reader can start running a reachability timer. Before the reachability timer expires, the reader considers the device to still be under its control and can directly send commands to the device.

[0331] Optionally, after the reader assigns an AS ID to the device, the device can maintain the AS ID for a certain period of time (e.g., retain the AS ID), or the device can choose not to maintain the AS ID.

[0332] If the reader receives a command from the core network and stores a valid context for the device, the reader can send an AIoT paging message to the device, which carries the command. Optionally, the AIoT paging message can be scrambled with the AS ID or carry the AS ID corresponding to the device ID.

[0333] If the reader receives a command from the core network and does not store a valid context for the device, the reader can send an AIoT paging message to the device. This AIoT paging message carries the inventory and the device ID. The reader may choose not to send a command to the device, or in other words, the AIoT paging message may not include a command.

[0334] If the target device receives an AIoT paging message scrambled with the AS ID, or a message carrying the AS ID, within the validity period, the target device will respond to the message or send a reply message to the reader. If the target device receives an AIoT paging message scrambled with the AS ID, or a message carrying the AS ID, outside the validity period, the target device will not respond to the message or send a reply message to the reader.

[0335] The validity period can be determined based on a timer maintained by the target device. During the validity period, the target device stores the AS ID corresponding to this device. If the timer expires, the target device deletes the AS ID corresponding to this device.

[0336] The above text combined Figures 1 to 13 The method embodiments of this application are described in detail below, in conjunction with... Figures 14-17 This section describes the apparatus embodiments of this application. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the foregoing method embodiments.

[0337] Figure 14 This is a schematic block diagram of a communication device provided in an embodiment of this application. The communication device 1400 can be any of the first devices described above. For example... Figure 14 As shown, the communication device 1400 includes a receiving module 1410 and a transmitting module 1420.

[0338] In one possible implementation, the device 1400 can be used to perform the steps described above by the first device.

[0339] The receiving module 1410 is used to receive a first message sent by the first network element, wherein the first message includes inventory-related information or command-related information.

[0340] The sending module 1420 is used to send a second message to the second device. The second message is used for inventory process or command process. The process targeted by the second message is related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element.

[0341] In some implementations, if the first message includes inventory-related information, then the second message is used in the inventory process.

[0342] In some implementations, the first message may also include first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to a command.

[0343] In some implementations, if the first message includes information related to the command, then the second message is used for inventory or command processes.

[0344] In some implementations, if the first message includes command-related information and second indication information, the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent R2D transmission, and the service type is inventory and command; or if the first message includes command-related information and third indication information, the second message is used for the command process, wherein the third indication information indicates one or more of the following: the command process is executed directly, there is no subsequent R2D transmission, and the service type is inventory.

[0345] In some implementations, the indication information included in the first message is related to a first time, which is determined based on the time when the first network element and the second device complete communication.

[0346] In some implementations, the time when the first network element and the second device complete communication is any one of the following times: the time when the first network element receives the device identifier of the second device; the time when the first network element sends the first security configuration information; the time when the first network element receives the reply message for the first security configuration information; wherein, the first security configuration information is security configuration information for the second device.

[0347] In some implementations, if the first message includes command-related information and the first device stores a valid context of the second device, then the second message is used for the command flow; or if the first message includes command-related information and the first device does not store a valid context of the second device, then the second message is used for the inventory flow.

[0348] In some implementations, whether the first device stores a valid context of the second device is related to a second time, which is determined based on the time when the first device and the second device complete communication.

[0349] In some implementations, the time when the first device and the second device complete communication is: the time when the first device receives the device identifier of the second device.

[0350] In some implementations, if the first device stores a valid context of the second device, the second message includes the AS ID assigned by the first device to the second device; or if the first device does not store a valid context of the second device, the second message includes the device identifier of the second device.

[0351] In some implementations, if the second message includes inventory-related information, then the second message also includes security configuration information for the second device.

[0352] Figure 15 This is a schematic block diagram of a communication device provided in an embodiment of this application. The communication device 1500 can be any of the first network elements described above. For example... Figure 15 As shown, the communication device 1500 includes a transmitting module 1510.

[0353] In one possible implementation, the device 1500 can be used to perform the steps described above by the first network element.

[0354] The sending module 1510 is used to send a first message to a first device, the first message being used to trigger the first device to send a second message to a second device; wherein, the first message includes inventory-related information or command-related information, the second message is used for inventory process or command process, and the process targeted by the second message is related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element.

[0355] In some implementations, if the first message includes inventory-related information, then the second message is used in the inventory process.

[0356] In some implementations, the first message may also include first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to a command.

[0357] In some implementations, if the first message includes information related to the command, then the second message is used for inventory or command processes.

[0358] In some implementations, if the first message includes command-related information and second indication information, the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent R2D transmission, and the service type is inventory and command; or if the first message includes command-related information and third indication information, the second message is used for the command process, wherein the third indication information indicates one or more of the following: the command process is executed directly, there is no subsequent R2D transmission, and the service type is inventory.

[0359] In some implementations, the indication information included in the first message is related to a first time, which is determined based on the time when the first network element and the second device complete communication.

[0360] In some implementations, the time when the first network element and the second device complete communication is any one of the following times: the time when the first network element receives the device identifier of the second device; the time when the first network element sends the first security configuration information; the time when the first network element receives the reply message for the first security configuration information; wherein, the first security configuration information is security configuration information for the second device.

[0361] In some implementations, if the first message includes command-related information and the first device stores a valid context of the second device, then the second message is used for the command flow; or if the first message includes command-related information and the first device does not store a valid context of the second device, then the second message is used for the inventory flow.

[0362] In some implementations, whether the first device stores a valid context of the second device is related to a second time, which is determined based on the time when the first device and the second device complete communication.

[0363] In some implementations, the time when the first device and the second device complete communication is: the time when the first device receives the device identifier of the second device.

[0364] In some implementations, if the first device stores a valid context of the second device, the second message includes the AS ID assigned by the first device to the second device; or if the first device does not store a valid context of the second device, the second message includes the device identifier of the second device.

[0365] In some implementations, if the second message includes inventory-related information, then the second message also includes security configuration information for the second device.

[0366] Figure 16 This is a schematic block diagram of a communication device provided in an embodiment of this application. The communication device 1600 can be any of the second devices described above. For example... Figure 16 As shown, the communication device 1600 includes a receiving module 1610.

[0367] In one possible implementation, the device 1600 can be used to perform the steps described above by the second device.

[0368] The receiving module 1610 is used to send a first message to a first device, the first message being used to trigger the first device to send a second message to a second device; wherein, the first message includes inventory-related information or command-related information, the second message is used for inventory process or command process, and the process targeted by the second message is related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element.

[0369] In some implementations, if the first message includes inventory-related information, then the second message is used in the inventory process.

[0370] In some implementations, the first message may also include first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to a command.

[0371] In some implementations, if the first message includes information related to the command, then the second message is used for inventory or command processes.

[0372] In some implementations, if the first message includes command-related information and second indication information, the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent R2D transmission, and the service type is inventory and command; or if the first message includes command-related information and third indication information, the second message is used for the command process, wherein the third indication information indicates one or more of the following: the command process is executed directly, there is no subsequent R2D transmission, and the service type is inventory.

[0373] In some implementations, the indication information included in the first message is related to a first time, which is determined based on the time when the first network element and the second device complete communication.

[0374] In some implementations, the time when the first network element and the second device complete communication is any one of the following times: the time when the first network element receives the device identifier of the second device; the time when the first network element sends the first security configuration information; the time when the first network element receives the reply message for the first security configuration information; wherein, the first security configuration information is security configuration information for the second device.

[0375] In some implementations, if the first message includes command-related information and the first device stores a valid context of the second device, then the second message is used for the command flow; or if the first message includes command-related information and the first device does not store a valid context of the second device, then the second message is used for the inventory flow.

[0376] In some implementations, whether the first device stores a valid context of the second device is related to a second time, which is determined based on the time when the first device and the second device complete communication.

[0377] In some implementations, the time when the first device and the second device complete communication is: the time when the first device receives the device identifier of the second device.

[0378] In some implementations, if the first device stores a valid context of the second device, the second message includes the AS ID assigned by the first device to the second device; or if the first device does not store a valid context of the second device, the second message includes the device identifier of the second device.

[0379] In some implementations, if the second message includes inventory-related information, then the second message also includes security configuration information for the second device.

[0380] It should be understood that the devices 1400-1600 here are embodied in the form of functional modules. The term "module" here can refer to application-specific integrated circuits (ASICs), electronic circuits, processors (e.g., shared processors, proprietary processors, or group processors, etc.) and memories for executing one or more software or firmware programs, integrated logic circuits, and / or other suitable components supporting the described functions. In an alternative example, those skilled in the art will understand that device 1400 may specifically be the first device in the above embodiments, and device 1400 may be used to execute the various processes and / or steps corresponding to the first device in the above method embodiments. Device 1500 may specifically be the first network element in the above embodiments, and device 1500 may be used to execute the various processes and / or steps corresponding to the first network element in the above method embodiments. Device 1600 may specifically be the second device in the above embodiments, and device 1600 may be used to execute the various processes and / or steps corresponding to the second device in the above method embodiments. To avoid repetition, further details are omitted here.

[0381] The aforementioned device 1400 has the function of implementing the corresponding steps performed by the first device in the aforementioned method, device 1500 has the function of implementing the corresponding steps performed by the first network element in the aforementioned method, and device 1600 has the function of implementing the corresponding steps performed by the second device in the aforementioned method. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions.

[0382] In embodiments of this application, devices 1400-1600 can also be chips, such as system-on-chip (SOC) or modems. Correspondingly, the receiving module and the transmitting module can be the transceiver circuits of the chip, and are not limited herein.

[0383] Figure 17 This is a schematic structural diagram of a communication device according to an embodiment of this application. Figure 17 The dashed lines indicate that the unit or module is optional. The device 1700 can be used to implement the methods described in the above method embodiments. The device 1700 can be a chip, a first device, a second device, or a first network element.

[0384] Apparatus 1700 may include one or more processors 1710. The processor 1710 may support apparatus 1700 in implementing the methods described in the preceding method embodiments. The processor 1710 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), ASICs, field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0385] The apparatus 1700 may further include one or more memories 1720. The memories 1720 store a program that can be executed by the processor 1710, causing the processor 1710 to perform the methods described in the preceding method embodiments. The memories 1720 may be independent of the processor 1710 or integrated within the processor 1710.

[0386] The device 1700 may also include a transceiver 1730. The processor 1710 can communicate with other devices or chips via the transceiver 1730. For example, the processor 1710 can send and receive data with other devices or chips via the transceiver 1730.

[0387] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to a first device, a second device, or a first network element provided in this application, and the program causes a computer to execute the methods performed by the first device, the second device, or the first network element in various embodiments of this application.

[0388] This application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the first device, second device, or first network element provided in the embodiments of this application, and the program causes a computer to execute the methods performed by the first device, second device, or first network element in various embodiments of this application.

[0389] This application also provides a computer program. This computer program can be applied to the first device, second device, or first network element provided in this application, and causes the computer to execute the methods performed by the first device, second device, or first network element in various embodiments of this application.

[0390] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0391] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0392] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0393] In this application, entity A sends information to entity B, either directly or indirectly through other entities. Similarly, entity B receives information from entity A, either directly or indirectly through other entities. Entities A and B can be RAN nodes or terminals, or modules within RAN nodes or terminals. Information transmission and reception can be between RAN nodes and terminals, such as between a base station and a terminal; between two RAN nodes, such as between a CU and a DU; or between different modules within a single device, such as between a terminal chip and other modules of the terminal, or between a base station chip and other modules of the base station.

[0394] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0395] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0396] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0397] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0398] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A wireless communication method, characterized in that, The method is applied to a first device and includes: Receive a first message sent by a first network element, the first message including inventory-related information or command-related information; Send a second message to the second device. The second message is used for inventory process or command process. The process targeted by the second message is related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element.

2. The method according to claim 1, characterized in that, If the first message includes inventory-related information, then the second message is used in the inventory process.

3. The method according to claim 2, characterized in that, The first message also includes first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to the command.

4. The method according to claim 1, characterized in that, If the first message includes information related to the command, then the second message is used for the inventory process or the command process.

5. The method according to claim 4, characterized in that, If the first message includes command-related information and the first message includes second indication information, then the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent R2D transmission, and the service type is inventory and command; or If the first message includes command-related information and the first message includes third indication information, then the second message is used for the command flow, wherein the third indication information is used to indicate one or more of the following: direct execution of the command flow, no subsequent reader-to-device R2D transmission, and service type is disk storage.

6. The method according to claim 5, characterized in that, The indication information included in the first message is related to a first time, which is determined based on the time when the first network element and the second device complete communication.

7. The method according to claim 6, characterized in that, The communication between the first network element and the second device is completed at any of the following times: The time when the first network element receives the device identifier of the second device; The time when the first network element sends the first security configuration information; The time when the first network element receives the reply message regarding the first security configuration information; The first security configuration information is the security configuration information for the second device.

8. The method according to claim 4, characterized in that, If the first message includes command-related information and the first device stores the valid context of the second device, then the second message is used for the command flow. or If the first message includes information related to the command, and the first device does not store a valid context for the second device, then the second message is used for the inventory process.

9. The method according to claim 8, characterized in that, Whether the first device stores a valid context of the second device is related to a second time, which is determined based on the time when the first device and the second device complete communication.

10. The method according to claim 9, characterized in that, The time when the first device and the second device complete communication is: the time when the first device receives the device identifier of the second device.

11. The method according to any one of claims 1-10, characterized in that, If the second message includes inventory-related information, then the second message also includes security configuration information for the second device.

12. A wireless communication method, characterized in that, The method is applied to the first network element, including: Send a first message to the first device, the first message being used to trigger the first device to send a second message to the second device; The first message includes inventory-related information or command-related information, and the second message is used for inventory or command processes. The process targeted by the second message is related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element.

13. The method according to claim 12, characterized in that, If the first message includes inventory-related information, then the second message is used in the inventory process.

14. The method according to claim 13, characterized in that, The first message also includes first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to the command.

15. The method according to claim 12, characterized in that, If the first message includes information related to the command, then the second message is used for the inventory process or the command process.

16. The method according to claim 15, characterized in that, If the first message includes command-related information and the first message includes second indication information, then the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent reader-to-device R2D transmission, and the service type is inventory and command; or If the first message includes command-related information and the first message includes third indication information, then the second message is used for command flow, wherein the third indication information is used to indicate one or more of the following: direct execution of command flow, no subsequent R2D transmission, and service type is disk storage.

17. The method according to claim 16, characterized in that, The indication information included in the first message is related to a first time, which is determined based on the time when the first network element and the second device complete communication.

18. The method according to claim 17, characterized in that, The communication between the first network element and the second device is completed at any of the following times: The time when the first network element receives the device identifier of the second device; The time when the first network element sends the first security configuration information; The time when the first network element receives the reply message regarding the first security configuration information; The first security configuration information is the security configuration information for the second device.

19. The method according to claim 15, characterized in that, If the first message includes command-related information and the first device stores the valid context of the second device, then the second message is used for the command flow. or If the first message includes information related to the command, and the first device does not store a valid context for the second device, then the second message is used for the inventory process.

20. The method according to claim 19, characterized in that, Whether the first device stores a valid context of the second device is related to a second time, which is determined based on the time when the first device and the second device complete communication.

21. The method according to claim 19, characterized in that, The time when the first device and the second device complete communication is: the time when the first device receives the device identifier of the second device.

22. The method according to any one of claims 12-21, characterized in that, If the second message includes inventory-related information, then the second message also includes security configuration information for the second device.

23. A wireless communication method, characterized in that, The method is applied to a second device, including: The system receives a second message sent by the first device. The second message is used for inventory or command processes. The process targeted by the second message is related to the information included in the first message and / or the context corresponding to the second device maintained by the first device and / or the first network element. The first message is sent from the first network element to the first device and includes inventory-related information or command-related information.

24. The method according to claim 23, characterized in that, If the first message includes inventory-related information, then the second message is used in the inventory process.

25. The method according to claim 24, characterized in that, The first message also includes first indication information, which is used to indicate receiving or listening to a third message, the third message including information related to the command.

26. The method according to claim 23, characterized in that, If the first message includes information related to the command, then the second message is used for the inventory process or the command process.

27. The method according to claim 26, characterized in that, If the first message includes command-related information and the first message includes second indication information, then the second message is used for the inventory process, wherein the second indication information indicates one or more of the following: the inventory process is executed first, there is subsequent reader-to-device R2D transmission, and the service type is inventory and command; or If the first message includes command-related information and the first message includes third indication information, then the second message is used for command flow, wherein the third indication information is used to indicate one or more of the following: direct execution of command flow, no subsequent R2D transmission, and service type is disk storage.

28. The method according to claim 26, characterized in that, If the first message includes command-related information and the first device stores the valid context of the second device, then the second message is used for the command flow. or If the first message includes information related to the command, and the first device does not store a valid context for the second device, then the second message is used for the inventory process.

29. A communication device, characterized in that, include: A processor coupled to a memory for storing a computer program, wherein when the processor invokes the computer program, the communication device performs the method as claimed in any one of claims 1 to 11, or any one of claims 12 to 22, or any one of claims 23 to 28.

Images