Communication method and apparatus

Abstract

A communication method and apparatus, which are used for improving the accuracy of fault location. The method comprises: an AIoT producer determining fault prediction information on the basis of terminal device access information and historical sensing information, and sending the fault prediction information to a first network element, wherein the terminal device access information and the historical sensing information each correspond to a first area range and a first time range. On the basis of the method, an AIoT producer determines predicted fault information on the basis of terminal device access information and historical sensing information, so as to obtain terminal device tracking information regarding an area range, a time range, etc., that have higher fault occurrence probabilities, and sends the predicted fault information to a first network element, such that the first network element can increase the probability of terminal device tracking in a targeted manner, thereby improving the accuracy of fault tracking and thus improving the accuracy of fault location.

Description

A communication method and apparatus

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510125351.3, filed on January 26, 2025, entitled "A Communication Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology

[0004] Ambient power-enabled internet of things (AIoT) refers to low-power IoT devices where terminal devices have no electrical energy storage or only a small amount of electrical energy storage, but the modules storing the electrical energy do not require charging or manual replacement.

[0005] AIoT devices involve data interaction between multiple network elements. However, statistics on current IoT application servers reveal issues such as poor module uptime and significant group failures in AIoT terminal device and network operation and maintenance scenarios. Furthermore, to achieve billions of connections in AIoT network operation and maintenance scenarios, a massive number of terminal devices will be deployed to the market. Therefore, it can be inferred that AIoT business development will inevitably face massive end-to-end troubleshooting, analysis, and diagnosis of IoT services. Thus, improving the accuracy of fault location is of paramount importance. Summary of the Invention

[0006] This application provides a communication method and apparatus to improve the accuracy of fault location.

[0007] Firstly, this application provides a communication method that can be applied to a communication device, which can be an AIoT producer, or a processor, chip, chip system, circuit, or functional module within an AIoT producer. The method may include: determining fault prediction information based on terminal device access information and / or historical sensing information, wherein the terminal device access information and / or the historical sensing information correspond to a first regional range and a first time range; and sending the fault prediction information.

[0008] Based on the aforementioned communication method, AIoT producers can determine predicted fault information by using terminal device access information and / or historical sensing information. This allows them to obtain terminal device tracking information within areas and time ranges where faults are more likely to occur. Sending the predicted fault information to the first network element enables the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0009] In one possible design, the terminal device access information may include one or more of the following: the success rate of the terminal device accessing any network element, the number of accessing terminal devices, key performance indicators (KPIs), interference information, resource utilization, alarm information, or logs. This allows AIoT producers to obtain more accurate fault prediction information based on the terminal device access information.

[0010] In one possible design, the historical sensing information corresponds to sensing requirements, which include one or more of the following: sensing source type, sensing target, or sensing location. This allows AIoT producers to obtain more accurate fault prediction information based on historical sensing information.

[0011] In one possible design, a first request is received, which requests the configuration of fault prediction information within the first regional range and the first time range; the first request includes sensing requirements. This allows AIoT producers to obtain fault prediction information for the first regional range and the first time range, enabling the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location.

[0012] In one possible design, a second request is sent to request terminal device access information within a second regional range and a second time range; the second regional range is included within the first regional range, and the second time range is included within the first time range; and / or, a third request is sent to request historical sensing information within a third regional range and a third time range; the third regional range is included within the first regional range, and the third time range is included within the first time range. This allows AIoT producers to obtain more accurate fault prediction information based on terminal device access information and historical sensing information.

[0013] In one possible design, the method for determining fault prediction information based on terminal device access information and historical sensing information can be: determining the fault prediction information based on a fault prediction model, according to the terminal device access information and / or the historical sensing information. In this way, AIoT producers can determine predicted fault information based on terminal device access information and / or historical sensing information, obtaining terminal device tracking information within areas and time ranges where faults are more likely to occur. Sending the predicted fault information to the first network element allows the first network element to purposefully increase the probability of terminal device tracking, improving the accuracy of fault tracking and fault location.

[0014] In one possible design, the fault prediction information includes one or more of the following: the predicted fault location area, the predicted fault occurrence time, the equipment information of the faulty device, the fault probability, or the fault service type. This allows the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location.

[0015] Secondly, this application provides a communication method that can be applied to a communication device, which can be a first network element, or a processor, chip, chip system, circuit, or functional module within the first network element. The method may include: sending terminal device access information within a second regional range and a second time range; the second regional range being included within a first regional range, and the second time range being included within the first time range; and receiving fault prediction information, the fault prediction information being determined based on the terminal device access information and / or historical sensing information within the first regional range and the first time range.

[0016] Based on the aforementioned communication method, AIoT producers can determine predicted fault information based on terminal device access information. This allows them to obtain terminal device tracking information within areas and time ranges where faults are more likely to occur. Sending the predicted fault information to the first network element enables the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0017] In one possible design, the terminal device access information includes one or more of the following: the success rate of the terminal device accessing any network element, the number of connected terminal devices, key performance indicators (KPIs), interference information, resource utilization, alarm information, or logs. This allows AIoT producers to obtain more accurate fault prediction information based on the terminal device access information.

[0018] In one possible design, a second request is received, which requests terminal device access information within the second regional range and the second time range. This allows AIoT producers to obtain more accurate fault prediction information based on terminal device access information and historical sensing information.

[0019] In one possible design, the fault prediction information includes one or more of the following: the predicted fault location area, the predicted fault occurrence time, the equipment information of the faulty device, the fault probability, or the fault service type. This allows the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location.

[0020] In one possible design, fault monitoring can be performed based on the fault prediction information. This allows the first network element to purposefully increase the probability of tracking the terminal device, improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0021] Thirdly, this application provides a communication method that can be applied to a communication device, which can be an AIoT producer, or a processor, chip, chip system, circuit, or functional module within an AIoT producer. The method may include: receiving first fault prediction information and sending second fault prediction information; wherein the first fault prediction information corresponds to a second regional range and a second time range; the second regional range is included within a first regional range, and the second time range is included within the first time range; the second fault prediction information is determined based on the first fault prediction information, and the second predicted fault information corresponds to the first regional range and the first time range.

[0022] Based on the aforementioned communication method, AIoT producers can determine second predicted fault information based on the first predicted fault information. This allows them to obtain terminal device tracking information within regions and time ranges where faults are more likely to occur. Sending the second predicted fault information to the first network element enables the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0023] In one possible design, either the first fault prediction information or the second fault prediction information includes one or more of the following: the predicted fault location area, the predicted fault occurrence time, the fault-causing device information, the fault probability, or the fault service type. This allows the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location.

[0024] In one possible design, a fourth request is received, which requests the configuration of fault prediction information for the first regional range and the first time range. This allows AIoT producers to obtain second fault prediction information for the first regional range and the first time range, enabling the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location.

[0025] In one possible design, a fifth request is sent to request the first fault prediction information within the second regional range and the second time range. This allows AIoT producers to determine second fault prediction information based on the first fault prediction information.

[0026] In one possible design, the second fault prediction information is determined based on the first fault prediction information, including: the second fault information is determined based on the first fault prediction information and a fault prediction model. In this way, AIoT producers can determine the second fault prediction information based on the first fault prediction information, obtaining terminal device tracking information for areas and time ranges with a higher probability of fault occurrence. Sending the second fault prediction information to the first network element allows the first network element to purposefully increase the probability of terminal device tracking, improving the accuracy of fault tracking and fault location.

