Communication method, apparatus, chip system, storage medium and computer program product

Abstract

The embodiment of the application provides a communication method, device, chip system, storage medium and computer program product, and belongs to the technical field of communication. In the method, when the failure type of the first AIoT device is an unrecoverable failure, the first AIoT device indicates to the read-write device that the first AIoT device cannot permanently report operation data through a message, so that the read-write device can stop sending request data for requesting operation data to the first AIoT device, that is, the read-write device no longer periodically sends the request message for requesting operation data to the first AIoT at this time. In this way, the communication overhead of the read-write device can be reduced, and the communication resources can be saved.

Description

Technical Field

[0001] This application belongs to the field of communication technology, specifically relating to a communication method, device, chip system, storage medium, and computer program product. Background Technology

[0002] In the ambient internet of things (AIoT), a reader / writer can instruct AIoT devices to perform operations such as inventory checks. For example, when paging an AIoT device, the reader / writer can instruct it to perform inventory checks and report the data obtained from these operations. After the AIoT device successfully connects to the reader / writer, the reader / writer can send a request message to the AIoT device requesting operation data, so that the AIoT device can report the data obtained from the operation (such as inventory checks) to the reader / writer.

[0003] When the AIoT device does not send operation data to the reader / writer, the reader / writer periodically sends request messages to the device to request operation data. However, this increases the communication overhead of the reader / writer and wastes communication resources. Summary of the Invention

[0004] In view of this, this application provides a communication method, apparatus, chip system, storage medium, and computer program product to reduce the communication overhead of read / write devices and save communication resources.

[0005] In a first aspect, embodiments of this application provide a communication method. This method can be executed by an AIoT device, by a component (such as a processor, circuit, chip, or chip system) configured in the AIoT device, or by a logic module or software capable of implementing all or part of the functions of the AIoT device. This application does not limit this. The following description uses a first AIoT device as an example.

[0006] The method includes: receiving a first message from a read / write device; in the event that the failure of the first AIoT device is an unrecoverable failure, in response to the first message, sending a second message to the read / write device; wherein the first message is used to request the first AIoT device to report operation data, the operation data being data obtained by the first AIoT device after performing a specified operation, and the second message includes first information, the first information being used to indicate that the first AIoT device is permanently unable to report operation data.

[0007] When the first AIoT device experiences an unrecoverable fault, it is unable to acquire or report operational data. In this case, the first AIoT device indicates to the read / write device via a first message that it is permanently unable to report operational data. Based on this first message, the read / write device can stop sending request data to the first AIoT device. In other words, the read / write device can cease periodically sending request messages to the first AIoT device. This reduces the communication overhead of the read / write device and allows communication resources allocated to the first AIoT device to be used by other devices, thereby improving overall communication efficiency.

[0008] In one possible implementation, the first information is a first fault classification code, which indicates an unrecoverable fault. After receiving the first information, the read / write device can indicate the fault type of the first AIoT device to the core network element based on the first fault classification code, or it can indicate a permanent fault in the first AIoT device based on the first fault classification code. This enables the core network element to notify the equipment operator to handle the first AIoT device. Furthermore, when the core network element indicates the fault type of the first AIoT device to the equipment operator, the equipment operator can handle the first AIoT device based on the fault type, thereby improving the efficiency of the equipment operator's handling of the first AIoT device.

[0009] The fault type indicated by the first fault classification code above is any of the following: data-related module damage, or insufficient power of non-rechargeable devices. Data-related module damage can be understood as: the device's data acquisition module is damaged, or the device's data storage module is damaged, in which case the device will permanently be unable to generate (or acquire) operational data. Insufficient power of non-rechargeable devices can be understood as: insufficient power in non-rechargeable or passive devices, to the point that NAS layer processing can never be initiated.

[0010] In one possible implementation, the second message also includes a service data unit, which indicates that the second message does not carry operation data. This avoids the read / write device triggering related processing flows for operation data, thereby saving processing resources and improving message processing efficiency.

[0011] In one possible implementation, after receiving the first message from the read / write device, the method of the first aspect further includes: if the fault type of the first AIoT device is a recoverable fault, sending a third message to the read / write device, the third message including duration information indicating the estimated waiting time for the first AIoT device to prepare the operation data. Based on the third message, the read / write device can wait for the specified duration before sending a request message for the operation data to the first AIoT device, meaning that the read / write device no longer periodically sends request messages for the operation data to the first AIoT device. This avoids the read / write device frequently sending request messages, thereby reducing the communication overhead of the read / write device and saving communication resources.

[0012] In one possible implementation, the duration information includes classification information and timer configuration information. The timer configuration information indicates the estimated duration for the first AIoT device to prepare the operation data under the duration category indicated by the classification information. Thus, when there are many preset or predefined durations, or when the value of the waiting duration is large, the waiting duration can be indicated with fewer bits, thereby reducing the communication overhead of the first AIoT device and ensuring that the duration information does not exceed the protocol's length limit for device-to-device (D2R) messages.

[0013] In one possible implementation, the classification information is a second fault classification code, which indicates a recoverable fault type. The read / write device can send the fault type of the first AIoT device to the core network element based on the second fault classification code, so that the core network element can notify the device operator to handle the first AIoT device, such as through repair or replacement.

[0014] The fault type indicated by the second fault classification code mentioned above is any of the following: insufficient rechargeable device power, device waiting to execute commands, or temporary resource conflict. Insufficient rechargeable device power can be understood as: the rechargeable device circuitry is insufficient; NAS layer functionality can be restored after charging, or NAS processing can be initiated after charging. Device waiting to execute commands can be understood as: the device's NAS layer is processing other commands and is temporarily unable to process operational data. Temporary resource conflict can be understood as: the data unit carrying data (such as operational data) is experiencing resource contention and conflict with other data units at the Media Access Control (MAC) layer (or physical PHY layer).

[0015] In one possible implementation, the third message also includes a service data unit, which indicates that the third message does not carry operation data. This avoids the read / write device triggering related processing flows for operation data, thereby saving processing resources and improving message processing efficiency.

[0016] In one possible implementation, after sending the third message to the read / write device, the method described in the first aspect further includes: within the waiting period, and after the first AIoT device has recovered from its malfunction, sending a fourth message to the read / write device, the fourth message indicating that the first AIoT device has prepared the operation data. This allows the read / write device to stop its timer upon receiving the fourth message and request the operation data from the first AIoT device. That is, the read / write device does not need to wait for the aforementioned waiting period before requesting the operation data from the first AIoT device; it can request the operation data earlier, thereby enabling the read / write device to obtain the operation data as quickly as possible and improving the timeliness of operation data acquisition.

[0017] In one possible implementation, after sending the third message to the read / write device, the method of the first aspect further includes: within a waiting period, and if the fault type of the first AIoT device changes from a recoverable fault to an unrecoverable fault, sending a fifth message to the read / write device, the fifth message indicating that the first AIoT device is permanently unable to report operational data. Thus, in the event of a worsening fault in the first AIoT device, the read / write device no longer sends a request message for operational data to the first AIoT device when the timer expires, thereby reducing the communication overhead of the read / write device and allowing the communication resources allocated to the first AIoT device to be distributed to other devices, thereby improving overall communication efficiency.

[0018] In one possible implementation, the fifth message includes a third fault classification code, which indicates an unrecoverable fault. It is understood that after receiving the third fault classification code, the read / write device can indicate the fault type of the first AIoT device to the core network element based on the third fault classification code, or it can indicate a permanent fault of the first AIoT device to the core network element based on the first fault classification code. This enables the core network element to notify the equipment operator to handle the first AIoT device promptly.

[0019] Secondly, embodiments of this application provide a communication method. This method can be executed by a read / write device, by a component (such as a processor, circuit, chip, or chip system) configured in the read / write device, or by a logic module or software capable of implementing all or part of the functions of the read / write device. This application does not limit this. Furthermore, the read / write device can be located within an AIoT (Artificial Intelligence of Things) system. The following description uses a read / write device as an example.