[0027] In one possible design, the second fault prediction information is determined based on the first fault prediction information, including: the second fault prediction information is determined based on the first fault prediction information and historical sensing information, wherein the historical sensing information corresponds to the first regional range and the first time range. This allows AIoT producers to obtain more accurate second predicted fault information by combining the first fault prediction information and the historical sensing information.

[0028] In one possible design, the historical sensing information corresponds to sensing requirements, which include one or more of the following: sensing source type, sensing target, or sensing location. This allows AIoT producers to obtain more accurate second-predictive fault information based on historical sensing information.

[0029] In one possible design, a sixth request is sent to request historical sensing information within the third regional range and the third time range; the third regional range is encompassed by the first regional range, and the third time range is encompassed by the historical sensing information received from the second network element within the first time range. This allows AIoT producers to obtain more accurate second predicted fault information based on the final historical sensing information.

[0030] Fourthly, this application provides a communication method that can be applied to a communication device. The communication device can be a first network element, or a processor, chip, chip system, circuit, or functional module within the first network element. The method can include: sending first fault prediction information and receiving second fault prediction information; wherein the first fault prediction information corresponds to a second regional range and a second time range; the second regional range is included within a first regional range, and the second time range is included within the first time range; the second fault prediction information is determined based on the first fault prediction information, and the second predicted fault information corresponds to the first regional range and the first time range.

[0031] Based on the aforementioned communication method, AIoT producers can determine second predicted fault information based on first predicted fault information. This allows them to obtain terminal device tracking information within regions and time ranges where faults are more likely to occur. Sending the second predicted fault information to the first network element enables the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0032] In one possible design, either the first fault prediction information or the second fault prediction information includes one or more of the following: the predicted fault location area, the predicted fault occurrence time, the fault-causing device information, the fault probability, or the fault service type. This allows the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location.

[0033] In one possible design, a fifth request is received, which requests the first fault prediction information within the second regional range and the second time range. This allows AIoT producers to determine second fault prediction information based on the first fault prediction information.

[0034] In one possible design, fault monitoring can be performed based on the second fault prediction information. This allows the first network element to purposefully increase the probability of tracking the terminal device, improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0035] Fifthly, this application also provides a communication device, which can be an AIoT producer or a component (e.g., a processor, chip, chip system, circuit, component, module, or functional module, etc.) within an AIoT producer. This communication device has the functionality to implement the methods described in the first aspect or various possible design examples of the first aspect, or the methods described in the third aspect or various possible design examples of the third aspect. The functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the described functionality.

[0036] In one possible design, the communication device may include a processing unit, and optionally a transceiver unit. These units may perform the functions of the methods described in the first aspect or various possible design examples of the first aspect, or the third aspect or various possible design examples of the third aspect, which will not be elaborated here.

[0037] In one possible design, the communication device includes one or more processors, and optionally also includes a memory and / or a transceiver. The transceiver is used to send and receive data, messages, or information, and to communicate and interact with other devices in the system. The processor is configured to support the communication device in performing the corresponding functions of the first aspect or various possible design examples of the first aspect, or the third aspect or various possible design examples of the third aspect. The memory is coupled to the processor and stores the necessary program instructions and data of the communication device.

[0038] Sixthly, this application also provides a communication device, which may be a first network element or a component within the first network element (e.g., a processor, chip, chip system, circuit, component, module, or functional module, etc.). This communication device has the functionality to implement the methods described in the second aspect or various possible design examples of the second aspect, or the fourth aspect or various possible design examples of the fourth aspect. The functionality can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functionality.

[0039] In one possible design, the communication device may include a processing unit, and optionally a transceiver unit. These units may perform the functions of the methods described in the second aspect or various possible design examples of the second aspect, or the fourth aspect or various possible design examples of the fourth aspect, which will not be elaborated here.

[0040] In one possible design, the communication device includes one or more processors, and optionally also includes a memory and / or a transceiver. The transceiver is used to send and receive data, messages, or information, and to communicate and interact with other devices in the system. The processor is configured to support the communication device in performing the functions described in the second aspect or various possible design examples of the second aspect, or the fourth aspect or various possible design examples of the fourth aspect. The memory is coupled to the processor and stores the necessary program instructions and data for the communication device.

[0041] In a seventh aspect, embodiments of this application provide a communication system that may include an AIoT producer and at least one first network element. The AIoT producer can be used to implement the methods described in the first aspect or various possible design examples of the first aspect; the first network element can be used to implement the methods described in the second aspect or various possible design examples of the second aspect. Alternatively, the AIoT producer can be used to implement the methods described in the third aspect or various possible design examples of the third aspect; the first network element can be used to implement the methods described in the fourth aspect or various possible design examples of the fourth aspect.

[0042] Eighthly, embodiments of this application provide a computer-readable storage medium storing program instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect and any possible design of the embodiments of this application, or in the second aspect and any possible design of the second aspect, or in the third aspect and any possible design of the third aspect, or in the fourth aspect and any possible design of the fourth aspect. Exemplarily, the computer-readable storage medium can be any available medium accessible to a computer. For example, but not limited to, a computer-readable medium can include a non-transient computer-readable medium, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM or other optical disk storage, magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible to a computer.

[0043] Ninthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed on a computer, cause the methods described in the first aspect or any possible design of the first aspect, or in the second aspect or any possible design of the second aspect, or in the third aspect and any possible design of the third aspect, or in the fourth aspect and any possible design of the fourth aspect to be executed.

[0044] In a tenth aspect, this application also provides a chip or chip system, including one or more processors, said processors being coupled to at least one memory for reading and executing program instructions stored in said memory to enable the chip or chip system to implement the methods described in the first aspect or any possible design of the first aspect, or in the second aspect or any possible design of the second aspect, or in the third aspect and any possible design thereof, or in the fourth aspect and any possible design thereof.

[0045] For the various aspects of the fifth to tenth aspects mentioned above, and the technical effects that each aspect may achieve, please refer to the description of the technical effects that can be achieved for the first aspect or the various possible solutions in the first aspect, or the second aspect or the various possible solutions in the second aspect, or the third aspect or the various possible solutions in the third aspect, or the fourth aspect or the various possible solutions in the fourth aspect. It will not be repeated here. Attached Figure Description

[0046] Figure 1 is a schematic diagram of the architecture of a communication system provided in this application;

[0047] Figure 2 is a schematic diagram of the architecture of another communication system provided in this application;

[0048] Figure 3 is a flowchart illustrating a communication method provided in this application;

[0049] Figure 4 is a flowchart illustrating an example of a communication method provided in this application;

[0050] Figure 5 is a flowchart illustrating another communication method provided in this application;

[0051] Figure 6 is a flowchart illustrating an example of another communication method provided in this application;

[0052] Figure 7 is a schematic diagram of the structure of a communication device provided in this application;

[0053] Figure 8 is a structural diagram of a communication device provided in this application. Detailed Implementation

[0054] This application provides a communication method and apparatus to improve the accuracy of fault location. The method and apparatus described in this application are based on the same technical concept. Since the principles by which the method and apparatus solve problems are similar, their implementations can be mutually referenced, and repeated details will not be elaborated further.

[0055] In the description of this application, the terms "first," "second," etc., are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance or order.

[0056] In the description of this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0057] In the description of this application, "and / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. " / " means "or", for example, a / b means a or b.