[0020] The method includes: receiving a second message from the first AIoT device when the fault type of the first AIoT device is an unrecoverable fault; and stopping sending request messages to the first AIoT device in response to the second message; wherein the second message includes first information indicating that the first AIoT device is permanently unable to report operation data, the operation data being data obtained by the first AIoT device after performing a specified operation, and the request message requesting the first AIoT device to report operation data.

[0021] In one possible implementation, the first information is a first fault classification code, which indicates an unrecoverable fault type; the method in the second aspect further includes: sending the fault type of the first AIoT device to the core network element; or, according to the first information, sending a sixth message to the core network element, which indicates a permanent fault of the first AIoT device.

[0022] The fault type indicated by the first fault classification code above is any of the following: damage to the data-related module, or insufficient power in the non-rechargeable device.

[0023] In one possible implementation, the second message also includes a service data unit, which is used to indicate that the second message does not carry operation data.

[0024] In one possible implementation, after receiving the second message from the first AIoT device, the method in the second aspect further includes: acquiring a plurality of AIoT devices to be paged, the plurality of AIoT devices including the first AIoT device; and sending a paging message to a second AIoT device, the second AIoT device being one of the plurality of AIoT devices other than the first AIoT device. After receiving the second message, the read / write device can determine that the first AIoT device has suffered an unrecoverable failure, and can mark the first AIoT device as permanently offline. When the read / write device pagees a plurality of AIoT devices including the first AIoT device, excluding the first AIoT device from these plurality of paged AIoT devices allows the paging message to not carry the identifier of the first AIoT device, thereby reducing the communication overhead of the read / write device.

[0025] In one possible implementation, after receiving the second message from the first AIoT device, the method of the second aspect further includes: if the fault type of the first AIoT device is a recoverable fault, receiving a third message from the read / write device, the third message including duration information used to indicate the estimated waiting time for the first AIoT device to prepare operation data; and configuring a timer according to the waiting time, the timer being set to trigger the sending of a request message when the waiting time is reached, the request message being used to request the first AIoT device to report operation data.

[0026] In one possible implementation, the duration information includes classification information and timer configuration information, which indicates the estimated duration for the first AIoT device to prepare operational data under the duration category indicated by the classification information.

[0027] In one possible implementation, the classification information is a second fault classification code, which indicates a recoverable fault type. After configuring the timer according to the waiting duration, the method in the second aspect further includes: after the timer reaches the waiting duration, sending a seventh message to the first AIoT device, which requests the first AIoT device to report operation data; and if no operation data is received, sending the fault type of the first AIoT device to the core network element.

[0028] The fault type indicated by the above second fault classification code is any of the following: insufficient power of the rechargeable device, device waiting to execute a command, or temporary resource conflict.

[0029] In one possible implementation, the third message also includes a service data unit, which is used to indicate that the third message does not carry operation data.

[0030] In one possible implementation, after receiving the third message from the read / write device, the method of the second aspect further includes: during the waiting period, and after the fault of the first AIoT device has been resolved, receiving a fourth message from the first AIoT device, the fourth message indicating that the first AIoT device has prepared the operation data; in response to the fourth message, stopping the timer and sending an eighth message to the first AIoT device, the eighth message requesting the first AIoT device to report the operation data.

[0031] In one possible implementation, after receiving the third message from the read / write device, the method of the second aspect further includes: during the waiting period, and if the fault type of the first AIoT device changes from a recoverable fault to an unrecoverable fault, receiving a fifth message from the first AIoT device, the fifth message indicating that the first AIoT device is permanently unable to report operation data; in response to the fifth message, stopping the timer and stopping sending request messages to the first AIoT device.

[0032] In one possible implementation, the fifth message includes a third fault classification code, which indicates that the fault type is an unrecoverable fault; after receiving the fifth message from the first AIoT device, the method of the second aspect further includes: sending the fault type of the first AIoT device to the core network element.

[0033] The second aspect is the implementation on the read / write device side, which corresponds to the first aspect. The explanations, supplements, and descriptions of the beneficial effects of the first aspect also apply to the second aspect, and will not be repeated here.

[0034] Thirdly, a communication method is provided, the method comprising: a first AIoT device performing the method described in the first aspect, and a read / write device performing the method described in the second aspect.

[0035] Fourthly, a communication device is provided. The communication device includes: a module for performing the method in any possible implementation of any of the above aspects, such as a communication module and a processing module. For example, the communication module is used to instruct the transmission and reception functions of the communication device, and the processing module is used to perform functions of the communication device other than the transmission and reception functions.

[0036] Optionally, the communication module may include a transmitting module and a receiving module. The transmitting module implements the transmitting function of the communication device described in the fourth aspect, and the receiving module implements the receiving function of the communication device described in the fourth aspect.

[0037] Optionally, the communication device described in the fourth aspect may further include a storage module storing programs or instructions. When the processing module executes the program or instructions, the communication device can perform the methods in any of the possible implementations of any of the above aspects.

[0038] It is understood that the communication device described in the fourth aspect may be an AIoT device or a read / write device, or it may be a chip (system) or other component or assembly that can be disposed in the AIoT device or the read / write device, or it may be a device that includes the AIoT device or the read / write device. This application does not limit it in this regard.

[0039] Furthermore, the technical effects of the communication device described in the fourth aspect can be referenced from the technical effects of the methods in any possible implementation of any of the above aspects, and will not be repeated here.

[0040] Fifthly, a communication device is provided, including at least one processor. The at least one processor is coupled to a memory storing programs or instructions. The processor executes the programs or instructions in the memory, causing the communication device to perform a method in any possible implementation of any of the above aspects. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, to which the processor is coupled.

[0041] In one implementation, the communication interface may be a transceiver, or an input / output interface.

[0042] In another implementation, the communication device is a chip configured in a terminal device or network device. When the communication device is a chip configured in a terminal device or network device, the communication interface can be an input / output interface.

[0043] In a sixth aspect, a processor is provided, comprising: an input circuit, an output circuit, and a processing circuit. The processing circuit is configured to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute a method in any possible implementation of any aspect.

[0044] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit can be output to, for example, but not limited to, a transmitter and transmitted by the transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0045] In a seventh aspect, a communication device is provided, including a processor and a memory. The processor is used to read instructions stored in the memory and to receive signals via a receiver and transmit signals via a transmitter to execute the method in any possible implementation of any of the above aspects.

[0046] Optionally, the processor may be one or more, and the memory may be one or more.

[0047] Eighthly, embodiments of this application provide a chip system including one or more processors for calling and executing instructions stored in memory, causing the methods in any of the above aspects or possible implementations to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0048] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0049] Ninthly, a computer-readable storage medium is provided that stores a computer program or instructions, which, when executed, cause a computer to perform the method in any possible implementation of any of the preceding aspects.

[0050] In a tenth aspect, a computer program product is provided, the computer program product comprising: a computer program or instructions, which, when the computer program is run, causes the method in any possible implementation of any of the preceding aspects to be executed.

[0051] Eleventhly, a communication system is provided, comprising: a first AIoT device for performing the method of the first aspect, and a read / write device for performing the method of the second aspect. Attached Figure Description

[0052] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings.

[0053] Figure 1 A schematic diagram of the communication system provided in the embodiments of this application;

[0054] Figure 2 Flowchart of the communication method provided in the embodiments of this application Figure 1 ;

[0055] Figure 3 Flowchart of the communication method provided in the embodiments of this application Figure 2 ;

[0056] Figure 4 Flowchart of the communication method provided in the embodiments of this application Figure 3 ;

[0057] Figure 5 Schematic diagram of the communication device provided in the embodiments of this application Figure 1 ;

[0058] Figure 6 Schematic diagram of the communication device provided in the embodiments of this application Figure 2 . Detailed Implementation

[0059] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0060] The technical solutions provided in this application can be applied to various communication systems, such as: Global System for Mobile Communications (GSM) systems, General Packet Radio Service (GPRS), Wireless Local Area Network (WLAN), Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, sidelink communication systems, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication systems, non-terrestrial network (NTN) communication systems, 5th generation (5G) mobile communication systems, or new radio access technology (NR). Among these, 5G mobile communication systems can include non-standalone (NSA) and / or standalone (SA) networking. The technical solutions provided in this application can also be applied to future communication systems. This application does not limit the scope of these applications.