[0058] To more clearly describe the technical solutions of the embodiments of this application, the communication methods and devices provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0059] For example, Figure 1 illustrates a possible architecture diagram of a communication system applicable to an embodiment of this application. As shown in Figure 1, the communication system 10 may include a radio access network (RAN) 100 and a core network (CN) 200. Optionally, the communication system 10 may also include the Internet 300.

[0060] RAN 100 includes at least one RAN node (110a and 110b in Figure 1, collectively referred to as 110) and at least one terminal device (120a-120j in Figure 1, collectively referred to as 120). RAN 100 may also include other RAN nodes, such as wireless relay devices and / or wireless backhaul devices (not shown in Figure 1). Terminal device 120 is wirelessly connected to RAN node 110. RAN node 110 is wirelessly or wired connected to core network 200. The core network devices in core network 200 and RAN node 110 in RAN 100 can be different physical devices, or they can be the same physical device integrating core network logical functions and wireless access network logical functions.

[0061] RAN 100 can be a 3rd Generation Partnership Project (3GPP) related cellular system, such as a 4th generation (4G) mobile communication system (e.g., Long Term Evolution, LTE), a 5th generation (5G) mobile communication system (e.g., New Radio, NR), or a future-oriented communication system. RAN 100 can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or a WiFi system. RAN 100 can also be a communication system that integrates two or more of the above systems.

[0062] RAN node 110, sometimes referred to as RAN entity or access node, constitutes part of the communication system and assists terminal devices in achieving wireless access. Multiple RAN nodes 110 in communication system 10 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal device 120 are relative. For example, network element 120i in Figure 1 can be a helicopter or drone, which can be configured as a mobile base station. For terminals 120j accessing RAN 100 through network element 120i, network element 120i is a base station; however, for base station 110a, network element 120i is a terminal device. RAN node 110 and terminal device 120 are sometimes both referred to as communication devices. For example, network elements 110a and 110b in Figure 1 can be understood as communication devices with base station functions, and network elements 120a-120j can be understood as communication devices with terminal device functions.

[0063] RAN nodes can also be referred to in different ways, such as network devices. Unless otherwise specified in this application, network devices will be used as the term.

[0064] In one possible scenario, the network device can also be called an access network device. The access network device can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a base station in a future mobile communication system, or an access node in a WiFi system. The access network device can be a macro base station (as shown in Figure 1, 110a), a micro base station or indoor station (as shown in Figure 1, 110b), a relay node or donor node, or a radio controller in a CRAN scenario. Optionally, the access network device can also be a server, wearable device, vehicle, or in-vehicle equipment. For example, the access network device in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the access network device in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform). The access network device in this application can also be a logical node, logical module, or software capable of implementing all or part of the access network device functions.

[0065] In another possible scenario, multiple access network devices collaborate to assist terminal devices in achieving wireless access, with each access network device performing a portion of the base station's functions. For example, the access network devices can be a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU), etc. The CU and DU can be configured separately or included in the same network element, such as a baseband unit (BBU). The RU can be included in radio frequency equipment or radio frequency units, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH).

[0066] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called an open CU (O-CU), DU can also be called an open DU (O-DU), CU-CP can also be called an open CU-CP (O-CU-CP), CU-UP can also be called an open CU-UP (O-CU-UP), and RU can also be called an open RU (O-RU). Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

[0067] Terminal devices can also be called user equipment (UE), mobile stations, mobile terminals, etc. Terminal devices 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), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, etc. Terminal devices can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, etc. For example, terminal devices can be active terminal devices, also known as tags. The terminal devices in the embodiments of this application can also be called ambient Internet of Things (IoT) terminal devices, IoT terminal devices, environmental IoT devices, or IoT devices, etc. The embodiments of this application do not limit the device form of the terminal devices.

[0068] Core network equipment may include core network elements used to serve AIoT devices, such as ambient IoT management function (AIOTMF) network elements, access and mobility management function (AMF) network elements, session management function (SMF) network elements, user plane function (UPF) network elements, etc.

[0069] For example, Figure 2 shows a schematic diagram of the architecture of another communication system to which embodiments of this application are applicable. The architecture includes an AIoT platform, an operation support system (OSS), a RAN, a CN, and a UE.

[0070] Among them, the AIoT platform can be located in a third-party entity (3 rd The OSS (Service OSS) can be understood as the network management plane, which can be network management devices. The network management plane can include AIoT producers and sensing modules. The AIoT producer's function is to receive AIoT-related service requests, process them, obtain results, and feed them back to the requesting party. The sensing module stores sensing data. RAN, UE, and CN report AIoT fault-related data to the management plane.

[0071] Third-party entities and the OSS can communicate via the agent communication interface (ACI)-N or interface R1. The RAN and the AIoT producer can communicate via interface O1, interface A1, or interface O2. The CN and the sensing module can communicate via the ACI-P interface.

[0072] It should be understood that the architecture of the communication system of this application may also include other devices, and this application does not limit this.

[0073] The communication system described in this application is intended to more clearly illustrate the technical solutions of this application and does not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0074] Currently, AIoT devices involve data interaction between multiple network elements. However, statistics on current IoT industry application servers reveal issues such as poor module uptime and significant group failures in AIoT terminal device and network operation and maintenance scenarios. Furthermore, to achieve billions of connections in AIoT network operation and maintenance scenarios, a massive number of terminal devices will be deployed to the market. Therefore, it can be inferred that the development of AIoT businesses will inevitably face massive end-to-end troubleshooting, analysis, and diagnosis of IoT services.

[0075] In troubleshooting AIoT terminal devices, traditional analysis and location methods require the core network to track terminal devices in advance to record their data reporting and signaling message status, enabling the core network to obtain historical information about abnormal terminal devices during troubleshooting. However, current technology achieves fault location through random terminal device tracking. When a faulty terminal device appears, random tracking may fail to capture fault information within the fault's duration, thus impacting troubleshooting efficiency.

[0076] Based on this, embodiments of this application provide a communication method to improve the accuracy of fault location.

[0077] In the following embodiments, the communication method provided in this application is described in detail using a certain device (or network element) as an example. It should be understood that the operation performed by the certain device (or network element) can also be implemented by the processor, chip or chip system, or functional module in the certain device (or network element).

[0078] Based on the above description, an embodiment of this application provides a communication method, as shown in Figure 3. The process of this method may include:

[0079] Step 301: The AIoT producer determines the fault prediction information based on the terminal device access information and / or historical sensing information, which corresponds to the first regional range and the first time range.

[0080] AIoT producers can be understood as functional modules for AIoT troubleshooting, possessing the ability to train terminals to track large models, build knowledge bases and tool libraries, and call relevant tools.

[0081] Among them, the terminal device access information and / or historical sensing information correspond to the first area range and the first time range, and can be understood as the terminal device access information and / or historical sensing information within the first area range and the first time range.

[0082] In some examples, terminal device access information may include one or more of the following: the success rate of terminal device access to any network element, the number of accessing terminal devices, key performance indicators (KPIs), interference information, resource utilization, alarm information, or logs.

[0083] For example, the success rate of a terminal device accessing any network element can be the success rate of the terminal device accessing network equipment, the core network, or the AIoT platform. The KPI can be the service-side KPI of the terminal device accessing network equipment, the core network, or the AIoT platform.

[0084] In some examples, historical sensing information can correspond to sensing needs, which may include one or more of the following: sensing source type, sensing target, or sensing location. It can also be understood that historical sensing information is determined based on sensing needs.

[0085] For example, the sensing source type may include one or more of the following: camera, millimeter-wave radar, etc.

[0086] The sensing targets may include one or more of the following: base stations, traffic flow, environmental information, etc.

[0087] In one alternative implementation, the AIoT producer may receive a first request from the AIoT consumer, the first request being for requesting the configuration of fault prediction information within a first regional range and a first time range.

[0088] The first request can also be described as a terminal device tracking information request, or it can be described in other ways, which are not limited in this application.

[0089] Optionally, the first request may include a first regional range and a first time range. The first time range can be understood as a reference time range, and the first time region can be understood as the maximum tracking region.

[0090] Optionally, the first request may also include a perceived need.

[0091] In one optional implementation, the AIoT producer, based on the first request, uses a fault prediction model to determine the network elements or functional modules that can be invoked within a first area, as well as the sensing modules that can be invoked, and determines the time range and area range corresponding to each network element or functional module and sensing module.

[0092] In some embodiments, the fault prediction model may be trained by the AIoT producer based on historical fault data or other relevant data. The fault prediction model may include a knowledge base and a tool library, or it may be understood that the fault prediction model and the knowledge base exist independently of the tool library; this application does not limit this. The fault prediction model may be described as a terminal device tracking model or other names; this application does not limit this.

[0093] Furthermore, the AIoT producer can send a second request to the first network element. The second request is used to request access information of terminal devices in a second regional range and a second time range. The second regional range is included in the first regional range, and the second time range is included in the first time range.

[0094] The second region being contained within the first region can be understood as either the second region being the same as the first region, or the second region being smaller than the first region. Similarly, the second time range being contained within the first time range can be understood as either the second time range being the same as the first time range, or the second time range being smaller than the first time range.

[0095] It should be understood that the first network element here refers to any one of the network elements or functional modules that can be invoked within the first area. AIoT producers can request terminal device access information within the corresponding area and time range from multiple network elements or functional modules. This application only uses the first network element as an example for illustration.

[0096] Optionally, the network elements that can be invoked within the first area may include one or more of the following: AIoT platform, access network equipment, core network equipment, terminal equipment, etc.

[0097] Optionally, the second request may include a second regional range and a second time range, as well as the requirement information for terminal device access information.

[0098] For example, the access requirements of terminal devices may include requirements for one or more of the following: the success rate of terminal devices accessing any network element, the number of accessing terminal devices, KPIs, interference information, resource utilization, alarm information, or logs.

[0099] Accordingly, the first network element can determine the terminal device access information within the second area and the second time range based on the second request, and send the terminal device access information within the second area and the second time range to the AIoT producer.

[0100] When the first network element sends terminal device access information within the second regional range and the second time range to the AIoT producer, it can send the second regional range, the first time range, and the terminal device access information.

[0101] The process by which the first network element determines the terminal device access information within the second area and the second time range based on the second request can also be understood as the first network element retrieving available tracking information within the second area and the second time range.

[0102] AIoT producers can also send a third request to the second network element. The third request is used to request historical sensing information within a third regional range and a third time range. The third regional range is included within the first regional range, and the third time range is included within the first time range.

[0103] The third region being contained within the first region can be understood as either the third region being the same as the first region, or the third region being smaller than the first region. Similarly, the third time range being contained within the first time range can be understood as either the third time range being the same as the first time range, or the third time range being smaller than the first time range.

[0104] It should be understood that the second network element here is any one of the sensing modules that can be called within the first area. AIoT producers can request historical sensing information within the corresponding area and time range from multiple sensing modules. This application only uses the second network element as an example for illustration.

[0105] Optionally, the third request may include a third regional scope and a third time scope, as well as perception requirements.

[0106] Accordingly, the second network element can determine the corresponding historical sensing information based on the third area range and third time range included in the third request, as well as the sensing requirements, and send the historical sensing information corresponding to the sensing requirements within the third area range and third time range to the AIoT producer.

[0107] When the second network element sends historical sensing information corresponding to sensing needs within a third regional range and a third time range to the AIoT producer, it can send the third regional range, the third time range, the sensing needs, and the historical sensing information.

[0108] In some embodiments, AIoT producers determine fault prediction information based on terminal device access information and / or historical sensing information. The method may be: determining fault prediction information based on a fault prediction model, according to terminal device access information and / or historical sensing information.

[0109] For example, fault prediction information may include one or more of the following: the predicted area range where the fault will occur, the predicted time of the fault occurrence, the equipment information where the fault occurs (such as decive ID), the fault probability, or the fault service type.

[0110] Among them, the failure probability can reflect the likelihood of a failure. For example, the failure probability can include a list of failure probabilities for a certain area and / or a certain time range.

[0111] Fault service types may include one or more of the following: disconnection, latency, etc.

[0112] In some examples, fault prediction information can be a terminal device tracking probability table.

[0113] Optionally, AIoT producers can determine fault prediction information for a first regional range and a first time range based on terminal device access information from multiple network elements and historical sensing information from multiple sensing modules. Here, multiple network elements correspond to different regional ranges and time ranges, and multiple sensing modules correspond to different regional ranges and time ranges.

[0114] Step 302: The AIoT producer sends fault prediction information to the first network element. Accordingly, the first network element receives the fault prediction information.

[0115] In one optional implementation, after receiving the fault prediction information, the first network element can perform fault monitoring based on the fault prediction information.

[0116] The first network element performs fault monitoring based on the fault prediction information, which can also be understood as the first network element tracking or fault tracing based on the fault prediction information.

[0117] In some embodiments, the first network element can perform fault monitoring on terminal devices that conform to the fault service type within the predicted fault area and within the predicted fault time, based on fault prediction information. Alternatively, the first network element can track terminal devices that conform to the fault service type within the predicted fault area and within the predicted fault time, based on fault prediction information.

[0118] Specifically, when the first network element performs fault monitoring on the aforementioned terminal equipment, it can send instruction information to the corresponding terminal equipment, instructing the terminal equipment to report signaling logs, etc. Furthermore, the terminal equipment can report signaling logs, etc., to the first network element, and the first network element analyzes the signaling logs, etc., to determine whether the terminal equipment has malfunctioned.

[0119] The frequency at which the first network element sends the aforementioned indication information to the terminal device is positively correlated with the probability of failure. This can also be understood as a positive correlation between the tracking frequency and the probability of failure.

[0120] Optionally, the signaling log may include signaling records of interactions between the terminal device and other devices (such as other terminal devices, access network devices, or core network devices) during the terminal device's service operation. The first network element can analyze the timing and operations of the terminal device's interactions with other devices based on the signaling records to determine whether the terminal device has malfunctioned.

[0121] When the first network element receives the fault prediction information, it can perform fault monitoring on the terminal equipment in a targeted manner based on the fault prediction information. That is, it can track the terminal equipment with prior knowledge, improve the accuracy of tracking the problematic terminal equipment, and thus improve the accuracy of fault location.

[0122] It should be understood that AIoT producers can send this fault prediction information to multiple network elements.

[0123] Based on the aforementioned communication method, AIoT producers can determine predicted fault information by using terminal device access information and / or historical sensing information. This allows them to obtain terminal device tracking information within areas and time ranges where faults are more likely to occur. Sending the predicted fault information to the first network element enables the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0124] Based on the embodiment shown in Figure 3, the communication method shown in Figure 3 will be described in detail below using the example shown in Figure 4. For example, the process of this example may include:

[0125] Step 401: AIoT producers train a fault prediction model based on historical fault data or other relevant data.

[0126] The fault prediction model can be found in the relevant description in Figure 3, which will not be repeated here.