[0061] Figure 1 This is a schematic diagram of a communication system applied in an embodiment of this application. The communication system may include: an AIoT device and a reader.

[0062] AIoT devices can be sensors, such as temperature sensors, humidity sensors, detectors, cameras, positioning devices, etc. This application does not limit the type or form of AIoT devices. AIoT devices can also be called devices, terminal devices, AIoT terminals, etc. In this application, the device used to implement the functions of an AIoT device can be an AIoT device itself, or a device capable of supporting the AIoT device in implementing that function, such as a processor, circuit, chip, or chip system. This device can be installed in or connected to the AIoT device. In the technical solutions provided in this application, the example of an AIoT device being used to implement the functions of an AIoT device is used to describe the technical solutions provided in this application.

[0063] The read / write device in this application can be used to operate at least one AIoT device, such as reading, writing, and inventory operations; and the read / write device can be a wireless device capable of receiving network device scheduling and instruction information. This wireless device can be a device with reader / writer functionality. The read / write device can also be referred to as a reader / writer, AIoT terminal, terminal, user equipment (UE), user equipment reader / writer (UE reader), mobile station, mobile terminal, etc. The read / write device can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), ultra-reliable low-latency communication (URLLC), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart cities, or satellite communication, etc. The reading and writing device can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, wearable device, vehicle, aircraft (such as drone, helicopter, airplane), hot air balloon, ship, robot, robotic arm, or smart home device, etc. The embodiments of this application do not limit the form of the reading and writing device.

[0064] In this application, the device used to implement the function of the read / write device can be a read / write device itself, or a device capable of supporting the read / write device in implementing this function, such as a processor, circuit, chip, or chip system. This device can be installed in or connected to the read / write device. In the technical solution provided in this application, the use of a read / write device as an example of a device implementing the function of the read / write device is described.

[0065] Optionally, the aforementioned communication system may further include core network elements. These core network elements can communicate with the read / write devices, such as sending instructions from the service provider to the read / write device, or forwarding AIoT-related data sent by the read / write device to the service provider. The core network elements can be access and mobility management function (AMF) entities, or ambient internet of things (AIoTF) entities, etc., and can be configured according to actual circumstances without limitation.

[0066] To facilitate understanding of the embodiments of this application, a brief explanation of the technical terms involved in this application is provided first. Optionally, the explanation of some terms may also refer to the explanations in the 3rd Generation Partnership Project (3GPP) standard protocol. It should be understood that the technical terms in this application are for illustrative purposes only and not as limiting. For example, as technology evolves, technical terms may also change; where the technical meaning remains the same, other technical terms should also apply to this application.

[0067] 1. AIoT: With the development of communication technology, 3GPP defined AIoT. AIoT can also be called ambient power-enabled IoT or passive IoT (P-IoT). AIoT can also be referred to as A-IoT, and this application does not limit it to that.

[0068] 2. Delayed response can be understood as: when an AIoT device requests operation data from a read / write device, the operation data is not ready and is sent to the read / write device with a delay.

[0069] 3. Completely unresponsive can be understood as follows: When an AIoT device requests operation data from a read / write device, it is permanently unable to obtain the operation data and is permanently unable to send the operation data to the read / write device. That is, without external or human intervention, the AIoT device is unable to obtain the operation data and is unable to send the operation data to the read / write device.

[0070] To address the aforementioned issue that when an AIoT device periodically sends request messages to the reader / writer device even when the device is not sending operation data, this increases communication overhead and wastes communication resources. This application proposes that when the AIoT device experiences an unrecoverable failure, it can indicate to the reader / writer device via a message that it is permanently unable to report operation data. This causes the reader / writer device to stop sending request data to the AIoT device, thereby reducing communication overhead and conserving communication resources.

[0071] The solution provided in this application will be described in detail below with reference to the corresponding flowcharts. It is understood that the illustrative flowcharts provided in this application primarily use different devices (such as AIoT devices and read / write devices) as examples of the execution subjects of this interaction to illustrate the method, but this application does not limit the execution subjects of the interaction. For example, the devices (such as AIoT devices and read / write devices) in the illustrative flowcharts can also be chips, chip systems, or processors that support the implementation of this method on the device, or logic modules or software that can implement all or part of the functions of the device.

[0072] It is hereby uniformly stated that the message or signaling interactions involved in the interaction process of the embodiments of this application can adopt standard messages or signaling, or they can be newly introduced messages or signaling. The embodiments of this application do not specifically limit this. The following embodiments are provided as examples to more clearly illustrate the technical solutions of this application, and should not be used to limit the scope of protection of this application. Those skilled in the art will understand that, without conflict, the following embodiments and features can be combined with each other.

[0073] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, relational terms such as "first," "second," etc., in the description of this application are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0074] Furthermore, the term "and / or" in this application is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0075] In the description of the embodiments of this application, unless otherwise expressly specified and limited, the technical term "connection" can be a direct connection or an indirect connection through an intermediate medium.

[0076] Figure 2 Flowchart of the communication method provided in the embodiments of this application Figure 1 This method is applied to AIoT, and it can be used for interactions between AIoT devices and read / write devices in the aforementioned communication system. It is understood that this application uses an AIoT device as the first example for illustration.

[0077] like Figure 2 As shown, the communication method includes the following steps:

[0078] S201, the read / write device sends a first message to the first AIoT device. Correspondingly, the first AIoT device receives the first message from the read / write device.

[0079] The first message is used to request the first AIoT device to report (or send) operation data.

[0080] For the first AIoT device, please refer to the relevant introduction of AIoT devices in the aforementioned communication system section, which will not be repeated here.

[0081] The operation data is the data obtained after the first AIoT device performs the specified operation.

[0082] The specified operation can be an operation instructed by the read / write device to the first AIoT device. For example, the read / write device can instruct the first AIoT device to perform the operation via a paging message when paging the first AIoT device. Additionally, when receiving a service instruction from a core network element, the read / write device can instruct the first AIoT device to perform the operation corresponding to that service instruction. The specified operation can also be an operation that the first AIoT device performs periodically. For example, the read / write device can instruct the first AIoT device to periodically perform operations such as inventory checks, or the first AIoT device can be pre-configured to perform inventory checks periodically. The specified operation can be an inventory check, read, or write operation, and the specific configuration can be set according to actual conditions without limitation.

[0083] When the specified operation is an operation instructed by the read / write device to the first AIoT device, the operation data is the data obtained by the first AIoT device after performing the operation. When the specified operation is an operation periodically performed by the first AIoT device, the operation data can be the data obtained by the first AIoT device performing the latest operation, or it can be all data that has not been reported, without limitation. It is understood that the "operation data" mentioned in the embodiments of this application is only an exemplary expression, and "operation data" can also be replaced by any possible expression, such as "upper-layer data", "non-access stratum (NAS) data", or "NAS response", etc., without limitation.

[0084] The first message can also be used to instruct the first AIoT to send (or report) operation data, or to authorize the first AIoT to send (or report) operation data. The first message can be a reader-to-device (R2D) upper layer data transfer message in the upper-layer data transfer procedure in the prior art; the first message can also be a newly defined message, which is not limited in this application.

[0085] In this embodiment of the application, the read / write device can instruct the first AIoT device to perform the specified operation via a paging message; after receiving the paging message, the first AIoT device can send a random number (RN) 16 to the read / write device; after verifying that RN 16 is successful, the read / write device can send a first message to the first AIoT device to instruct the first AIoT device to send operation data to the read / write device.

[0086] S202, the first AIoT device sends a second message to the read / write device. Correspondingly, the read / write device receives the second message from the first AIoT device.

[0087] That is, in the case that the failure type of the first AIoT device is an unrecoverable failure, in response to the first message, the first AIoT device sends a second message to the read / write device.