[0127] Step 402: The AIoT consumer sends a first request to the AIoT producer, the first request being used to request the configuration of fault prediction information within a first regional range and a first time range.

[0128] Specifically, the first request can be referred to in the relevant description in Figure 3, which will not be repeated here.

[0129] Step 403: AIoT producers use fault prediction models to determine the network elements or functional modules that can be called within the first area, as well as the sensing modules that can be called, and determine the time range and area range corresponding to each network element or functional module and sensing module.

[0130] Step 404a: The AIoT producer sends a second request to the first network element. The second request is used to request access information of terminal devices in the second area and the second time range.

[0131] For details, please refer to the relevant descriptions in Figure 3, which will not be repeated here.

[0132] Step 404b: The AIoT producer sends a third request to the second network element. The third request is used to request historical sensing information within a third regional range and a third time range.

[0133] For details, please refer to the relevant descriptions in Figure 3, which will not be repeated here.

[0134] The order of steps 404a and 404b is not limited in this application.

[0135] Step 405a: The first network element determines the terminal device access information within the second area and the second time range based on the second request.

[0136] Step 405b: The second network element determines the corresponding historical sensing information based on the third area range and third time range included in the third request, as well as the sensing requirements.

[0137] The order of steps 405a and 405b is not limited in this application.

[0138] Step 406a: The first network element sends terminal device access information within the second regional range and the second time range to the AIoT producer.

[0139] For details, please refer to the relevant descriptions in Figure 3, which will not be repeated here.

[0140] Step 406b: The second network element sends historical sensing information corresponding to sensing needs within the third regional range and the third time range to the AIoT producer.

[0141] For details, please refer to the relevant descriptions in Figure 3, which will not be repeated here.

[0142] The order of steps 406a and 406b is not limited in this application.

[0143] Step 407: AIoT producers determine fault prediction information based on the fault prediction model, according to the terminal device access information and historical sensing information.

[0144] For details, please refer to the relevant descriptions in Figure 3, which will not be repeated here.

[0145] Step 408: The AIoT producer sends fault prediction information to the first network element.

[0146] Step 409: The first network element performs fault monitoring based on the fault prediction information.

[0147] For details, please refer to the relevant descriptions in Figure 3, which will not be repeated here.

[0148] Based on this example, AIoT producers can determine predicted fault information by using terminal device access information and historical sensing information. This allows them to obtain terminal device tracking information within areas and time ranges where faults are more likely to occur. Sending the predicted fault information to the first network element enables the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location. This method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0149] Furthermore, this application embodiment also provides a communication method, as shown in Figure 5. The process of this method may include:

[0150] Step 501: The first network element sends first fault prediction information, which corresponds to a second regional range and a second time range; the second regional range is included in the first regional range, and the second time range is included in the first time range. Accordingly, the AIoT producer receives the first fault prediction information from the first network element.

[0151] The first fault prediction information corresponds to the second regional range and the second time range, and can be understood as the first fault prediction information within the second regional range and the second time range.

[0152] The second region being contained within the first region can be understood as either the second region being the same as the first region, or the second region being smaller than the first region. Similarly, the second time range being contained within the first time range can be understood as either the second time range being the same as the first time range, or the second time range being smaller than the first time range.

[0153] The first fault prediction information may include one or more of the following: the predicted area range of the fault, the predicted time of the fault, the equipment information of the fault (such as Decive ID), the fault probability, or the fault service type.

[0154] Among them, the failure probability can reflect the likelihood of a failure. For example, the failure probability can include a list of failure probabilities for a certain area and / or a certain time range.

[0155] Fault service types may include one or more of the following: disconnection, latency, etc.

[0156] Optionally, the first fault prediction information may be described as the terminal equipment indicator evaluation result, or the terminal equipment indicator evaluation information, or other descriptions, which are not limited in this application.

[0157] In one alternative implementation, the AIoT producer may receive a fourth request from the AIoT consumer, the fourth request being used to request the configuration of fault prediction information within a first regional range and a first time range.

[0158] The fourth request can also be described as a terminal device tracking information request, or it can be described in other ways, which are not limited in this application.

[0159] Optionally, the fourth request may include a first regional range and a first time range. The first time range can be understood as a reference time range, and the first time region can be understood as the maximum tracking region.

[0160] In one alternative implementation, the AIoT producer, based on the fourth request, uses a fault prediction model to determine the network elements or functional modules that can be invoked within the first area, and determines the time range and area range corresponding to each network element or functional module.

[0161] In some embodiments, the fault prediction model may be trained by the AIoT producer based on historical fault data or other relevant data. The fault prediction model may include a knowledge base and a tool library, or it may be understood that the fault prediction model and the knowledge base exist independently of the tool library; this application does not limit this. The fault prediction model may be described as a terminal device tracking model or other names; this application does not limit this.

[0162] Furthermore, the AIoT producer can send a fifth request to the first network element, which is used to request first fault prediction information within a second regional range and a second time range.

[0163] It should be understood that the first network element here refers to any one of the network elements or functional modules that can be called within the first area. AIoT producers can request terminal device indicator evaluation information within the corresponding area and time range from multiple network elements or functional modules. This application only uses the first network element as an example for illustration.

[0164] Optionally, the network elements that can be invoked within the first area may include one or more of the following: AIoT platform, access network equipment, core network equipment, terminal equipment, etc.

[0165] Optionally, the fifth request may include a second regional range and a second time range.

[0166] In some embodiments, the first network element determines first fault prediction information within a second regional range and a second time range based on a fifth request, and sends the first fault prediction information within the second regional range and the second time range to the AIoT producer. For example, the first network element can obtain corresponding historical KPI records based on the second regional range and the second time range to determine the first fault prediction information.

[0167] Optionally, when the first network element sends the first fault prediction information within the second regional range and the second time range to the AIoT producer, it can send the second regional range, the second time range, and the first fault prediction information.

[0168] Step 502: The AIoT producer sends second fault prediction information to the first network element. The second fault prediction information is determined based on the first fault prediction information, and the second predicted fault information corresponds to the first regional range and the first time range. Accordingly, the first network element receives the second fault prediction information.

[0169] The second fault prediction information corresponds to the first regional range and the first time range, and can be understood as the second fault prediction information within the first regional range and the first time range.

[0170] Optionally, the second fault prediction information may include one or more of the following: the predicted area range of the fault, the predicted time of the fault, the equipment information of the fault, the fault probability, or the fault service type.

[0171] In some examples, the second fault prediction information may be a terminal device tracking probability table.

[0172] Optionally, the AIoT producer can receive terminal device evaluation information (i.e., first fault prediction information) from multiple network elements, and determine second fault prediction information within a first regional range and a first time range based on the terminal device evaluation information from different network elements. The multiple network elements can correspond to different regional ranges and time ranges.

[0173] In some embodiments, AIoT producers can determine second fault prediction information based on first fault prediction information.

[0174] For example, AIoT producers can determine second fault prediction information based on first fault prediction information and fault prediction models.

[0175] In one alternative implementation, the AIoT producer can determine second fault prediction information based on first fault prediction information and historical sensing information, wherein the historical sensing information corresponds to a first regional range and a first time range.

[0176] For example, AIoT producers can determine second fault prediction information based on first fault prediction information, historical sensing information, and fault prediction models.

[0177] In some embodiments, historical sensing information corresponds to sensing requirements, which include one or more of the following: sensing source type, sensing target, or sensing location.

[0178] For example, the sensing source type may include one or more of the following: camera, millimeter-wave radar, etc.