[0088] Unrecoverable faults can be faults that the device cannot recover from on its own, meaning that external intervention (or manual intervention) is required to restore the device to normal operation. Unrecoverable faults can also be faults that cannot be recovered even after external intervention. The fault type of the first AIoT device being unrecoverable can be understood as follows: the first AIoT device malfunctions, and this malfunction cannot be recovered by the first AIoT device itself, or the malfunction cannot be recovered even after external intervention. In this case, the first AIoT device is permanently unable to acquire or report operational data; that is, the first AIoT device is completely unresponsive to the first message. In other words, the first AIoT device cannot acquire or report operational data until the fault is resolved through external intervention, or the first AIoT device may never be able to report operational data.

[0089] The second message includes the first information. This first information is used to indicate that the first AIoT device is permanently unable to report operational data, or in other words, the first information is used to indicate that the first AIoT device is completely unresponsive. The first AIoT device being permanently unable to report operational data can be understood as: the first AIoT device is unable to report operational data, and the duration of the first AIoT device's inability to report operational data (also known as a completely unresponsive state, or an unresponsive state) cannot be assessed.

[0090] In this embodiment, the first AIoT device can determine whether a fault is unrecoverable when it occurs. If the fault type of the first AIoT device is unrecoverable, in response to the first message, the first AIoT device can send a second message to the read / write device. Furthermore, this embodiment does not limit the specific time at which the first AIoT device malfunctions.

[0091] S203, in response to the second message, the read / write device stops sending request messages to the first AIoT device.

[0092] The request message is used to request the first AIoT device to report operation data. The first AIoT device and the operation data can be found in the aforementioned descriptions, and will not be repeated here. This request message can have the same structure as the first message, and is not limited thereto.

[0093] The fact that the read / write device stops sending request messages to the first AIoT device can be understood as: the read / write device no longer sends request messages to the first AIoT device. That is, after receiving the second message, the read / write device stops requesting operation data from the first AIoT device. For example, the read / write device can mark the first AIoT device as a permanently offline device, or the read / write device can delete the identification information of the first AIoT device from the device scheduling table.

[0094] In summary, in this embodiment, when the failure of the first AIoT device is an unrecoverable failure, the first AIoT device cannot obtain (or report) operation data. In this case, the first AIoT device indicates to the read / write device via first information that it is permanently unable to report operation data. Based on the first information, the read / write device can stop sending request data to the first AIoT device to request operation data. That is, at this time, the read / write device can stop periodically sending request messages to the first AIoT device to request operation data. In this way, the communication overhead of the read / write device can be reduced, and the communication resources allocated to the first AIoT device can be allocated to other devices, thereby improving the overall communication efficiency.

[0095] Optionally, in conjunction with the above embodiments, the first information is a first fault classification code, which indicates an unrecoverable fault type; the above method may further include: the reading and writing device sending the fault type of the first AIoT device to the core network element; or, the reading and writing device sending a sixth message to the core network element based on the first information, which is used to indicate a permanent fault of the first AIoT device.

[0096] The first fault classification code can indicate the fault type of the first AIoT device, such as damage to the data-related module of the first AIoT device (described below); and at this time, the fault type of the first AIoT device is an unrecoverable fault.

[0097] Fault types can be classified in many ways. For example, fault types can be divided into only unrecoverable faults and recoverable faults. Or they can be classified more finely. For example, unrecoverable faults can be further divided into multiple types, and recoverable faults can also be further divided into multiple types. That is, they can be further subdivided into the smallest indivisible fault type.

[0098] Fault classification codes can be represented using a certain number of bits. For example, a fault classification code can be represented using 4 bits, and a total of 16 fault classification codes can be represented using 4 bits. For instance, the first fault classification code could be 0001. The number of bits used to represent the fault classification code depends on the number of fault classification types; the number of bits should match the number of fault types. Alternatively, a larger number of bits can be reserved for undiscovered fault types. Furthermore, the number of bits used to represent the fault classification code can be determined in conjunction with communication overhead, thereby balancing the comprehensiveness of fault classification with communication overhead.

[0099] In this embodiment, different fault classification codes can be predefined in the protocol to correspond to different fault types; alternatively, different fault classification codes can be pre-set in the first AIoT device and the read / write device. Furthermore, after receiving the first fault classification code, the read / write device can determine (or ascertain) that the first fault classification code corresponds to an unrecoverable fault, thereby ceasing to send request messages to the first AIoT device.

[0100] For details on core network elements, please refer to the relevant introduction in the aforementioned communication system section; they will not be repeated here.

[0101] After receiving the first information, the read / write device can send the fault type of the first AIoT device to the core network element. Specifically, sending the fault type of the first AIoT device to the core network element can include sending the aforementioned first fault classification code. That is, the read / write device can indicate the fault type of the first AIoT device to the core network element through the first fault classification code. In this case, different fault classification codes can be predefined in the protocol, or different fault classification codes can be pre-set in the core network element. After receiving the fault type of the first AIoT device from the read / write device, the core network element can send the fault type of the first AIoT device to the device operator (or device owner, or service provider) to notify the device operator to handle the first AIoT device, such as repair or replacement. Furthermore, the device operator can handle the first AIoT device based on the fault type, thereby improving the efficiency of handling the first AIoT device.

[0102] Alternatively, after receiving the first message, the read / write device can indicate a permanent fault in the first AIoT device to the core network element. This permanent fault can be understood as a fault that the device cannot recover on its own, requiring manual intervention to restore normal operation, or a fault that cannot be restored even with manual intervention. This permanent fault is the same as an unrecoverable fault; please refer to the relevant introduction to unrecoverable faults for understanding, which will not be repeated here. After receiving the sixth message from the read / write device, the core network element can send a message to the equipment operator indicating a permanent fault in the first AIoT device, notifying the operator to handle the first AIoT device, such as repair or replacement.

[0103] In this embodiment, the first AIoT device, after determining its corresponding fault type, can report a first fault classification code corresponding to that fault type to the read / write device. Upon receiving the first fault classification code, the read / write device can indicate the fault type of the first AIoT device to the core network element based on the first fault classification code, or it can indicate a permanent fault of the first AIoT device to the core network element based on the first fault classification code. This enables the core network element to notify the equipment operator to handle the first AIoT device. Furthermore, when the core network element indicates the fault type of the first AIoT device to the equipment operator, the equipment operator can handle the first AIoT device based on the fault type, thereby improving the equipment operator's processing efficiency for the first AIoT device.

[0104] In addition, after receiving the fault type or the sixth message of the first AIoT device, the core network element can stop (or terminate) scheduling of the first AIoT device and reclaim the air interface resources corresponding to the first AIoT device, such as time slot resources and carrier power.

[0105] Furthermore, the above-mentioned fault types are any of the following: damage to data-related modules, or insufficient power in non-rechargeable devices.

[0106] Damage to data-related modules can be understood as either the data acquisition module or the data storage module of an AIoT device being damaged. In this case, the AIoT device will permanently be unable to generate (or acquire) operational data. The data acquisition module is used to collect data, such as data collected according to specified operations; the damaged data storage module is used to store the collected data. It can be understood that the data acquisition module and the data storage module are modules corresponding to the NAS layer of the AIoT device. This NSA layer can be used to process data (such as operational data), such as encapsulating data into upper-layer protocol data units, etc. For details, please refer to relevant descriptions in existing technologies; they will not be elaborated upon here.

[0107] Insufficient power for non-rechargeable devices can be understood as: insufficient power in non-rechargeable or passive devices, to the point that they are permanently unable to start NAS layer processing.

[0108] It is understood that the aforementioned data related modules being damaged or the non-rechargeable device having insufficient power could be referred to by other names, and this application does not limit this.

[0109] When an unrecoverable fault occurs, such as damage to a data-related module or insufficient power in a non-rechargeable device, different fault classification codes can be used to indicate the damage to the data-related module or the insufficient power in a non-rechargeable device. For example, fault classification code 0001 can indicate damage to a data-related module, and fault classification code 0010 can indicate insufficient power in a non-rechargeable device.

[0110] In this embodiment of the application, the fault type indicated by the first fault classification code can also be other fault types besides damage to data-related modules or insufficient power of non-rechargeable devices. The specific type can be set according to the actual situation and is not limited.