[0179] The sensing targets may include one or more of the following: base stations, traffic flow, environmental information, etc.

[0180] Optionally, the AIoT producer can send a sixth request to the second network element. The sixth request is used to request historical sensing information within a third regional range and a third time range. The third regional range is included within the first regional range, and the third time range is included within the first time range.

[0181] The third region being contained within the first region can be understood as either the third region being the same as the first region, or the third region being smaller than the first region. Similarly, the third time range being contained within the first time range can be understood as either the third time range being the same as the first time range, or the third time range being smaller than the first time range.

[0182] It should be understood that the second network element here can be any of the sensing modules that can be invoked within the first area determined by the AIoT producer according to the fourth request. The AIoT producer can request historical sensing information within the corresponding area and time range from multiple sensing modules. This application only uses the second network element as an example for illustration.

[0183] Optionally, the sixth request may include a third regional scope and a third time scope, as well as perception requirements.

[0184] Accordingly, the second network element can determine the corresponding historical sensing information based on the third regional range and the third time range included in the sixth request, as well as the sensing requirements, and send the historical sensing information corresponding to the sensing requirements within the third regional range and the third time range to the AIoT producer.

[0185] When the second network element sends historical sensing information corresponding to sensing needs within a third regional range and a third time range to the AIoT producer, it can send the third regional range, the third time range, the sensing needs, and the historical sensing information.

[0186] In one optional implementation, after receiving the second fault prediction information, the first network element can perform fault monitoring based on the second fault prediction information.

[0187] The first network element performs fault monitoring based on the second fault prediction information, which can also be understood as the first network element tracking or fault tracing based on the second fault prediction information.

[0188] In some embodiments, the first network element can perform fault monitoring on terminal devices that conform to the fault service type within the predicted fault area and within the predicted fault time, based on the second fault prediction information. Alternatively, the first network element can track terminal devices that conform to the fault service type within the predicted fault area and within the predicted fault time, based on the second fault prediction information.

[0189] Specifically, when the first network element performs fault monitoring on the aforementioned terminal equipment, it can send instruction information to the corresponding terminal equipment, instructing the terminal equipment to report signaling logs, etc. Furthermore, the terminal equipment can report signaling logs, etc., to the first network element, and the first network element analyzes the signaling logs, etc., to determine whether the terminal equipment has malfunctioned.

[0190] The frequency at which the first network element sends the aforementioned indication information to the terminal device is positively correlated with the probability of failure. This can also be understood as a positive correlation between the tracking frequency and the probability of failure.

[0191] Optionally, the signaling log may include signaling records of interactions between the terminal device and other devices (such as other terminal devices, access network devices, or core network devices) during the terminal device's service operation. The first network element can analyze the timing and operations of the terminal device's interactions with other devices based on the signaling records to determine whether the terminal device has malfunctioned.

[0192] In some embodiments, upon receiving the second fault prediction information, the first network element can purposefully monitor the terminal device for faults based on this information. This involves tracking the terminal device using prior knowledge, improving the accuracy of tracking problematic terminal devices, and thus enhancing the accuracy of fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0193] It should be understood that AIoT producers can send this second fault prediction information to multiple network elements.

[0194] Based on the above communication method, AIoT producers can determine second predicted fault information according to first predicted fault information, and obtain terminal device tracking information such as area range and time range with higher probability of fault occurrence. Sending the second predicted fault information to the first network element can enable the first network element to purposefully increase the probability of terminal device tracking, improve the accuracy of fault tracking, and improve the accuracy of fault location.

[0195] Based on the embodiment shown in Figure 5, the communication method shown in Figure 5 will be described in detail below using the example shown in Figure 6. In this example, the first network element may have large model capabilities or be an artificial intelligence (AI) agent. It can obtain terminal device indicator evaluation results from the first network element according to the AIoT producer's request and provide them to the AIoT producer. Exemplarily, the process of this example may include:

[0196] Step 601: AIoT producers train a fault prediction model based on historical fault data or other relevant data.

[0197] The fault prediction model can be found in the relevant description in Figure 5, which will not be repeated here.

[0198] Step 602: The AIoT consumer sends a fourth request to the AIoT producer, which requests the configuration of fault prediction information within a first regional range and a first time range.

[0199] Specifically, the fourth request can be found in the relevant description in Figure 5, which will not be repeated here.

[0200] Step 603: AIoT producers use fault prediction models to determine the network elements or functional modules that can be called within the first area, and determine the time range and area range corresponding to each network element or functional module.

[0201] For details, please refer to the relevant descriptions in Figure 5, which will not be repeated here.

[0202] Step 604: The AIoT producer sends a fifth request to the first network element. The fifth request is used to request first fault prediction information within the second regional range and the second time range.

[0203] For details, please refer to the relevant descriptions in Figure 5, which will not be repeated here.

[0204] Step 605: The first network element obtains the corresponding historical KPI records based on the second regional range and the second time range to determine the first fault prediction information.

[0205] For details, please refer to the relevant descriptions in Figure 5, which will not be repeated here.

[0206] Step 606: The first network element sends the first fault prediction information to the AIoT producer.

[0207] For details, please refer to the relevant descriptions in Figure 5, which will not be repeated here.

[0208] Step 607: AIoT producers can determine second fault prediction information based on the first fault prediction information and the fault prediction model.

[0209] For details, please refer to the relevant descriptions in Figure 5, which will not be repeated here.

[0210] Step 608: The AIoT producer sends the second fault prediction information to the first network element.

[0211] For details, please refer to the relevant descriptions in Figure 5, which will not be repeated here.

[0212] Step 609: The first network element performs fault monitoring based on the second fault prediction information.

[0213] For details, please refer to the relevant descriptions in Figure 5, which will not be repeated here.

[0214] Based on this example, AIoT producers can determine second predicted fault information based on first predicted fault information. This allows them to obtain terminal device tracking information for areas and time ranges with a higher probability of fault occurrence. Sending the second predicted fault information to the first network element enables the first network element to purposefully increase the probability of terminal device tracking, thereby improving the accuracy of fault tracking and fault location. Furthermore, this method also increases the likelihood of obtaining terminal device fault information from the first network element when a terminal device malfunctions.

[0215] Based on the above embodiments, this application also provides a communication device. Referring to FIG7, the communication device 700 may include a transceiver unit 701 and a processing unit 702. The transceiver unit 701 is used for communication by the communication device 700, such as receiving or sending information (signals or data). The processing unit 702 is used for controlling and managing the operation of the communication device 700. The processing unit 702 can also control the steps performed by the transceiver unit 701.

[0216] For example, the communication device 700 may specifically be the AIoT producer, the processor of the AIoT producer, a chip, a chip system, a component, a module, a functional module, etc., as described in the above embodiments. Alternatively, the communication device 700 may specifically be the first network element, the processor of the first network element, a chip, a chip system, a component, a module, a functional module, etc., as described in the above embodiments.

[0217] In one embodiment, when the communication device 700 is used to implement the AIoT producer function in the embodiment shown in FIG3 or FIG4, the processing unit 702 can be used to determine fault prediction information based on terminal device access information and / or historical sensing information, wherein the terminal device access information and / or the historical sensing information correspond to a first regional range and a first time range; the transceiver unit 701 can be used to send the fault prediction information.

[0218] In some examples, the terminal device access information includes one or more of the following: the success rate of the terminal device accessing any network element, the number of accessing terminal devices, key performance indicators (KPIs), interference information, resource utilization rate, alarm information, or logs.

[0219] Optionally, the historical sensing information corresponds to sensing requirements, which include one or more of the following: sensing source type, sensing target, or sensing location.

[0220] In an optional implementation, the transceiver unit 701 may also be used to receive a first request, the first request being used to request the configuration of fault prediction information within the first regional range and the first time range; the first request includes a sensing requirement.

[0221] In some embodiments, the transceiver unit 701 can also be used to send a second request, the second request being used to request terminal device access information within a second regional range and a second time range; the second regional range is included within the first regional range, and the second time range is included within the first time range; and / or

[0222] A third request is sent, the third request being used to request historical sensing information within a third regional range and a third time range; the third regional range is included within the first regional range, and the third time range is included within the first time range.

[0223] Optionally, when determining fault prediction information based on terminal device access information and / or historical perception information, the processing unit 702 may be used to: determine the fault prediction information based on the fault prediction model, according to the terminal device access information and / or the historical perception information.

[0224] For example, the fault prediction information includes one or more of the following: the predicted area range where the fault will occur, the predicted time of the fault occurrence, the equipment information where the fault occurs, the fault probability, or the fault service type.

[0225] In another embodiment, when the communication device 700 is used to implement the function of the first network element in the embodiment shown in FIG3 or FIG4, the transceiver unit 701 can be used to send terminal device access information within a second regional range and a second time range; the second regional range is included in the first regional range, and the second time range is included in the first time range; and to receive fault prediction information, the fault prediction information being determined based on the terminal device access information and historical sensing information within the first regional range and the first time range. The processing unit 702 can be used to control the operation of the transceiver unit 701.

[0226] Optionally, the terminal device access information includes one or more of the following: the access success rate of the terminal device accessing any network element, the number of accessing terminal devices, key performance indicators (KPIs), interference information, resource utilization rate, alarm information, or logs.

[0227] In some embodiments, the transceiver unit 701 can also be used to receive a second request, the second request being used to request terminal device access information within the second regional range and the second time range.

[0228] For example, the fault prediction information includes one or more of the following: the predicted area range where the fault will occur, the predicted time of the fault occurrence, the equipment information where the fault occurs, the fault probability, or the fault service type.

[0229] In one possible approach, the processing unit 702 can also be used to perform fault monitoring based on the fault prediction information.

[0230] In another embodiment, when the communication device 700 is used to implement the AIoT producer function shown in the embodiment of FIG5 or FIG6, the transceiver unit 701 can be used to receive first fault prediction information, the first fault prediction information corresponding to a second regional range and a second time range; the second regional range is included in the first regional range, and the second time range is included in the first time range; and to send second fault prediction information, the second fault prediction information being determined based on the first fault prediction information, the second predicted fault information corresponding to the first regional range and the first time range. The processing unit 702 can be used to control the operation of the transceiver unit 701.

[0231] Optionally, either the first fault prediction information or the second fault prediction information includes one or more of the following: the predicted area range of the fault, the predicted time of the fault, the equipment information of the fault, the fault probability, or the fault service type.

[0232] In an optional implementation, the transceiver unit 701 may also be used to receive a fourth request, the fourth request being used to request the configuration of fault prediction information within the first regional range and the first time range.

[0233] In an optional implementation, the transceiver unit 701 may also be used to send a fifth request, the fifth request being used to request the first fault prediction information within the second regional range and the second time range.

[0234] In some embodiments, the second fault prediction information is determined based on the first fault prediction information, including: the second fault information is determined based on the first fault prediction information and the fault prediction model.

[0235] In some embodiments, the second fault prediction information is determined based on the first fault prediction information, including: the second fault prediction information is determined based on the first fault prediction information and historical sensing information, wherein the historical sensing information corresponds to the first regional range and the first time range.

[0236] Optionally, the historical sensing information corresponds to sensing requirements, which include one or more of the following: sensing source type, sensing target, or sensing location.

[0237] In some possible implementations, the transceiver unit 701 may also be used to send a sixth request, the sixth request being used to request historical sensing information within the third regional range and the third time range; the third regional range being included within the first regional range and the third time range being included within the first time range; and to receive the historical sensing information.

[0238] In another embodiment, when the communication device 700 is used to implement the function of the first network element in the embodiment shown in FIG5 or FIG6, the transceiver unit 701 can be used to send first fault prediction information, the first fault prediction information corresponding to a second regional range and a second time range; the second regional range is included in the first regional range, and the second time range is included in the first time range; and receive second fault prediction information, the second fault prediction information being determined based on the first fault prediction information, the second predicted fault information corresponding to the first regional range and the first time range. The processing unit 702 can be used to control the operation of the transceiver unit 701.

[0239] Optionally, either the first fault prediction information or the second fault prediction information includes one or more of the following: the predicted area range of the fault, the predicted time of the fault, the equipment information of the fault, the fault probability, or the fault service type.

[0240] In an optional implementation, the transceiver unit 701 may also be used to receive a fifth request, the fifth request being used to request the first fault prediction information within the second regional range and the second time range.

[0241] In one possible approach, the processing unit 702 can also be used to perform fault monitoring based on the second fault prediction information.

[0242] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. The functional units in the embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0243] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0244] Based on the above embodiments, this application also provides a communication device. Referring to FIG8, the communication device 800 may include one or more processors 802. Optionally, the communication device 800 may further include one or more transceivers 801. Optionally, the communication device 800 may further include at least one memory 803. The memory 803 may be disposed inside the communication device 800 or outside the communication device 800. The processor 802 may control the transceiver 801 to receive and send information, messages, or data.

[0245] Specifically, the processor 802 may be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP. The processor 802 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0246] The transceiver 801, processor 802, and memory 803 are interconnected. Optionally, the transceiver 801, processor 802, and memory 803 are interconnected via bus 804; bus 804 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 8, but this does not mean that there is only one bus or one type of bus.

[0247] In one optional embodiment, the memory 803 is used to store programs, etc. Specifically, the program may include program code, which includes computer operation instructions. The memory 803 may include RAM, and may also include non-volatile memory, such as one or more disk storage devices. The processor 802 executes the application program stored in the memory 803 to implement the above-mentioned functions, thereby realizing the functions of the communication device 800.

[0248] For example, the communication device 800 can specifically implement the functions of the AIoT producer or the first network element in the above embodiments.

[0249] In one embodiment, when the communication device 800 implements the functions of the AIoT producer in the aforementioned method embodiments, the transceiver 801 can implement the transmit / receive operations performed by the AIoT producer in the aforementioned method embodiments; the processor 802 can implement other operations performed by the AIoT producer in the aforementioned method embodiments besides the transmit / receive operations. Specific details can be found in the relevant descriptions in the above method embodiments, and will not be elaborated upon here.

[0250] In another embodiment, when the communication device 800 implements the functions of the AIoT producer in the aforementioned method embodiments, the processor 802 can implement the operations performed by the AIoT producer in the aforementioned method embodiments. For specific details, please refer to the relevant descriptions in the above method embodiments, which will not be elaborated upon here.

[0251] In another embodiment, when the communication device 800 implements the function of the first network element in the aforementioned method embodiment, the transceiver 801 can implement the transmit / receive operations performed by the first network element in the aforementioned method embodiment; the processor 802 can implement other operations performed by the first network element in the aforementioned method embodiment besides the transmit / receive operations. Specific details can be found in the relevant descriptions in the above method embodiments, and will not be elaborated upon here.