[0111] Optionally, in conjunction with the above embodiments, the second message further includes a service data unit (SDU), which indicates that the second message does not carry operation data. That is, the SDU in the second message is 0. SDUs can be found in existing technologies and will not be repeated here. Carrying an SDU in the second message enables the read / write device to determine, upon receiving the second message, that the second message does not carry operation data based on the SDU. This avoids the read / write device triggering related processing procedures for operation data, thereby saving processing resources and improving message processing efficiency.

[0112] Optionally, in conjunction with the above embodiments, after the reading and writing device receives the second message from the first AIoT device, the above method may further include: the reading and writing device acquiring a plurality of AIoT devices to be paged, and sending a paging message to the second AIoT device; wherein the plurality of AIoT devices includes the first AIoT device, and the second AIoT device is other AIoT devices among the plurality of AIoT devices besides the first AIoT device.

[0113] The second AIoT device can be at least one AIoT device. The paging message may include the identification information of each AIoT device in the second AIoT device, as detailed in existing technologies, which will not be elaborated here.

[0114] For example, if a reader / writer needs to page AIoT device #a1, AIoT device #a2, and AIoT device #a3, and AIoT device #a2 is the first AIoT device mentioned above, then the reader / writer will exclude (or remove) AIoT device #a2 from the AIoT devices to be paged, that is, the reader / writer will page AIoT device #a1 and AIoT device #a3.

[0115] In this embodiment, after receiving the second message, the read / write device can know (or determine) that the first AIoT device has suffered an unrecoverable failure, and the read / write device can mark the first AIoT device as permanently offline. When the read / write device pages multiple AIoT devices including the first AIoT device, excluding the first AIoT device from these multiple paged AIoT devices allows the paging message not to carry the identifier of the first AIoT device, thereby reducing the communication overhead of the read / write device.

[0116] Optionally, in conjunction with the above embodiments, after the first AIoT device receives the first message from the read / write device, or after the read / write device receives the second message from the first AIoT device, the above method may further include: if the fault type of the first AIoT device is a recoverable fault, the first AIoT device sends a third message to the read / write device, and correspondingly, the read / write device receives the third message from the first AIoT device, wherein the third message includes duration information, which is used to indicate the estimated waiting time for the first AIoT device to prepare the operation data; the read / write device configures a timer according to the waiting time, which is set to trigger the sending of a request message when the waiting time is reached, which is used to request the first AIoT device to report the operation data.

[0117] A recoverable fault can be understood as a fault that the device can recover from itself. In other words, for a recoverable fault, the device can return to normal operation after a period of time following the fault. A recoverable fault in the first AIoT device can be understood as follows: the first AIoT device experiences a fault, and this fault can be recovered by the first AIoT device itself within a certain period (which is estimable). In this case, the first AIoT device is temporarily unable to send operation data to the read / write device; that is, after the first AIoT device recovers from the fault, it can send operation data to the read / write device.

[0118] The duration information can also be used to indicate the waiting time for the read / write device to request operation data from the first AIoT device again. The waiting time is the sum of the fault recovery time and data processing time of the first AIoT device. The data processing time is the time it takes for the first AIoT device to process the acquired data and obtain the operation data after recovering. That is, when the first AIoT device experiences a recoverable fault, it can estimate the fault recovery time (denoted as duration #1) based on the type of fault, and the time it takes to process the data and obtain the operation data after the fault recovery (denoted as duration #2); adding duration #1 and duration #2 gives the waiting time. The waiting time can be represented by the number of time slots, for example, 6 time slots; or it can be represented by a specific time length, for example, 30 milliseconds (ms).

[0119] The timer can be preset in the read / write device. When the read / write device receives duration information, it can configure the timer to count down to the specified waiting time, such as setting the initial value of a countdown timer to the specified waiting time, so that a request message is sent to the first AIoT device when the timer reaches the specified waiting time. Alternatively, when the read / write device receives duration information, it can start counting down from zero, so that a request message is sent to the first AIoT device when the timer reaches the specified waiting time.

[0120] The request message can be found in the relevant description in S203 above, and will not be repeated here.

[0121] In this embodiment, when the fault of the first AIoT device is a recoverable fault, the first AIoT device needs to obtain operation data after the fault is recovered, i.e., the first AIoT device has a delayed response. In this case, the first AIoT device indicates to the read / write device the estimated waiting time for the operation data to be ready. This allows the read / write device to send a request message for requesting operation data to the first AIoT device after the waiting time, meaning that the read / write device no longer periodically sends request messages for requesting operation data to the first AIoT device. This avoids the read / write device frequently sending request messages, thereby reducing the communication overhead of the read / write device and saving communication resources.

[0122] Furthermore, the aforementioned third message may also include an SDU, which indicates that the third message does not carry operation data. That is, the SDU in the third message is 0. Including the SDU in the third message allows the read / write device to determine, upon receiving the third message, that it does not carry operation data based on the SDU within the message. This avoids the read / write device triggering related processing procedures for operation data, thereby saving processing resources and improving message processing efficiency.

[0123] Furthermore, the aforementioned duration information may include category information and timer configuration information.

[0124] The timer configuration information can be used to indicate the estimated time for the first AIoT device to prepare operation data under the duration category indicated by the classification information. That is, the classification information can indicate the duration category, and the timer configuration information can indicate the specific duration under that duration category. In other words, the timing configuration information and classification information can jointly indicate the waiting time. In this embodiment, different duration categories, different durations, and the correspondence between bits can be pre-set in the first AIoT device and the read / write device or pre-defined by the protocol. Furthermore, the number of duration categories and the number of different durations can be flexibly set according to actual conditions without limitation.

[0125] For example, there are two duration categories: duration category #b1 and duration category #b2, represented by bits 0 and 1 respectively. Duration category #b1 includes durations #c1 to #c4, and duration category #b2 includes durations #c5 to #c8. The four durations within these two categories can be represented by bits 00, 01, 10, and 11 respectively. If the classification information is bit 0, indicating duration category #b1, and the timer configuration information is 01, then the timer configuration information indicates duration #c2. This duration #c2 is the aforementioned waiting duration.

[0126] In this embodiment of the application, the duration information is indicated by classification information and timer configuration information. When there are many preset or predefined durations, or when the data of waiting duration is large, the waiting duration can be indicated by fewer bits, thereby reducing the communication overhead of the first AIoT device.

[0127] Furthermore, the aforementioned classification information can be a second fault classification code, which indicates a recoverable fault type. After configuring the timer based on the waiting duration, the method may further include: after the timer reaches the waiting duration, the read / write device sends a seventh message to the first AIoT device, and the first AIoT device receives the seventh message from the read / write device, wherein the seventh message is used to request the first AIoT device to report operation data; if the read / write device does not receive the operation data, it sends the fault type of the first AIoT device to the core network element, and the core network element receives the fault type from the first AIoT device.

[0128] The second fault classification code can indicate the fault type of the first AIoT device, such as the NAS layer of the first AIoT device being processing complex commands and temporarily unable to process operational data; and at this time, the fault type of the first AIoT device is a recoverable fault. This second fault classification code can be represented by bits, for example, the second fault classification code can be 0100, and the specific setting can be determined according to actual conditions without limitation. In the embodiments of this application, different fault classification codes corresponding to different fault types can be predefined in the protocol or pre-set in the first AIoT device and the read / write device.

[0129] The seventh message can have the same structure as the first message, without any restrictions.

[0130] The failure of the read / write device to receive operation data can be understood as follows: after sending the seventh message to the first AIoT device, the read / write device does not receive a message from the first AIoT device within a preset time period; or, the read / write device receives a message from the first AIoT device, but the message does not carry operation data.

[0131] The core network elements can be referred to in the aforementioned introduction, and will not be repeated here.

[0132] In this embodiment, when the read / write device requests operation data from the first AIoT device again (i.e., after the read / write device sends the seventh message) and does not receive the operation data, the read / write device can send the fault type of the first AIoT device to the core network element, so that the core network element can notify the equipment operator to handle the first AIoT device, such as repair or replacement. After receiving the fault type of the first AIoT device from the read / write device, the core network element can send the fault type of the first AIoT device to the equipment operator, or it can send a message to the equipment operator indicating a permanent fault of the first AIoT device. For details, please refer to the foregoing description, which will not be repeated here.

[0133] In addition, if the read / write device does not receive operation data after sending the seventh message, it can also stop sending request messages to the first AIoT device to save communication resources.

[0134] Furthermore, the above-mentioned fault types can be any of the following: insufficient power of the rechargeable device, device waiting to execute commands, or temporary resource conflict.

[0135] The low battery level of a rechargeable device can be understood as: the rechargeable device's circuitry is insufficient. After charging, the NAS layer function can be restored, or the NAS processing can be started after charging.

[0136] The device waiting to execute commands can be understood as the device's NAS layer being processed by other commands, such as security authentication and multi-step data encryption, and is temporarily unable to process data.

[0137] Temporary resource conflicts can be understood as resource contention and conflicts between data units carrying data (such as operational data) and other data units at the media access control (MAC) layer (or physical (PHY) layer). The MAC and PHY layers can be found in existing technologies and will not be elaborated upon here.

[0138] It is understood that the aforementioned terms "insufficient power of rechargeable device," "device waiting to execute command," and "temporary resource conflict" can also be used, and this application does not limit them.

[0139] When recoverable faults include insufficient rechargeable device power, device waiting to execute commands, and temporary resource conflicts, different fault classification codes can be used to represent these faults. For example, fault classification code 0011 can represent insufficient rechargeable device power, fault code 0100 can represent device waiting to execute commands, and fault classification code 0101 can represent temporary resource conflicts.

[0140] In this embodiment of the application, the fault type indicated by the second fault classification code can also be other fault types besides insufficient power of the rechargeable device, device waiting to execute commands, and temporary resource conflicts. The specific type can be set according to the actual situation and is not limited.

[0141] In addition, in this embodiment, a timer can be pre-set in the first AIoT device, and the fault classification code and timer configuration corresponding to different fault types can be pre-defined in the protocol or pre-set in the first AIoT device and the read / write device, as shown in Table 1 below.

[0142] Table 1

[0143]

[0144] In Table 1, the timer configuration code is the timer configuration information mentioned above. For unrecoverable faults (i.e., damage to the data-related modules or insufficient power in non-rechargeable devices), the corresponding timer configuration code is 11. 11 indicates that the reservation is invalid, meaning that the read / write device does not need to start the timer in this case. Fault classification codes 0110-1111 are reserved fault types, meaning that newly added fault types in the future can use these fault classification codes.

[0145] In this embodiment, the second, third, and fifth messages (described below) can all carry a fault type code and a timer configuration code (as shown in Table 1). After receiving these messages, the read / write device can set a timer according to the fault type code and the timer configuration code, and can send the fault classification code carried in the message to the core network element when it is necessary to send the fault of the first AIoT device to the core network element.

[0146] For example, the second message includes fault classification code 0001 and timer configuration code 11. After receiving the second message, the read / write device can, according to the timer configuration code 11, not start the timer, and can send fault classification code 0001 to the core network element.

[0147] For example, the third message includes fault classification code 0101 and timer configuration code 0101. After receiving the third message, the read / write device can set the timer to countdown 100ms according to the fault classification code 0101 and the timer configuration code 0101. The read / write device can also send fault classification code 0101 to the core network element when it needs to send the fault of the first AIoT device to the core network element.

[0148] After the read / write device sends a first message to the first AIoT device (denoted as S301), and the first AIoT device sends a third message to the read / write device based on the first message (denoted as S302), the first AIoT device can assess the fault recovery progress in real time, such as whether the fault has been recovered ahead of schedule or whether the fault has worsened, and promptly inform the read / write device when the fault changes. These will be described in detail below.

[0149] In one possible implementation, such as Figure 3 As shown, after the first AIoT device sends the third message to the read / write device, the method may further include: within the waiting period, and after the fault of the first AIoT device has been resolved, sending a fourth message to the read / write device (denoted as S303a), and correspondingly, the read / write device receives the fourth message from the first AIoT device, wherein the fourth message is used to indicate that the first AIoT device has prepared the operation data; in response to the fourth message, the read / write device stops the timer and sends an eighth message to the first AIoT device (S304a), and correspondingly, the first AIoT device receives the eighth message from the read / write device, wherein the eighth message is used to request the first AIoT device to report the operation data.

[0150] The waiting period can be understood as: the time period during which the first AIoT device sends the third message, starting from the time point when the first AIoT device sends the third message; or, the time period during which the reading / writing device receives the third message, starting from the time point when the reading / writing device receives the third message, continuing to wait.

[0151] The first AIoT device having prepared operational data can be understood as: the first AIoT device has recovered from a fault and has prepared operational data. The first AIoT device's normal recovery from a fault can be understood as: the first AIoT device has recovered from a fault and is currently operating normally. This normal recovery can include the first AIoT device completing charging, NAS command execution, or conflicting resources being released. After the first AIoT device has recovered from a fault, it can acquire operational data.

[0152] The fourth message may include status information. This status information can be used to indicate that the first AIoT device has returned to normal and is ready to operate data; or, the status information can be used to indicate that the first AIoT device is in a normal state and is ready to operate data. This status information can be a status code, such as bit 0000.

[0153] The fourth message may also include an SDU, which indicates that no operation data is carried in the fourth message. That is, the SDU is 0 in the fourth message. This allows the read / write device to determine that no operation data is carried in the fourth message based on the SDU within it. This avoids triggering related processing procedures for operation data, thus saving processing resources and improving message processing efficiency.

[0154] The read / write device can stop the timer by either turning off the timer, resetting the timer to zero, or pausing the timer.

[0155] The eighth message can have the same structure as the first message, without any restrictions.

[0156] In this embodiment, when the first AIoT device recovers from a fault within the waiting period, it can indicate to the read / write device via a fourth message that the first AIoT device is ready to receive operation data. Upon receiving the fourth message, the read / write device can stop the timer and request the operation data from the first AIoT device. That is, the read / write device does not need to wait for the specified waiting period before requesting the operation data; it can request the operation data in advance. This allows the read / write device to obtain the operation data as quickly as possible, thereby improving the timeliness of operation data acquisition.

[0157] Furthermore, after receiving the eighth message from the read / write device, the first AIoT device can send a ninth message (denoted as S305a) to the read / write device. Correspondingly, the read / write device receives the ninth message from the first AIoT device, whereby the ninth message may include operation data. And when the ninth message includes operation data, the SDU carried in the ninth message is not zero.

[0158] In another possible implementation, such as Figure 4 As shown, after the first AIoT device sends the third message to the read / write device, the method may further include: during the waiting period, and if the fault type of the first AIoT device changes from a recoverable fault to an unrecoverable fault, the first AIoT device sends a fifth message to the read / write device (denoted as S303b). Accordingly, the read / write device receives the fifth message from the first AIoT device, wherein the fifth message is used to indicate that the first AIoT device is permanently unable to report operation data; in response to the fifth message, the read / write device stops the timer and stops sending request messages to the first AIoT device (denoted as S304b).

[0159] Please refer to the above-mentioned information during the waiting period; it will not be repeated here.

[0160] The change in the fault type of the first AIoT device from a recoverable fault to an unrecoverable fault can be understood as the fault of the first AIoT device deteriorating, and the fault type of the first AIoT device becoming an unrecoverable fault. For details on unrecoverable faults and the unrecoverable fault type of the first AIoT device, please refer to the relevant description in S202 above, which will not be repeated here.

[0161] The fifth message is similar to the second message; please refer to the relevant description of the second message in S202 for understanding, and it will not be repeated here. The specific implementation of stopping the timer on the read / write device can be found in the above description, and will not be repeated here.

[0162] In this embodiment, when the first AIoT device's failure deteriorates to an unrecoverable state within the waiting time, it can indicate to the read / write device via a fifth message that it is permanently unable to report operation data. In this case, the read / write device stops the timer and stops sending request messages to the first AIoT device; that is, the read / write device no longer sends request messages for requesting operation data to the first AIoT device when the timer expires. This reduces the communication overhead of the read / write device and allows the communication resources allocated to the first AIoT device to be used by other devices, thereby improving overall communication efficiency.

[0163] Furthermore, the fifth message may include a third fault classification code, which indicates that the fault type is an unrecoverable fault; after the above-mentioned read / write device receives the fifth message from the first AIoT device, the above method may further include: the read / write device sending the fault type of the first AIoT device to the core network element (denoted as S305b), or the read / write device sending a tenth message to the core network element according to the fifth message, which is used to indicate a permanent fault of the first AIoT device (denoted as S305b).

[0164] The third fault classification code is similar to the first fault classification code; please refer to the aforementioned introduction to the first fault classification code for a detailed understanding, which will not be repeated here. The tenth message is similar to the sixth message; please refer to the aforementioned introduction to the sixth message for a detailed understanding, which will not be repeated here.

[0165] The above-mentioned fault types can be any of the following: damage to data-related modules, insufficient power of non-rechargeable devices. For details, please refer to the aforementioned introduction, which will not be repeated here.

[0166] In this embodiment, after receiving the third fault classification code, the read / write device can indicate the fault type of the first AIoT device to the core network element based on the third fault classification code; that is, the read / write device can send information indicating the fault type of the first AIoT device to the core network element. Alternatively, after receiving the third fault classification code, the read / write device can indicate a permanent fault of the first AIoT device to the core network element based on the first fault classification code; that is, the read / write device can send information indicating a permanent fault of the first AIoT device to the core network element. This enables the core network element to notify the equipment operator to process the first AIoT device. Furthermore, when the core network element indicates the fault type of the first AIoT device to the equipment operator, the equipment operator can process the first AIoT device based on the fault type, thereby improving the processing efficiency of the first AIoT device by the equipment operator.

[0167] It is understandable that the above-mentioned scheme of the read-write device sending the fault type of the first AIoT device to the core network element according to the third fault classification code or indicating a permanent fault of the first AIoT device to the core network element (denoted as scheme #1) is similar to the aforementioned scheme of the read-write device sending the fault type of the first AIoT device to the core network element according to the first fault classification code or indicating a permanent fault of the first AIoT device to the core network element (denoted as scheme #2). The difference is that the two schemes occur in different scenarios and at different times. Scheme #1 is carried out within the waiting time after the first AIoT device sends the third message to the read-write device, while Scheme #2 is carried out when the first AIoT device sends the second message to the read-write device. The similarities can be understood by referring to each other, and will not be elaborated here.

[0168] It can also be understood that the above content describes the relevant content when the fault of the first AIoT device changes during the waiting period. In this embodiment of the application, if the read / write device does not receive operation data after sending the seventh message, it can stop sending request messages to the first AIoT device. In this case, if the fault of the first AIoT device returns to normal after receiving the seventh message, the first AIoT device can send a message to the read / write device to indicate that the fault of the first AIoT device has returned to normal. After receiving this message, the read / write device can request operation data from the first AIoT device.

[0169] Furthermore, in this embodiment, the message sent by the first AIoT device to the read / write device may also carry a more data indicator (MDI). An MDI of 1 indicates that there are subsequent segments to be transmitted after this frame, while an MDI of 0 indicates that there are no segments after this frame. For example, a second message may include an MDI of 0. Similarly, a third message may include an MDI, which can be either 0 or 1. It is understood that the specific value of the MDI can be set according to actual conditions, and the relevant descriptions of the MDI in the prior art can be referenced, which will not be elaborated upon here.

[0170] The above text combined Figures 2 to 4 This document describes in detail the communication method provided in the embodiments of this application. The following will combine... Figures 5 to 6 The device embodiments of this application are described in detail below. It should be understood that the communication device of this application embodiment can execute the various communication methods of the foregoing embodiments of this application, that is, the specific working processes of the various products below can be referred to the corresponding processes in the foregoing method embodiments.

[0171] In the embodiments described above, the terminal device may execute some or all of the steps in each embodiment; the network device may execute some or all of the steps in each embodiment. These steps or operations are merely examples, and the embodiments of this application may also perform other operations or variations thereof. Furthermore, the steps may be executed in different orders as presented in the embodiments, and it is not necessary to execute all the operations in the embodiments of this application. Moreover, the sequence number of each step 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.

[0172] Figure 5 Schematic diagram of the communication device provided in the embodiments of this application Figure 1 .like Figure 5As shown, the communication device 500 may include a communication module 520. The communication module 520 can implement corresponding communication functions, which can be internal communication functions of the communication device 500 or communication functions between the communication device 500 and other devices. Optionally, the communication module 520 may also be referred to as a communication interface or transceiver module. Optionally, the communication device 500 further includes a processing module 510. The processing module 510 can implement corresponding processing functions.

[0173] Optionally, the communication device 500 further includes a storage module, which can be used to store instructions and / or data; the processing module 510 can read the instructions and / or data in the storage module so that the communication device 500 can implement the aforementioned method embodiments.

[0174] In one possible design, the communication device 500 may correspond to the first AIoT device in the above method embodiments, or to a component (such as a processor, circuit, chip, or chip system) configured in the first AIoT device. The communication device 500 can be used to perform the steps or processes performed by the first AIoT device in any of the above method embodiments.

[0175] For example, the communication module 520 is used to receive a first message from the read / write device. The first message is used to request the first AIoT device to report operation data, which is the data obtained by the first AIoT device after performing a specified operation.

[0176] The communication module 520 is also configured to, in response to the first message, send a second message to the read / write device when the fault type of the first AIoT device is an unrecoverable fault. The second message includes first information, which indicates that the first AIoT device is permanently unable to report operation data.

[0177] The above are merely examples; for detailed steps or procedures, please refer to the descriptions in the foregoing embodiments.

[0178] In one possible design, the communication device 500 may correspond to the read / write device in the above method embodiments, or to a component (such as a processor, circuit, chip, or chip system) configured in the read / write device. The communication device 500 can be used to execute the steps or processes performed by the read / write device in any of the above method embodiments.

[0179] For example, the communication module 520 is used to receive a second message from the first AIoT device when the fault type of the first AIoT device is an unrecoverable fault. The second message includes first information, which is used to indicate that the first AIoT device is permanently unable to report operation data. The operation data is the data obtained by the first AIoT device after performing a specified operation.

[0180] The processing module 510 is used to stop sending request messages to the first AIoT device in response to the second message. The request message is used to request the first AIoT device to report operation data.

[0181] The above are merely examples; for detailed steps or procedures, please refer to the descriptions in the foregoing embodiments.

[0182] Figure 6 Schematic diagram of the communication device provided in the embodiments of this application Figure 2 .like Figure 6 As shown, the communication device 600 can be an AIoT device or a read / write device to implement the above method (i.e. Figure 6 The method described herein includes circuits, chips, chip systems, or processors. The communication device 600 can be used to implement the methods described in the above method embodiments; for details, please refer to the descriptions in the above method embodiments.

[0183] like Figure 6 As shown, the communication device 600 may include one or more processors 610, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 610 may be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, while the central processing unit can be used to control the communication device 600 (e.g., a base station, baseband chip, user, user chip), execute software programs, and process data from the software programs.

[0184] In an alternative design, the processor 610 may also store instructions and / or data that can be executed by the processor 610 to cause the communication device 600 to perform the methods described in the above method embodiments.

[0185] In another alternative design, the communication device 600 may include a communication interface 620 for implementing receiving and transmitting functions. For example, the communication interface 620 may be a transceiver circuit, interface, interface circuit, or transceiver. The transceiver circuit, interface, interface circuit, or transceiver for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, interface circuit, or transceiver may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0186] Optionally, the communication device 600 may include one or more memories 630, which may store instructions that can be executed on the processor 610, causing the communication device 600 to perform the methods described in the above method embodiments. Optionally, the memories 630 may also store data. Optionally, the processor 610 may also store instructions and / or data. The processor 610 and the memories 630 may be provided separately or integrated together.

[0187] It should be understood that, in one possible design, the steps in the method embodiments provided in this application can be implemented by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0188] In one implementation, the communication device 600 may correspond to the AIoT device in the above method embodiments and may be used to execute the various steps and / or processes executed by the AIoT device in the above method embodiments. The processor 610 may be used to execute instructions stored in the memory 630, and when the processor 610 executes the instructions stored in the memory, the processor 610 is used to execute the various steps and / or processes of the above method embodiments corresponding to the AIoT device.

[0189] In another implementation, the communication device 600 may correspond to the read / write device in the above method embodiments, and may be used to execute the various steps and / or processes executed by the read / write device in the above method embodiments. The processor 610 may be used to execute instructions stored in the memory 630, and when the processor 610 executes the instructions stored in the memory, the processor 610 is used to execute the various steps and / or processes of the above method embodiments corresponding to the read / write device.

[0190] It should be understood that the processor 610 described above can be one or more chips. For example, the processor 610 can be a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0191] It is understood that the memory 630 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0192] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0193] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0194] According to the method provided in the embodiments of this application, this application also provides a communication system, which includes the aforementioned AIoT device (i.e., the first AIoT device mentioned above) and a read / write device.