[0252] In yet another embodiment, when the communication device 800 implements the function of the first network element in the aforementioned method embodiment, the processor 802 can implement the operations performed by the first network element in the aforementioned method embodiment. For specific details, please refer to the relevant descriptions in the above method embodiments; they will not be elaborated upon here.

[0253] Based on the above embodiments, this application provides a communication system that may include the AIoT producer and at least one first network element involved in the above embodiments.

[0254] This application provides a communication system that may include the AIoT producer, at least one first network element, and at least one second network element involved in the above embodiments.

[0255] This application also provides a computer-readable storage medium for storing computer programs or instructions. When the computer programs or instructions are executed by a computer, the computer can implement the communication methods provided in the above-described method embodiments.

[0256] This application also provides a computer program product for storing computer programs or instructions. When the computer program or instructions are executed by a computer, the computer can implement the communication method provided in the above-described method embodiments.

[0257] This application also provides a chip or chip system, including logic circuitry, which is used to execute the communication method provided in the above-described method embodiments.

[0258] This application also provides a chip or chip system, including one or more processors, wherein the one or more processors are coupled to at least one memory, for calling a program in the memory to enable the chip or chip system to implement the communication method provided in the above method embodiments.

[0259] This application also provides a chip or chip system coupled to at least one memory, which is used to implement the communication method provided in the above method embodiments.

[0260] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0261] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0262] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0263] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0264] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A communication method characterized by comprising: The method comprises: determining fault prediction information according to terminal device access information and / or historical perception information, the terminal device access information and / or the historical perception information corresponding to a first area range and a first time range; sending the fault prediction information.

2. The method of claim 1, wherein, The terminal device access information comprises one or more of the following: access success rate of terminal device to any network element, number of terminal devices accessed, key performance indicator (KPI), interference information, resource utilization, alarm information or log.

3. The method of claim 1 or 2, wherein, The historical perception information corresponds to a perception requirement, and the perception requirement comprises one or more of the following: perception source type, perception target or perception location.

4. The method according to any one of claims 1 to 3, characterized in that, The method further comprises: receiving a first request for requesting fault prediction information in the first area range and the first time range; and the first request comprising a perception requirement.

5. The method according to any one of claims 1 to 4, characterized in that, The method further comprises: sending a second request for requesting terminal device access information in a second area range and a second time range; the second area range being contained in the first area range, and the second time range being contained in the first time range; and / or sending a third request for requesting historical perception information in a third area range and a third time range; the third area range being contained in the first area range, and the third time range being contained in the first time range.

6. The method according to any one of claims 1 to 5, wherein, The determining of the fault prediction information according to the terminal device access information and / or the historical perception information comprises: determining the fault prediction information according to the terminal device access information and / or the historical perception information based on a fault prediction model.

7. The method according to any one of claims 1 to 6, wherein The fault prediction information comprises one or more of the following: predicted area range of fault occurrence, predicted time of fault occurrence, device information of fault occurrence, fault probability or fault service type.

8. A communication method characterized by comprising: The method comprises: sending terminal device access information in a second area range and a second time range; the second area range is contained in a first area range, and the second time range is contained in a first time range; receiving fault prediction information determined according to terminal device access information and / or historical perception information in the first area range and the first time range.

9. The method of claim 8, wherein, The terminal device access information comprises one or more of the following: access success rate of terminal devices to any network element, number of terminal devices accessed, key performance indicator (KPI), interference, resource utilization, alarm information or log.

10. The method of claim 8 or 9, wherein, The method further comprises: receiving a second request for requesting terminal device access information in the second area range and the second time range.

11. The method according to any one of claims 8 to 10, wherein, The fault prediction information comprises one or more of the following: predicted area range of fault occurrence; predicted time of fault occurrence; device information of fault occurrence; fault probability; or fault service type.

12. The method according to any one of claims 8 to 11, characterized in that, The method further comprises: performing fault monitoring according to the fault prediction information.

13. A method of communication, comprising: The method comprises: receiving first fault prediction information corresponding to a second area range and a second time range; the second area range being contained in a first area range, and the second time range being contained in a first time range; sending second fault prediction information, the second fault prediction information being determined based on the first fault prediction information, the second fault prediction information corresponding to the first area range and the first time range.

14. The method of claim 13, wherein, Any one of the first fault prediction information and the second fault prediction information comprises one or more of a predicted area range where a fault occurs, a predicted time when a fault occurs, device information where a fault occurs, a fault probability, or a fault service type.

15. The method of claim 13 or 14, wherein, The method further comprises: receiving a fourth request, the fourth request being used to request configuration of fault prediction information in the first area range and the first time range.

16. The method according to any one of claims 13 to 15, wherein, The method further comprises: sending a fifth request, the fifth request being used to request the first fault prediction information in the second area range and the second time range.

17. The method of any one of claims 13-16, wherein, The second fault prediction information is determined based on the first fault prediction information, comprising: The second fault information is determined based on the first fault prediction information and a fault prediction model.

18. The method of any one of claims 13-17, wherein, The second fault prediction information is determined based on the first fault prediction information, comprising: The second fault prediction information is determined based on the first fault prediction information and historical perception information, the historical perception information corresponding to the first area range and the first time range.

19. The method of claim 18, wherein, The historical perception information corresponds to a perception requirement, the perception requirement comprising one or more of a perception source type, a perception target, or a perception location.

20. The method of claim 18 or 19, wherein, The method further comprises: sending a sixth request, the sixth request being used to request historical perception information in a third area range and a third time range; the third area range being contained in the first area range, the third time range being contained in the first time range; receiving the historical perception information.

21. A method of communication, comprising: comprising: sending first fault prediction information, the first fault prediction information corresponding to a second area range and a second time range; the second area range being contained in the first area range, the second time range being contained in the first time range; receiving second fault prediction information, the second fault prediction information being determined based on the first fault prediction information; the second fault prediction information corresponding to the first area range and the first time range.

22. The method of claim 21, wherein, Any one the first fault prediction information and the second fault prediction information comprises one or more of a predicted area where a fault occurs, a predicted time when a fault occurs, device information where a fault occurs; a fault probability, or a fault service type.

23. The method of claim 21 or 22, wherein, The method further comprises: receiving a fifth request, the fifth request being used to request the first fault prediction information in the second range and the second time range.

24. The method of any one of claims 21-23, wherein, The method further comprises: performing fault monitoring according to the second fault prediction information.

25. A communications device, characterized by comprising a module or unit for performing the method of any one of claims 1-7, or comprising a module or unit for performing the method of any one of claims 8-12, or comprising a module or unit for performing the method of any one of claims 13-20, or comprising a module or unit for performing the method of any one of claims 21-24.

26. A communications device, characterized by A computer readable storage medium having stored therein computer executable instructions which, when invoked by the computer, cause the method of any of claims 1-7 to be performed, or the method of any of claims 8-12 to be performed, or the method of any of claims 13-20 to be performed, or the method of any of claims 21-24 to be performed.

27. A computer readable storage medium, characterized in that, A computer readable storage medium having stored therein computer executable instructions which, when invoked by the computer,cause the method of any of claims 1-7 to be performed, or the method of anyof claims 8-12 to be performed, or the method of any of claims 13- 20 to be performed, or the method of any of claims 21-24 to be performed. A computer program product comprising instructions which, when run on a computer, cause the method of any of claims 1-7 to be performed, or themethod of any of claims 8-12 to be performed, or the method of any of claims13-20 to be performed, or the method of any of claims 21-24 tobe performed.

28. A computer program product, characterised in that, ​

Images