[0195] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes a computer program or instructions that, when the computer program is run, cause the method described in the embodiments of this application to be executed.

[0196] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing a program or instructions, which, when executed, cause the method described in the embodiments of this application to be performed.

[0197] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0198] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0199] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer 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.

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

[0201] It should be understood that in the various embodiments of this application, the sequence number of each process 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.

[0202] In summary, the above description is merely a preferred embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A communication method, characterized in that, The method, applied to an AIoT device in a first-environment Internet of Things (IoT) environment, includes: Receive a first message from the read / write device, the first message being used to request the first AIoT device to report operation data, the operation data being the data obtained by the first AIoT device after performing a specified operation; In the event that the fault type of the first AIoT device is an unrecoverable fault, in response to the first message, a second message is sent to the read / write device so that the read / write device stops sending request messages to the first AIoT device based on the second message; the second message includes first information, which is used to indicate that the first AIoT device is permanently unable to report the operation data, and the request message is used to request the first AIoT device to report the operation data.

2. The method according to claim 1, characterized in that, The first information is a first fault classification code, and the fault type indicated by the first fault classification code is an unrecoverable fault.

3. The method according to claim 1 or 2, characterized in that, The second message also includes a service data unit, which is used to indicate that the operation data is not carried in the second message.

4. The method according to claim 1, characterized in that, After receiving the first message from the read / write device, the method further includes: If the fault type of the first AIoT device is a recoverable fault, a third message is sent to the read / write device. The third message includes duration information, which is used to indicate the estimated waiting time for the first AIoT device to prepare the operation data.

5. The method according to claim 4, characterized in that, The duration information includes classification information and timer configuration information. The timer configuration information is used to indicate the estimated duration for the first AIoT device to prepare the operation data under the duration category indicated by the classification information.

6. The method according to claim 5, characterized in that, The classification information is a second fault classification code, and the fault type indicated by the second fault classification code is a recoverable fault.

7. The method according to claim 4, characterized in that, The third message also includes a service data unit, which is used to indicate that the operation data is not carried in the third message.

8. The method according to any one of claims 4-7, characterized in that, After sending the third message to the read / write device, the method further includes: During the waiting period, and after the first AIoT device recovers from its fault, a fourth message is sent to the read / write device, the fourth message indicating that the first AIoT device has prepared the operation data.

9. The method according to any one of claims 4-7, characterized in that, After sending the third message to the read / write device, the method further includes: During the waiting period, and if the fault type of the first AIoT device changes from the recoverable fault to the unrecoverable fault, a fifth message is sent to the read / write device, the fifth message indicating that the first AIoT device is permanently unable to report the operation data.

10. The method according to claim 9, characterized in that, The fifth message includes a third fault classification code, which indicates an unrecoverable fault type.

11. A communication method, characterized in that, The method for using a read / write device in the Environmental Internet of Things (AIoT) includes: In the case that the failure type of the first AIoT device is an unrecoverable failure, a second message is received from the first AIoT device. The second message includes first information, which is used to indicate that the first AIoT device is permanently unable to report operation data. The operation data is the data obtained by the first AIoT device after performing a specified operation. In response to the second message, the sending of request messages to the first AIoT device is stopped, the request messages being used to request the first AIoT device to report the operation data.

12. The method according to claim 11, characterized in that, The first information is a first fault classification code, and the fault type indicated by the first fault classification code is an unrecoverable fault; The method further includes: Send the fault type of the first AIoT device to the core network element; or... Based on the first information, a sixth message is sent to the core network element, the sixth message being used to indicate a permanent failure of the first AIoT device.

13. The method according to claim 11, characterized in that, The second message also includes a service data unit, which indicates that the operation data is not carried in the second message.

14. The method according to any one of claims 11-13, characterized in that, After receiving the second message from the first AIoT device, the method further includes: Obtain multiple AIoT devices to be paged, wherein the multiple AIoT devices include the first AIoT device; A paging message is sent to a second AIoT device, which is another AIoT device among the plurality of AIoT devices besides the first AIoT device.

15. The method according to claim 11, characterized in that, After receiving the second message from the first AIoT device, the method further includes: In the case that the fault type of the first AIoT device is a recoverable fault, a third message is received from the read / write device. The third message includes duration information, which is used to indicate the estimated waiting time for the first AIoT device to prepare the operation data. Based on the waiting time, a timer is configured, and the timer is set to trigger the sending of a request message when the waiting time is reached. The request message is used to request the first AIoT device to report the operation data.

16. The method according to claim 15, characterized in that, The duration information includes classification information and timer configuration information. The timer configuration information is used to indicate the estimated duration for the first AIoT device to prepare the operation data under the duration category indicated by the classification information.

17. The method according to claim 16, characterized in that, The classification information is a second fault classification code, and the fault type indicated by the second fault classification code is a recoverable fault; After configuring the timer according to the waiting duration, the method further includes: After the timer reaches the waiting time, a seventh message is sent to the first AIoT device, the seventh message being used to request the first AIoT device to report the operation data; If the operation data is not received, the fault type of the first AIoT device is sent to the core network element.

18. The method according to claim 15, characterized in that, The third message also includes a service data unit, which is used to indicate that the operation data is not carried in the third message.

19. The method according to any one of claims 15-18, characterized in that, After receiving a third message from the read / write device, the method further includes: During the waiting period, and after the fault of the first AIoT device is restored to normal, a fourth message is received from the first AIoT device, the fourth message being used to indicate that the first AIoT device has prepared the operation data; In response to the fourth message, the timer is stopped, and an eighth message is sent to the first AIoT device, the eighth message being used to request the first AIoT device to report the operation data.

20. The method according to any one of claims 15-18, characterized in that, After receiving a third message from the read / write device, the method further includes: During the waiting period, and if the fault type of the first AIoT device changes from the recoverable fault to the unrecoverable fault, a fifth message is received from the first AIoT device, the fifth message indicating that the first AIoT device is permanently unable to report the operation data; In response to the fifth message, the timer is stopped, and the sending of the request message to the first AIoT device is stopped.

21. The method according to claim 20, characterized in that, The fifth message includes a third fault classification code, which indicates an unrecoverable fault type; after receiving the fifth message from the first AIoT device, the method further includes: The fault type of the first AIoT device is sent to the core network element.

22. A communication device, characterized in that, The apparatus includes a module for performing the method as described in any one of claims 1 to 21.

23. A communication device, characterized in that, The device includes at least one processor coupled to a memory storing a program or instructions, the processor executing the program or instructions to cause the device to perform the method as described in any one of claims 1 to 21.

24. A chip system, characterized in that, The chip system includes one or more processors, which are configured to retrieve and execute instructions stored in memory, such that the method as described in any one of claims 1 to 21 is performed.

25. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1 to 21.

26. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a communication device, cause the method of any one of claims 1 to 21 to be performed.

Images