Communication method and related apparatus

Abstract

The present application relates to the technical field of wireless communications, and particularly relates to a communication method and a related apparatus. The method comprises: when an unexpected failure occurs during a first service procedure, a first network element determining a second network element, wherein the second network element is a standby network element of the first network element, and the cause of the unexpected failure does not comprise a protocol-specified exception or a custom exception; and the first network element migrating the first service procedure to the second network element, so as to indicate that a procedure subsequent to the first service procedure is initiated by means of the second network element. By means of the method provided in the present application, the service delay of a first service procedure can be reduced.

Description

A communication method and related apparatus

[0001] This application claims priority to Chinese Patent Application No. 202510112579.9, filed on January 23, 2025, entitled “A Communication Method and Related Device”, the entire contents of which are incorporated herein by reference. Technical Field

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

[0003] Service processes initiated by terminal devices may utilize certain functional network elements in the core network. For example, processes such as terminal device registration, establishment of protocol data units (PDUs) initiated by terminal devices, or handover of serving cells by terminal devices may utilize access and mobility management function (AMF) network elements and session management function (SMF) network elements in the core network.

[0004] To ensure the reliable implementation of business processes, existing technologies propose disaster recovery networking schemes for the core network. When a business process fails, if an anomaly detection mechanism such as a heartbeat message detection mechanism or a link detection mechanism detects an anomaly in the business path corresponding to the business process, the disaster recovery networking scheme can be used to re-initiate the business process on a backup business path to achieve failure recovery. It should be understood that, in the embodiments of this application, the business path of the business process may include the network elements and communication links used in the implementation of the business process, and anomalies in the business path include anomalies in the network elements and / or anomalies in the communication links within the business path. However, there may also be anomalies on the business path that existing anomaly detection mechanisms cannot detect. Therefore, based on the existing failure recovery process, the business process will be re-initiated on the business path with such anomalies, which will lead to continuous failure of the business process and affect the user experience of the terminal device. Summary of the Invention

[0005] To address the aforementioned problems, this application provides a communication method and related apparatus. Using the communication method provided in this application can prevent continuous failures of business processes caused by anomalies that existing anomaly detection mechanisms cannot detect, thereby reducing business latency and improving the user experience of terminal devices.

[0006] Firstly, this application provides a communication method. This method can be executed by a first network element or by a component of the first network element (e.g., a processor, chip, or chip system). It should be understood that the first network element can be a network element in the core network and is associated with a first service process.

[0007] The method may include: in the event of an unexpected failure in the first service process, the first network element determines a second network element. The second network element is a backup network element for the first network element, and the cause of the unexpected failure does not include protocol-defined exceptions or custom exceptions. The first network element migrates the first service process to the second network element, instructing subsequent processes of the first service process to be initiated through the second network element.

[0008] It should be understood that, in the embodiments of this application, unexpected failure can also be understood as failure caused by unexpected exceptions. Unexpected exceptions refer to exceptions other than those specified in the protocol and custom exceptions.

[0009] In the above implementation, when the first service process fails and the cause of failure does not include exceptions specified in the protocol or custom exceptions, the first network element will migrate the first service process to a backup second network element, instructing subsequent processes of the first service process to be initiated through the second network element. This method prevents the first service process from being repeatedly initiated on the first network element where an unexpected failure has already occurred, thus avoiding continuous failures of the first service process, reducing service latency, and improving the user experience of terminal devices.

[0010] In conjunction with the first aspect, in one possible implementation, the first network element will migrate the first service process to the second network element, which may include: if the service failure recovery of the first network element is in the redirection mode, the first network element sends a first request message to the second network element. The first request message is used to provide the second network element with the already generated session information corresponding to the first service process, and the already generated session information is used for the failure recovery of the first service process.

[0011] Optionally, the first network element receives a first response message from the second network element corresponding to the first request message. The first response message indicates that the first request message was correctly received.

[0012] In the above implementation, when a service failure is recovered via redirection, the first network element can provide the second network element with the already generated session information corresponding to the first service process, facilitating the migration of the first service process to the second network element. This method is simple and easy to implement, ensuring not only the efficiency of the first service process's failure recovery but also making the communication method provided in this application applicable to scenarios where service failure is recovered via redirection.

[0013] In conjunction with the first aspect, in one possible implementation, the first request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, the terminal device context information of the first service process, or first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to unexpected failure.

[0014] In conjunction with the first aspect, in one possible implementation, the first network element migrates the first service process to the second network element, including: when the service of the first network element fails and recovers to the rerouting mode, the first network element sends a second request message to the network device to migrate the first service process to the second network element, wherein the second request message is used to instruct the network device to reroute the first service process to the second network element.

[0015] In the above implementation, when a service failure is recovered to a rerouting mode, the first network element can instruct the network device to reroute the first service process to the second network element, thereby facilitating the migration of the first service process to the second network element. This method is simple and easy to implement, ensuring not only the efficiency of the first service process's failure recovery but also making the communication method provided in this application applicable to scenarios where service failure is recovered to a rerouting mode.

[0016] In conjunction with the first aspect, in one possible implementation, the second request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, and identification information of the second network element.

[0017] In conjunction with the first aspect, in one possible implementation, when the first network element sends a first request message or a second request message, the aforementioned first service process can be the initial registration process of the terminal device. In this case, the aforementioned first network element can be the access and mobility management function network element that the terminal device connects to before the first service process fails unexpectedly, and the second network element is the backup access and mobility management function network element for the first network element.

[0018] In conjunction with the first aspect, in one possible implementation, migrating the first service process to the second network element includes: the first network element sending a third request message to the second network element to migrate the first service process to the second network element. The third request message is used to instruct the second network element to reconstruct the session information of the first service process.

[0019] In the above implementation, the first network element can directly instruct the second network element to reconstruct the session information of the first service process through a third request message, thereby realizing the migration of the first service process to the second network element. This method is simple and easy to implement, and can guarantee the efficiency of failure recovery of the first service process.

[0020] In conjunction with the first aspect, in one possible implementation, the third request message includes: identification information of the network device, identification information of the next-generation application protocol corresponding to the terminal device initiating the first service process, or first information. The first information is used to indicate that the first service process, due to unexpected failure, is migrated from the first network element to the second network element.

[0021] Optionally, the identification information of the network device can be the globally unified radio access network identifier of the network device associated with the first service process. The next-generation application protocol identifier information corresponding to the terminal device can be the next-generation radio access network application protocol identifier (i.e., NG-RAN application protocol ID, abbreviated as NGAP ID) of the terminal device.

[0022] In conjunction with the first aspect, in one possible implementation, when the first network element sends a third request message, the aforementioned first service process can be a protocol data unit session establishment process or a serving cell handover process. In this case, the aforementioned first network element can be an access and mobility management function network element that the terminal device connected to before the unexpected failure of the first service process, and the second network element is a backup access and mobility management function network element for the first network element.

[0023] In conjunction with the first aspect, in one possible implementation, the method may further include: obtaining a failure cause value in the event of a failure of the first business process. If, based on the failure cause value, it is determined that the cause of the failure of the first business process does not include exceptions specified in the protocol or custom exceptions, the failure of the first business process is determined to be an unexpected failure.

[0024] Secondly, this application provides a communication method. This method can be executed by a second network element or by a component of the second network element (e.g., a processor, chip, or chip system). It should be understood that the second network element is a backup network element for the first network element, and the first network element is a network element in the core network and is associated with the first service process.

[0025] The method includes: if a first service process experiences an unexpected failure on a first network element and is migrated from the first network element to a second network element, and if the first service process fails again on the second network element, the second network element determines whether the second failure is an unexpected failure. The cause of this unexpected failure does not include protocol-defined exceptions or custom exceptions. If the second network element determines that the second failure is an unexpected failure, and if the first time interval between the two unexpected failures of the first service process on the first and second network elements is less than or equal to a time interval threshold, the second network element will not migrate the first service process back to the first network element.

[0026] It should be understood that, in the embodiments of this application, unexpected failure can also be understood as failure caused by unexpected anomalies. Unexpected anomalies refer to anomalies other than those specified in the protocol and custom anomalies. Optionally, in the embodiments of this application, unexpected anomalies include, but are not limited to: internal logic processing anomalies of network elements, application software defects, transmission packet loss, and probabilistic processing failures of the communication system.

[0027] In the above implementation, if the first service process experiences unexpected failures at both the first and second network elements, and the time interval between the two unexpected failures is less than or equal to a time interval threshold, the second network element will not migrate the first service process back to the first network element. In the event that the anomaly at the first network element has not been recovered, this scheme can avoid the continuous failure of the first service process caused by switching back and forth between the first and second network elements (which can also be understood as ping-pong switching), thus avoiding the additional load that ping-pong switching brings to the first and second network elements.

[0028] In conjunction with the second aspect, in one possible implementation, the method may further include: migrating the first service process to the first network element if the first time interval is greater than a time interval threshold.

[0029] In the above implementation, if the time interval between two unexpected failures is greater than the time interval threshold, the first service process can be migrated back to the first network element. This can avoid the situation where the first network element has recovered but the first service process has not been switched back, thus improving the flexibility and practicality of the communication method provided in this application.

[0030] In conjunction with the second aspect, in one possible implementation, the method further includes: the second network element receiving a first request message from the first network element. The first request message is used to provide the second network element with already generated session information corresponding to the first service process, thereby enabling the migration of the first service process to the second network element. The already generated session information is used for failure recovery of the first service process. In this case, the aforementioned first time interval is the time interval between the first moment of receiving the first request message and the second moment when an unexpected failure occurs again on the second network element.

[0031] In the above implementation, the first time interval is set as the difference between the time when the first request message used by the first business process to migrate to the second network element is received and the time when the unexpected failure occurs again on the second network element. The solution is simple and easy to implement, and can ensure the efficiency of the failure recovery of the first business process.

[0032] In conjunction with the second aspect, in one possible implementation, the first request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, the terminal device context information of the first service process, or first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to unexpected failure.

[0033] In conjunction with the second aspect, in one possible implementation, the method further includes: the second network element receiving a third request message from the first network element to migrate the first service process to the second network element, wherein the third request message is used to instruct the second network element to rebuild the session information of the first service process. In this case, the first time interval is the time interval between the third moment of receiving the third request message and the second moment when the unexpected failure occurs again on the second network element.

[0034] In the above implementation, the first time interval is set as the difference between the time when the third request message used by the first business process to migrate to the second network element is received and the time when the unexpected failure occurs again on the second network element. The solution is simple and easy to implement, and can ensure the efficiency of the failure recovery of the first business process.

[0035] In conjunction with the second aspect, in one possible implementation, the third request message includes: identification information of the network device, identification information of the next-generation application protocol corresponding to the terminal device initiating the first service process, or first information. The first information is used to indicate that the first service process, due to unexpected failure, is migrated from the first network element to the second network element.

[0036] Thirdly, this application provides a communication method. This method can be executed by a third network element, or by a component of the third network element (e.g., a processor, chip, or chip system). It should be understood that the third network element can be a network element within the core network.

[0037] The method includes: a third network element determining that a first service request initiated to a fourth network element has unexpectedly failed. The reasons for the unexpected failure do not include protocol-defined exceptions or custom exceptions. The third network element adjusts the number of service requests initiated to the fourth network element based on the service request success rate between the third and fourth network elements. The number of service requests initiated to the fourth network element is positively correlated with the service request success rate.

[0038] Here, the unexpected failure of the first service request initiated to the fourth network element can also be understood as an unexpected anomaly in the service path between the third and fourth network elements, or an unexpected anomaly in the communication link between the fourth network element or the third and fourth network elements. Unexpected anomalies refer to any anomalies other than those specified in the protocol and custom anomalies.

[0039] In the above implementation, when the first service request initiated to the fourth network element fails unexpectedly, the third network element dynamically adjusts the number of service requests initiated to the fourth network element based on the success rate of service requests between the third and fourth network elements. This ensures that the number of service requests initiated to the fourth network element is positively correlated with the success rate of service requests, meaning that a high success rate results in more service requests being initiated, and a low success rate results in fewer service requests being initiated. This reduces the impact of unexpected anomalies on the service path between the third and fourth network elements on service requests initiated by the third network element to the fourth network element, thereby improving the success rate of service requests.

[0040] In conjunction with the third aspect, in one possible implementation, the third network element adjusts the number of service requests initiated to the fourth network element based on the success rate of service requests between the fourth network element and the third network element. This includes: when the success rate of service requests between the fourth network element and the third network element is less than a first success rate threshold but greater than a second success rate threshold, the third network element adjusts the number of service requests initiated to the fourth network element based on the positive correlation between the success rates of service requests.

[0041] In the above implementation, only when the success rate of service requests between the fourth network element and the third network element is less than the first success rate threshold but greater than the second success rate threshold, the number of service requests initiated to the fourth network element is adjusted according to the positive correlation of the service request success rate. This ensures that the number of service requests initiated to the fourth network element is not too small, thus guaranteeing the effective use of the service path between the fourth network element and the third network element.

[0042] In conjunction with the third aspect, in one possible implementation, the third network element adjusts the number of service requests it initiates to the fourth network element based on a positive correlation with the success rate of service requests, including:

[0043] When the success rate of service requests decreases from the first success rate threshold to the second success rate threshold, the number of service requests initiated to the fourth network element is reduced. When the success rate of service requests increases from the second success rate threshold to the first success rate threshold, the number of service requests initiated to the fourth network element is increased.

[0044] In conjunction with the third aspect, in one possible implementation, the number of service requests initiated to the fourth network element is adjusted based on the success rate of service requests between the fourth network element and the third network element. This includes: if the success rate of service requests between the fourth network element and the third network element is less than a second success rate threshold, the third network element adjusts the number of service requests initiated to the fourth network element to the minimum number of service requests.

[0045] In the above implementation, when the success rate of business requests between the fourth network element and the third network element is less than the second success rate threshold, it indicates that there is a significant problem with the business path between the fourth network element and the third network element. In this case, only the minimum number of business requests is guaranteed, which can minimize the impact of unexpected anomalies on business requests.

[0046] In conjunction with the third aspect, in one possible implementation, the number of service requests initiated to the fourth network element is adjusted based on the success rate of service requests between the fourth network element and the third network element. This includes: when the success rate of service requests between the fourth network element and the third network element is equal to or greater than the first success rate threshold, the number of service requests initiated to the fourth network element is not limited.

[0047] In the above implementation, when the success rate of service requests between the fourth network element and the third network element is greater than the first success rate threshold, it indicates that the reliability of the service path between the fourth network element and the third network element is high. At this time, the number of service requests initiated to the fourth network element is not limited, which can ensure the utilization rate of the service path.

[0048] In conjunction with the third aspect, in one possible implementation, the method further includes: when the success rate of the service request between the fourth network element and the third network element changes from being greater than the first success rate threshold to being less than the first success rate threshold, the third network element sends second information to the operation and maintenance center, wherein the second information is used to indicate that there is an anomaly in the service path between the fourth network element and the third network element.

[0049] In conjunction with the third aspect, in one possible implementation, the method further includes: when the success rate of service requests between the fourth network element and the third network element changes from being less than a first success rate threshold to being greater than or equal to the first success rate threshold, the third network element sends third information to the operation and maintenance center. This third information is used to indicate that the service path between the fourth network element and the third network element has returned to normal.

[0050] In the above implementation, the third network element can report the actual status of the service path between the fourth network element and the third network element to the operation and maintenance center based on the success rate of service requests, which facilitates resource scheduling of the communication system.

[0051] In conjunction with the third aspect, in one possible implementation, the method further includes: the third network element sending a second service request to the fifth network element, wherein the second service request is a service request that was reduced during the process of adjusting the number of service requests initiated to the fourth network element.

[0052] Fourthly, this application provides a communication device comprising modules or units for performing the communication method provided by any one of the first to third aspects or any possible implementation thereof.

[0053] Fifthly, this application provides a computer program product including instructions that, when executed on a computer, cause the computer to perform the communication method provided by any one of the first to third aspects or any possible implementation thereof.

[0054] Sixthly, this application provides a computer-readable storage medium storing a computer program that, when executed, performs the communication method provided by any one of the first to third aspects or any possible implementation thereof.

[0055] In a seventh aspect, this application provides a communication device, at least one processor, and a memory. The memory is used to store a computer program. The processor is used to execute the computer program stored in the memory, causing the communication device to perform the communication method provided by any one of the first to third aspects or any possible implementation thereof.

[0056] Optionally, the memory may be integrated with the processor, or the memory may be separated from the processor.

[0057] It should be understood that related data interaction processes, such as sending information, can be seen as the process of outputting information from the processor, and receiving information can be seen as the process of the processor receiving information. Specifically, the data output by the processor can be sent to the transmitter, and the input data received by the processor can come from the receiver. The transmitter and receiver can be collectively referred to as a transceiver.

[0058] Eighthly, this application provides a chip that includes at least a processor. The processor executes computer execution instructions to cause a device on which the chip is mounted to perform the communication method provided by any one of the first to third aspects or any possible implementation thereof.

[0059] In conjunction with aspect eight, in one possible implementation, the chip may also include interface circuitry. This interface circuitry is used to receive computer execution instructions and transmit them to the processor.

[0060] Ninthly, this application provides a communication system. The communication system may include the terminal device, the first network element, and the second network element described above. The terminal device is used to initiate the first service process described above, the first network element is used to execute the communication method provided by the first aspect or any possible implementation thereof, and the second network element is used to execute the communication method provided by the second aspect or any possible implementation thereof.

[0061] Tenthly, this application provides a communication system. This communication system may include the third network element and the fourth network element described above. The third network element is used to execute the communication method provided by the third aspect or any possible implementation thereof, and the fourth network element is used to process service requests sent by the third network element. Attached Figure Description

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

[0063] Figure 2 is a schematic diagram of a communication scenario provided in this application;

[0064] Figure 3 is a schematic diagram of another communication scenario provided in this application;

[0065] Figure 4 is a flowchart of a communication method provided in this application;

[0066] Figure 5 is a schematic diagram of another communication method provided in this application;

[0067] Figure 6 is a schematic diagram of another communication method provided in this application;

[0068] Figure 7 is a schematic diagram of a failure recovery process for an initial registration process provided in this application;

[0069] Figure 8 is a schematic diagram of a PDU session establishment process failure recovery provided in this application;

[0070] Figure 9 is a flowchart illustrating another communication method provided in this application;

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

[0072] Figure 11 is a structural schematic diagram of another communication device provided in this application;

[0073] Figure 12 is a structural schematic diagram of another communication device provided in this application. Detailed Implementation

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

[0075] It should be understood that the technical solutions provided in this application can be applied to various communication systems, such as: Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication systems, 5th Generation (5G) systems, or New Radio (NR). In addition, they can also be applied to subsequent evolution systems, such as 6th Generation communication systems, or even more advanced 7th Generation communication systems.

[0076] The following will exemplarily illustrate the communication system to which the technical solutions provided in this application are applicable.

[0077] Please refer to Figure 1, which is a schematic diagram of the architecture of a communication system provided in this application. The communication method provided in this application is applicable to this communication system. As shown in Figure 1, the communication system may include a radio access network (RAN) 100 and a core network (CN) 130. RAN 100 includes at least one RAN node (110a and 110b in Figure 1) and at least one terminal (120a-120j in Figure 1). RAN 100 may also include other RAN nodes, such as wireless relay devices and / or wireless backhaul devices (not shown in Figure 1). The terminal is connected to the RAN node wirelessly. The RAN node is connected to the core network 130 wirelessly or via a wired connection. The core network equipment in the core network 130 and the RAN node in the RAN 100 may be different physical devices, or they may be the same physical device integrating core network logical functions and radio access network logical functions.

[0078] RAN 100 can be a cellular system related to the 3rd Generation Partnership Project (3GPP), such as a 5G mobile communication system or a future-oriented evolution system. RAN 100 can also be an open access network (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system. RAN 100 can also be a communication system that integrates two or more of the above systems.

[0079] In the communication system shown in Figure 1, RAN nodes, sometimes also referred to as access network devices, network equipment, RAN entities, or access nodes, constitute part of the communication system and are used to help terminals achieve wireless access. Multiple RAN nodes in the communication system can be of the same type or different types. In some scenarios, the roles of RAN nodes and terminals 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. RAN nodes and terminals 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, while network elements 120a-120j can be understood as communication devices with terminal functions.

[0080] In one possible scenario, the RAN node can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a base station in a future mobile communication system, or an access node in a WiFi system. The RAN node 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 RAN node can also be a server, wearable device, vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the RAN node 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 RAN node can also be equipped with communication modules, circuits, or chips that perform corresponding communication functions. The RAN node can also be configured with program instructions for performing corresponding communication functions, as well as corresponding program instructions. The RAN node in this application can also be a logical node, logical module, or software capable of implementing all or part of the RAN node's functions.

[0081] In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, with each RAN node performing a portion of the base station's functions. For example, RAN nodes can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs), etc. CUs and DUs can be separate entities or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio frequency equipment or radio frequency units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

[0082] In the communication system shown in Figure 1, the terminal can be a device or module that accesses the communication system and has corresponding communication functions. The terminal can also be called a terminal device, user equipment (UE), mobile station, mobile terminal, etc. Terminals 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. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, transportation vehicles with wireless communication capabilities, communication modules, etc. The embodiments of this application do not limit the device form of the terminal. The terminal typically contains a communication module, circuit, or chip that performs the corresponding communication function. The terminal can also be configured with program instructions for performing the corresponding communication function.

[0083] In addition, the core network 130 mainly includes one or more of the following: user plane function (UPF) network elements, data network (DN), session management function network elements, registration function network elements, policy control function (PCF) network elements, short message service function (SMSF) network elements, selection function network elements, identity storage function network elements, and unified data management (UDM) network elements. It should be understood that interfaces exist between these network elements to achieve distributed connectivity. For example, this network architecture can be a network architecture after introducing RAN services; in this case, the interfaces between the RAN equipment and each network element can all be service-oriented interfaces.

[0084] To facilitate understanding of the functions of this network architecture, the functions of each network element will be briefly explained below.

[0085] User plane function network elements are primarily responsible for processing user packets, such as forwarding and charging. They can serve as anchor points for Protocol Data Unit (PDU) session connections, i.e., PDU session anchors (PSAs). They are responsible for filtering UE 10 data packets, transmitting or forwarding data, rate control, generating charging information, handling Quality of Service (QoS) for user plane sessions, uplink authentication, transmission level verification, downlink packet buffering, and triggering downlink data notifications. User plane function network elements can also serve as branch points for multi-homed PDU sessions.

[0086] A data network is a network that provides data transmission services to users, such as the Internet Protocol (IP), IP Multimedia Service (IMS), and the Internet. A data network may include an application server (AS), which is a software framework that provides an environment for applications to run, offering services such as security, data and transaction support, load balancing, and management of large distributed systems. Terminal devices obtain application messages by communicating with the application server.

[0087] The session management function network element is primarily responsible for all control plane functions of session management for terminal devices, including the selection and control of user plane function network elements, IP address allocation and management, session QoS management, and obtaining policy and charging control (PCC) policies from policy control function network elements. The session management function network element also serves as the endpoint for the session management portion of non-access stratum (NAS) messages.

[0088] Registration function network elements can be used to provide access and authentication functions for terminal devices. For example, the registration function network element may include access and mobility management function network elements.

[0089] The policy control function network element has the function of providing policy rules to the control plane function entity.

[0090] The SMS service function network element is responsible for handling SMS services in the network, such as SMS registration and cancellation, SMS forwarding, and SMS call caching.

[0091] The selection function network element can be used to select a core network element for a terminal device. Specifically, core network elements in the network can register with the selection function network element, which can then select a target core network element for the terminal device from among the registered core network elements. The selection function network element can also obtain the terminal device's subscription data from the unified data management network element, and then select a target core network element for the terminal device based on the core network element registration information and the subscription data. For example, the selection function network element may include a network function repository function (NFR) network element.

[0092] The identifier storage function network element can be used to store the correspondence between temporary and permanent identifiers of terminal devices. Specifically, after the network function registration function network element obtains the correspondence between the temporary and permanent identifiers of the terminal devices, it can store this correspondence in the identifier storage function network element. For example, this identifier storage function network element can be a unified database network element.

[0093] The unified data management network element is mainly responsible for the management of the subscription data of terminal devices, including the storage and management of terminal device identifiers and the authorization of terminal device access.

[0094] It should be noted that the naming of network elements in the core network in this application embodiment is exemplary and not limiting. As technology evolves, entities with the corresponding functions of each network element may adopt other naming methods, and no specific restrictions are imposed on this. For example, access and mobility management network elements may be named access management function network element, mobility management function network element, registration management function network element, etc.

[0095] Please refer to Figure 2, which is a schematic diagram of a communication scenario provided by this application. The communication method provided by this application is applicable to this scenario. As shown in Figure 2, this scenario may include a terminal device, a network device on the radio access network side, and a first network element and a second network element on the core network side. In the embodiments of this application, the first network element may be a terminal device context used to store the terminal device or a core network element responsible for the access and mobility management of the terminal device. For example, the first network element may be an access and mobility management function network element. The second network element is a backup network element of the first network element. Optionally, the second network element and the first network element may be located at different sites.

[0096] The terminal device, network device, first network element, and second network element can work together to implement the various steps of the communication method provided in this application. For specific implementation details, please refer to the corresponding description below.

[0097] Please refer to Figure 3, which is a schematic diagram of another communication scenario provided by this application. The other communication method provided by this application is applicable to this scenario. As shown in Figure 3, this scenario may include a third network element and a fourth network element on the core network side. In the embodiments of this application, the third network element and the fourth network element can be any two network elements on the core network side that have a communication connection. For example, the third network element can be an access and mobility management function network element, and the fourth network element can be a session management function network element.

[0098] The third and fourth network elements can also work together to implement the various steps of the communication method provided in this application. For specific implementation details, please refer to the corresponding description below.

[0099] Here, the descriptions of the terminal devices, network devices, and various network elements involved in Figure 2 or Figure 3 can be found in the relevant descriptions of the communication system shown in Figure 1, and will not be repeated here.

[0100] The preceding text has described the communication system and communication scenarios to which the communication method provided in this application is applicable, based on Figures 1-3. The following text will describe in detail the implementation process of the communication method provided in this application, in conjunction with the content shown in Figures 1-3.

[0101] Example 1

[0102] In actual communication, the business path corresponding to the business process may also encounter anomalies other than those specified in the protocol and custom anomalies, which can also lead to business process failure. For example, anomalies such as internal processing logic errors within network elements or application defects (i.e., software bugs) may occur in the business path, causing business process failure. However, since existing anomaly detection mechanisms cannot detect these anomalies, backup network elements or backup communication links are not used to recover from business process failures. Therefore, based on the existing failure recovery process, the business process will be re-initiated on the business path with such anomalies, resulting in continuous failure of the business process and affecting the user experience of terminal devices.

[0103] Based on this, the technical problem to be solved by this application is: how to avoid the continuous failure of business processes caused by anomalies that cannot be detected by existing anomaly detection mechanisms.

[0104] To solve this problem, this application provides a communication method. Please refer to Figure 4, which is a flowchart illustrating the communication method provided in this application. As shown in Figure 4, the method includes the following steps:

[0105] S401, if the first network element experiences an unexpected failure in the first service process, the second network element is determined. The cause of the unexpected failure does not include exceptions specified in the protocol or custom exceptions.

[0106] In some feasible implementations, if the first network element determines that the first service process has experienced an unexpected failure, it can identify a second network element. The second network element is a backup network element for the first network element. The causes of the aforementioned unexpected failure do not include protocol-defined exceptions or custom exceptions. In other words, an unexpected failure is a failure caused by an unexpected exception, which is any exception other than those specified in the protocol or custom exceptions.

[0107] It should be understood that, in the embodiments of this application, the exceptions specified in the protocol and custom exceptions are generally exceptions that cannot be recovered from by switching business paths. For example, exceptions specified in the protocol include, but are not limited to, reasons for business process failure as defined in the current and future communication protocols, such as unpaid fees or contract restrictions. Custom exceptions mainly refer to reasons for business process failure that can be flexibly configured by the user, such as not supporting Internet Protocol version 6 (IPv6) access types.

[0108] It should be noted that, in this embodiment, an unexpected failure of the first service process can refer to a failure caused by an unexpected anomaly in the network element or communication link associated with the first service process. Alternatively, an unexpected failure of the first service process can also refer to an unexpected anomaly in the service path corresponding to the first service process. Here, the service path corresponding to the first service process may include the network element and communication link associated with the first service process. It should be understood that, in this embodiment, the network element or communication link associated with the first service process refers to the network element and communication link used in the implementation of the first service process. These network elements and communication links are used to implement the sending and receiving of request and response messages and the processing of request and response messages involved in the first service process.

[0109] Furthermore, in this embodiment, since the unexpected failure of the first service process is determined by the first network element, it can also be described as the unexpected failure of the first service process occurring on the first network element. It should be understood that the unexpected failure of the first service process on the first network element as described in this application does not necessarily mean that the unexpected anomaly causing the unexpected failure must occur on the first network element. It could also occur on other network elements associated with the first service process and interacting with the first network element, or on the communication link between the first network element and other network elements associated with the first service process and interacting with the first network element.

[0110] Optionally, in the embodiments of this application, unexpected anomalies include, but are not limited to: internal logic processing anomalies of network elements, application software defects, transmission packet loss, and probabilistic processing failures of the communication system.

[0111] In one possible implementation, when the first network element determines that the first service process has failed, it can obtain the corresponding failure reason value. Then, the first network element can determine whether the failure reason value corresponds to a protocol-specified exception or a custom exception. If the first network element determines that the failure reason value corresponds to a protocol-specified exception or a custom exception, then the failure of the first service process is determined to be caused by a protocol-specified exception or a custom exception, and existing failure recovery schemes can be used to recover the first service process. If the first network element determines that the failure reason value does not correspond to a protocol-specified exception or a custom exception, then the failure of the first service process is determined to be caused by an exception other than a protocol-specified exception or a custom exception, i.e., the first service process has experienced an unexpected failure.

[0112] Optionally, the failure reason value of the first service process can be included in a message received by the first network element indicating that the first service process has failed. For example, this message can be a request timeout message received by the first network element from network element A after the first network element sends a service request associated with the first service process to another network element (let's assume it's network element A for ease of distinction).

[0113] In one possible implementation, after determining that an unexpected failure has occurred in the first service process, the first network element can determine a target set of network elements. This target set may include one or more backup network elements of the first network element. Then, the first network element can select a second network element from these one or more backup network elements.

[0114] Optionally, the first network element may randomly select the second network element from one or more backup network elements, or the second network element may be selected based on the usage of these backup network elements. This application does not restrict the specific implementation process of the first network element selecting the second network element from one or more backup network elements.

[0115] Optionally, the aforementioned set of target network elements may be provided by the network registration function network element to the first network element during the network function discovery phase, or it may be determined by the first network element based on the sub-local configuration information. This application does not impose specific restrictions on this.

[0116] S402, the first network element migrates the first service process to the second network element, instructing subsequent processes of the first service process to be initiated through the second network element.

[0117] In some feasible implementations, after determining that the first business process has experienced an unexpected failure, the first network element can migrate the first business process to the second network element, instructing subsequent processes of the first business process to be initiated through the second network element. Alternatively, the first network element can migrate the first business process to the second network element, allowing the second network element to handle the processing of requests and responses related to the first business process on its behalf.

[0118] In the above implementation, when the first service process fails and the cause of failure does not include exceptions specified in the protocol or custom exceptions, the first network element will migrate the first service process to a backup second network element, instructing subsequent processes of the first service process to be initiated through the second network element. This method prevents the first service process from being repeatedly initiated on the first network element where an unexpected failure has already occurred, thus avoiding continuous failures of the first service process, reducing service latency, and improving the user experience of terminal devices.

[0119] This application provides several possible implementation methods for the process of migrating the first service process from the first network element to the second network element, which will be described below.

[0120] Method 1 for implementing the first business process migration:

[0121] Please refer to Figure 5, which is another flowchart illustrating a communication method provided in this application. As shown in Figure 5, step S402 may include the following steps:

[0122] S4021, if the service of the first network element fails and recovers to the redirection mode, the first network element sends a first request message to the second network element. The first request message is used to provide the second network element with the session information already generated corresponding to the first service process. The corresponding second network element receives the first request message.

[0123] In some possible implementations, after determining that the first service process has unexpectedly failed, the first network element can obtain the service recovery method for itself. If the service failure recovery of the first network element is determined to be a redirection method, it can generate and send a first request message to the second network element to migrate the first service process to the second network element. The first request message provides the second network element with the already generated session information corresponding to the first service process. This already generated session information can be used for subsequent failure recovery of the first service process executed by the second network element. It should be understood that the aforementioned already generated session information refers to the session information associated with the first service process generated by the first network element during the execution of the first service process. Correspondingly, the second network element can receive the first request message and obtain the aforementioned already generated session information. Furthermore, the second network element can continue to execute the unfinished operations of the first service process on behalf of the first network element.

[0124] In one possible implementation, the first request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, terminal device context information of the first service process, or first information, wherein the first information is used to indicate that the first service process has failed unexpectedly and is migrated from the first network element to the second network element. Alternatively, the first information is used to indicate that the terminal device initiating the first service process switches to the second network element due to an unexpected failure of the first service process, and the reason for the unexpected failure does not include protocol-specified exceptions or custom exceptions. Or, the first information is used to indicate that the first service process failed due to an unexpected exception other than protocol-specified exceptions or custom exceptions, and is migrated from the first network element to the second network element.

[0125] Optionally, the N1 interface message between the terminal device initiating the first service process and the first network element can be transmitted through the N1 interface container message (i.e., n1_message_container). The terminal device context information of the terminal device initiating the first service process can be transmitted through the registration context container message (i.e., registration_ctxt_container).

[0126] Optionally, the aforementioned first information may be a specific bit in the first request message, and the value of this bit is a preset value. For example, the first information may be the first or last free bit of the first request message, and the value of this free bit is 1.

[0127] Optionally, the aforementioned first request message is referred to as the N1 message notification request corresponding to the first business process. For example, the first request message can be expressed as Namf_communication_N1message_notify_request.

[0128] Optionally, as shown in Figure 5, after step S4021, the method may further include the following steps:

[0129] S4022, the second network element sends a first response message to the first network element to indicate that the first request message has been correctly received. Correspondingly, the first network element receives the first response message.

[0130] In practice, after correctly receiving the first request message, the second network element can send a first response message to the first network element to indicate that the first request message has been correctly received. Correspondingly, upon receiving this first response message, the first network element can determine that the second network element has correctly received the first request message.

[0131] Optionally, the aforementioned first request message can be referred to as the N1 message notification response corresponding to the first business process. For example, the first request message can be described as Namf_communication_N1message_notify_response.

[0132] In the above implementation, when a service failure is recovered via redirection, the first network element can provide the second network element with the already generated session information corresponding to the first service process, facilitating the migration of the first service process to the second network element. This method is simple and easy to implement, ensuring not only the efficiency of the first service process's failure recovery but also making the communication method provided in this application applicable to scenarios where service failure is recovered via redirection.

[0133] Method 2 for implementing the first business process migration:

[0134] As shown in Figure 5, step S402 may also include the following steps:

[0135] S4023, if the service failure in the first network element recovers to rerouting mode, a second request message is sent to the network device. The second request message instructs the network device to reroute the first service process to the second network element. Accordingly, the second network element receives the second request message.

[0136] In some feasible implementations, after determining that the first service process has experienced an unexpected failure, the first network element can obtain the service recovery method of the first network element. If it is determined that the service failure recovery of the first network element is a rerouting method, it can generate and send a second request message to the network device to migrate the first service process to the second network element. The second request message instructs the network device to reroute the first service process to the second network element. Here, the aforementioned first service process is initiated by the terminal device to the first network element through the network device, and the relevant information of the first service process is forwarded by the network device between the terminal device and the first network element.

[0137] Correspondingly, the network device can receive the second request message and determine, based on the second request message, to reroute the first service process to the second network element.

[0138] In one optional implementation, the second request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, and identification information of the second network element.

[0139] Optionally, the N1 interface information between the terminal device initiating the first service process and the first network element can be transmitted via next generation (NG) application protocol messages.

[0140] Optionally, as shown in Figure 5, after step S4023, the method may further include the following steps:

[0141] S4024, the network device initiates the first service process to the second network element.

[0142] After receiving the second request message, the network device can determine that the first service process needs to be rerouted to the second network element. Then, the network device can initiate the first service process to the second network element, so that the second network element can re-initiate the subsequent processes of the first service process.

[0143] In the above implementation, when a service failure is recovered to a rerouting mode, the first network element can instruct the network device to reroute the first service process to the second network element, thereby facilitating the migration of the first service process to the second network element. This method is simple and easy to implement, ensuring not only the efficiency of the first service process's failure recovery but also making the communication method provided in this application applicable to scenarios where service failure is recovered to a rerouting mode.

[0144] Method 3 for implementing the first business process migration:

[0145] As shown in Figure 5, step S402 may also include the following steps:

[0146] In step S4025, the first network element sends a third request message to the second network element, instructing the second network element to rebuild the session information of the first service process. Correspondingly, the second network element receives the third request message.

[0147] In some possible implementations, after determining that the first service process has unexpectedly failed, the first network element may send a third request message to the second network element. This third request message instructs the second network element to rebuild the session information of the first service process. Alternatively, the third request message can be used to send the session information of the terminal device that initiated the first service process, as well as related information generated by the first network element during the execution of the first service process, to the second network element, so that the second network element can subsequently continue executing the first service process on behalf of the first network element. Accordingly, the second network element may receive the third request message and determine to rebuild the session information of the first service process.

[0148] In one possible implementation, the third request message includes: identification information of the network device, identification information of the next-generation application protocol corresponding to the terminal device initiating the first service process, or first information. The first information is used to indicate that the first service process has failed unexpectedly and is being migrated from the first network element to the second network element. Alternatively, the first information is used to indicate that the terminal device initiating the first service process is switching to the second network element due to an unexpected failure of the first service process, and the reason for the unexpected failure does not include protocol-specified exceptions or custom exceptions. Or, the first information is used to indicate that the first service process has failed due to an unexpected exception other than protocol-specified exceptions or custom exceptions, and is being migrated from the first network element to the second network element.

[0149] Optionally, the identification information of the network device can be the globally unified radio access network identifier of the network device associated with the first service process. The next-generation application protocol identifier information corresponding to the terminal device can be the next-generation radio access network application protocol identifier (i.e., NG-RAN application protocol ID, abbreviated as NGAP ID) of the terminal device.

[0150] Optionally, the aforementioned first information may be a specific bit in the first request message, and the value of this bit is a preset value. For example, the first information may be the first or last free bit of the first request message, and the value of this free bit is 1.

[0151] Optionally, the aforementioned third request message can also be referred to as the N1 message notification request corresponding to the first business process. For example, the first request message can be expressed as Namf_communication_N1message_notify_request.

[0152] Optionally, as shown in Figure 5, after step S4025, the method may further include the following steps:

[0153] S4026, the second network element initiates a terminal device context modification procedure to the network device so that the terminal device can switch to the second network element.

[0154] After reconstructing the session information for the first service process, the second network element can initiate a terminal device context modification procedure to the network device, thereby switching the terminal device that initiated the first service process from the first network element to the second network element. In other words, the terminal device no longer implements the first service process through the first network element, but through the second network element.

[0155] Optionally, the second network element may send a terminal device context modification request to the network device. Correspondingly, the network device receives the terminal device context modification request and sends a terminal device context modification response back to the second network element, indicating that it has correctly received the terminal device context modification request. Further, after receiving the terminal device context modification response, the second network element may send an update instruction for the first service process to the terminal device that initiated the first service process, indicating that subsequent processes of the first service process will be executed by the second network element. Correspondingly, the terminal device may receive the update instruction for the first service process and, after completing the update, will send an update completion message for the first service process back to the second network element. Upon receiving the update completion message for the first service process, the second network element may send a second response message to the first network element in response to the third request message, indicating that the first service process has been migrated from the first network element to the second network element. Correspondingly, the first network element may receive the second response message and determine that the migration of the first service process has been completed based on the second response message.

[0156] Optionally, after the first service process is migrated from the first network element to the second network element, the first network element can update the relevant information of the second network element to its surrounding functional network elements. These functional network elements include, but are not limited to: session management functional network elements, unified data management network elements, and policy control functional network elements associated with the first network element.

[0157] In the above implementation, the first network element can directly instruct the second network element to reconstruct the session information of the first service process through a third request message, thereby realizing the migration of the first service process to the second network element. This method is simple and easy to implement, and can guarantee the efficiency of failure recovery of the first service process.

[0158] It should be noted that, using the communication method shown in Figure 4 or Figure 5, when the first network element and the second network element serve as backups for each other, if the first service process migrates from the first network element to the second network element due to an expected failure, and then experiences another unexpected failure on the second network element, the first service process will migrate back to the first network element according to the communication method shown in Figure 4 or Figure 5. However, if the unexpected failure on the first network element is not resolved, the first service process will migrate back to the second network element again. Similarly, if the unexpected failure on the second network element is also not resolved, the first service process will be migrated back to the first network element again. This results in the first service process repeatedly switching between the first and second network elements in a short period of time, forming a ping-pong switching effect, which will bring additional processing load to both the first and second network elements.

[0159] To solve this problem, please refer to Figure 6, which is another flowchart of a communication method provided in this application. As shown in Figure 6, the method may further include the following steps:

[0160] S403 If the first business process fails again, the second network element determines whether the failure is an unexpected failure.

[0161] In some possible implementations, if the first business process fails unexpectedly on the first network element and is migrated from the first network element to the second network element, and if the first business process fails again on the second network element, the second network element determines whether the second failure is an unexpected failure.

[0162] For example, when the second network element determines that the first service process has failed again, it can obtain the failure cause value for the second failure. Then, the second network element can determine whether the failure cause value corresponds to the failure cause value specified in the protocol or a custom exception. If the second network element determines that the failure cause value corresponds to the failure cause value specified in the protocol or a custom exception, then it is determined that the failure of the first service process was caused by a protocol-specified exception or a custom exception, and the existing failure recovery scheme can be used to recover the first service process. If the second network element determines that the failure cause value does not correspond to the failure cause value specified in the protocol or a custom exception, then it is determined that the first service process has experienced another unexpected failure.

[0163] S404, if the second network element determines that the first time interval between the two unexpected failures of the first service process on the first network element and the second network element is less than or equal to the time interval threshold, then the first service process will no longer be migrated to the first network element.

[0164] In some possible implementations, if the failure of the first service process is an unexpected failure, and the second network element determines that the first time interval between the two unexpected failures of the first service process occurring on the first and second network elements is less than or equal to a time interval threshold, then the first service process will no longer be migrated to the first network element. It should be noted that the unexpected failure of the first service process occurring on the first network element is the same as the unexpected failure determined by the first network element in step S401 above, and the unexpected failure of the first service process occurring on the second network element is the same as the unexpected failure determined by the second network element in step S403 above. The first time interval is the interval between the occurrence times of these two unexpected failures.

[0165] In the above implementation, if the first service process experiences unexpected failures at both the first and second network elements, and the time interval between the two unexpected failures is less than or equal to a time interval threshold, the second network element will not migrate the first service process back to the first network element. In the event that the anomaly at the first network element has not been recovered, this solution can avoid the continuous failure of the first service process caused by the back-and-forth switching between the first and second network elements (i.e., ping-pong switching), thus avoiding the additional processing load that ping-pong switching brings to the first and second network elements.

[0166] In one possible implementation, when the first network element adopts implementation method 1 for the first service process migration, the aforementioned first time interval is the time interval between the first moment of receiving the first request message and the second moment when the unexpected failure occurs again on the second network element. That is, when the second network element receives the aforementioned first request message and determines that the first request message includes first information, it can determine the first moment of receiving the first request message as the moment when the first service process unexpectedly fails on the first network element. Then, the second network element can determine the difference between the second moment when the unexpected failure occurs again on the second network element and the aforementioned first moment as the aforementioned first time interval.

[0167] In the above implementation, the first time interval is set as the difference between the time when the first request message used by the first business process to migrate to the second network element is received and the time when the unexpected failure occurs again on the second network element. The solution is simple and easy to implement, and can ensure the efficiency of the failure recovery of the first business process.

[0168] In another possible implementation, where the first network element adopts implementation method 3 for the first service process migration, the aforementioned first time interval is the time interval between the third moment of receiving the third request message and the second moment when the unexpected failure occurs again on the second network element. That is, when the second network element receives the aforementioned third request message and determines that the third request message includes the first information, it can determine the third moment of receiving the third request message as the moment when the first service process unexpectedly fails on the first network element. Then, the second network element can determine the difference between the second moment when the unexpected failure occurs again on the second network element and the aforementioned third moment as the aforementioned first time interval.

[0169] In the above implementation, the first time interval is set as the difference between the time when the third request message used by the first business process to migrate to the second network element is received and the time when the unexpected failure occurs again on the second network element. The solution is simple and easy to implement, and can ensure the efficiency of the failure recovery of the first business process.

[0170] It should be understood that the above description of the method for the second network element to determine the first time interval is merely exemplary. In actual implementation, the second network element may also use other methods to determine the first time interval, and this application does not impose any specific restrictions on this.

[0171] Optionally, the method may also include the following steps:

[0172] S405, if the second network element determines that the first time interval between the two unexpected failures of the first service process on the first network element and the second network element is greater than the time interval threshold, then the first service process is migrated to the first network element.

[0173] In some possible implementations, if the subsequent failure is an unexpected failure, and the second network element determines that the first time interval between the two unexpected failures of the first service process occurring on the first and second network elements is greater than a time interval threshold, then the first service process can be migrated to the first network element. Here, the specific implementation process of the second network element migrating the first service process to the first network element is similar to the implementation process of the first network element migrating the first service process to the second network element described above, and can be referred to in step S402 above; therefore, it will not be repeated here.

[0174] In the above implementation, if the time interval between two unexpected failures is greater than the time interval threshold, the first service process can be migrated back to the first network element. This can avoid the situation where the first network element has recovered but the first service process has not been switched back, thus improving the flexibility and practicality of the communication method provided in this application.

[0175] It should be further noted that, in one possible implementation, the first service process can be an initial registration process initiated by the terminal device. In this case, the aforementioned first network element can be the access and mobility management function network element (here assumed to be the first AMF network element) that the terminal device connected to before the unexpected failure of the first service process, and the second network element is the backup access and mobility management function network element of the first network element (here assumed to be the second AMF network element). It should be understood that when the first service process can be an initial registration process initiated by the terminal device, the first network element can adopt either the first service process migration implementation method 1 or the first service process migration implementation method 2 described above.

[0176] The implementation process of the communication method provided in this application will be illustrated below using the initial registration process initiated by the terminal device as an example.

[0177] Please refer to Figure 7, which is a schematic diagram of a failure recovery process for an initial registration procedure provided in this application. As shown in Figure 7, the failure recovery process may include the following steps:

[0178] S701, the terminal device initiates the initial registration process with the first AMF network element through the network device.

[0179] The specific process may include a security management process, a process for obtaining contract data, and a process for obtaining session management policies. The specific implementation of these processes can be found in the corresponding implementation of the existing initial registration process, and will not be described in detail here.

[0180] S702, the first AMF network element selects the first PCF network element and sends an access management policy control creation request to the first PCF network element.

[0181] During the process of obtaining the session management policy, the first AMF network element can select the first PCF network element and send an access management policy control creation request to the first PCF network element to request the first PCF network element to provide the session management policy.

[0182] S703, if the first PCF network element is unable to respond to the access management policy control creation request, it sends a message timeout message to the first AMF network element. Correspondingly, the first AMF network element receives the message timeout message.

[0183] After receiving the access management policy control creation request from the first AMF network element, if the first PCF network element determines that it cannot respond to the request, it can send a message timeout information to the first AMF network element.

[0184] S704, the first AMF network element determines that the initial registration process has failed unexpectedly, and selects the second AMF network element.

[0185] If the first AMF network element receives a message timeout message from the first PCF network element, it can determine that the first PCF network element cannot respond to the access management policy control creation request, and thus the initial registration process has failed. Furthermore, the first AMF network element can determine whether the initial registration process failure is due to a predefined protocol exception or a custom exception. If it is not, the initial registration process has failed unexpectedly. Further, the first AMF network element can select a backup second AMF network element.

[0186] If the service fails and is reverted to a redirection method, perform the following steps:

[0187] S705, in the event that the service fails and is restored to the redirection mode, the first AMF network element sends a first request message to the second AMF network element.

[0188] If the first AMF network element determines that its service has failed and is recovering via redirection, it can send a first request message to the second AMF network element. This first request message can also be called an N1 interface message notification request, i.e., Namf_communication_N1message_notify_request. This first request message may include the following: an N1 interface container message, a registration context container message for the terminal device, and the aforementioned first information. Specifically, the N1 interface container message is used to transmit N1 interface information between the terminal device and the first AMF network element, and the registration context container message can be used to transmit registration context information related to the terminal device.

[0189] S706, the second AMF network element sends a first response message to the first AMF network element.

[0190] If the second AMF network element correctly receives the first request message, it can send a first response message to the first AMF network element. Correspondingly, the first AMF, upon receiving the first response message, confirms that the second AMF has correctly received the first request message. Here, this first response message can also be called the N1 interface message notification response, i.e., Namf_communication_N1message_notify_response.

[0191] If the service fails and reverts to rerouting mode, perform the following steps:

[0192] S707, the first AMF network element sends a second request message to the network device.

[0193] If the first AMF network element determines that its service has failed and it has to recover to rerouting mode, it can send a second request message to the network device. Here, this first request message can also be called a rerouting non-access stratum (NAS), or reroute_NAS_request. The second request message may include the following: a next-generation application protocol message and the identification information of the second AMF network element. The next-generation application protocol message is used to transmit the N1 interface information between the terminal device and the first AMF network element.

[0194] S708, the network device sends a registration request to the second AMF network element.

[0195] After receiving the second request message, the network device can determine the second AMF network element based on the second request message and send a registration request to the second AMF network element.

[0196] After step S706 or step S708, the following steps are performed:

[0197] S709, the second AMF network element re-initiates the subsequent registration process.

[0198] After the initial registration process is migrated to the second AMF network element, the second AMF network element can re-initiate the subsequent registration process of the initial registration process to complete the recovery from the failure of the initial registration process.

[0199] S710, the second AMF network element sends a registration acceptance message to the terminal device.

[0200] After the second AMF network element re-initiates the subsequent registration process, it can also send a registration acceptance message to the terminal device to notify the terminal device that it has re-initiated the initial registration process.

[0201] By implementing the above, it is possible to avoid the situation where the initial registration process is unexpectedly failed and the initial registration process is re-initiated on the first AMF network element that has already experienced an unexpected failure. This can prevent the continuous failure of the initial registration process and reduce the service latency of the initial registration process.

[0202] In one possible implementation, the first service process can be a service process initiated by the terminal device after initial registration, such as PDU session establishment and serving cell handover. In this case, the aforementioned first network element can be the access and mobility management function network element (here assumed to be the first AMF network element) that the terminal device connected to before the unexpected failure of the first service process, and the second network element is the backup access and mobility management function network element of the first network element (here assumed to be the second AMF network element). It should be understood that in this case, the first network element can adopt the implementation method 3 of the first service process migration described above.

[0203] The following will use the PDU session establishment process after the terminal device completes registration as an example to illustrate the implementation process of the communication method provided in this application.

[0204] Please refer to Figure 8, which is a schematic diagram of a PDU session establishment process failure recovery method provided in this application. As shown in Figure 8, the failure recovery process may include the following steps:

[0205] S801, the terminal device initiates a PDU session establishment process to the first AMF network element through the network device.

[0206] The specific process may include the establishment of a session management context and the acquisition of a session management policy. The specific implementation of these processes can be found in the corresponding implementations in the existing PDU session establishment process, and will not be described in detail here.

[0207] S802, the first SMF network element sends a PDU session establishment rejection to the first AMF network element.

[0208] If the PDU session establishment process fails during the acquisition of session management policies, the first SMF network element can send a PDU session establishment rejection to the first AMF network element. Accordingly, if the first AMF network element receives a PDU session establishment rejection from the first SMF network element, it can determine that the PDU session establishment process has failed.

[0209] S803, the first AMF network element determines that the PDU session establishment process has failed unexpectedly, and selects the second AMF network element.

[0210] If the first AMF network element determines that the PDU session establishment process has failed, it can determine whether the failure is due to a predefined protocol exception or a custom exception. If not, the PDU session establishment process has failed unexpectedly. Furthermore, the first AMF network element can select a backup second AMF network element.

[0211] S804, the first AMF network element sends a third request message to the second AMF network element.

[0212] If the first AMF network element determines that the PDU session establishment process has unexpectedly failed, it can send a third request message to the second AMF network element. This third request message can also be called an N1 interface message notification request, i.e., Namf_communication_N1message_notify_request. This third request message may include the following items: network device identification information, Next Generation Application Protocol (NGAP) identification information corresponding to the terminal device that initiated the PDU session establishment process, or first information. The network device identification information can be the network device's Global Unified Radio Access Network (GRAN) identifier. The NGAP identification information corresponding to the terminal device can be the terminal device's NGAP ID.

[0213] S805, the second AMF network element sends a terminal device context modification request to the network device.

[0214] After receiving the aforementioned third request message, the second AMF network element can send a UE context modification request to the network device to trigger the network device to update the UE context information of the UE.

[0215] S806, the network device sends a terminal device context modification response to the second AMF network element.

[0216] After correctly receiving the terminal device context modification request, the network device can send a terminal device context modification response (i.e., UE context modification response) to the second AMF network element to notify it that it has received the terminal device context modification request.

[0217] S807, the second AMF network element sends a registration update instruction to the terminal device.

[0218] After correctly receiving the terminal device's context modification request, the network device can also send a registration update instruction to the terminal device to instruct the terminal device to complete the registration update.

[0219] S808, the terminal device sends a registration update success indication to the second AMF network element.

[0220] Once the terminal device completes the registration update, it can send a registration update success indication to the second AMF network element.

[0221] S809, the second AMF network element sends a second response message to the first AMF network element.

[0222] Upon receiving a successful registration update indication from the terminal device, the second AMF network element can determine that the terminal device has completed the registration update. In this case, the second AMF network element can send a second response message to the first AMF network element to notify the first AMF network element that the PDU session establishment process has been migrated to the second network element.

[0223] S810, the first AMF network element notifies its surrounding network elements that the PDU session establishment process has been migrated to the second AMF network element.

[0224] After receiving the second response message from the second AMF network element, the first AMF network element notifies its surrounding network elements that the PDU session establishment process has been migrated to the second AMF network element.

[0225] By implementing the above, it is possible to avoid the situation where the PDU session establishment process is repeatedly initiated on the first AMF network element that has already experienced an unexpected failure, in the event of an unexpected failure in the PDU session establishment process. This can prevent the continuous failure of the PDU session establishment process and reduce the service latency of the PDU session establishment process.

[0226] Example 2

[0227] When a network element in the core network (let's call it the third network element for simplicity) initiates a service request to another network element (let's call it the fourth network element for simplicity), and the service request fails unexpectedly, it indicates that there is an unexpected anomaly in the service path between the third and fourth network elements (this service path includes the third network element, the fourth network element, and the communication links between the third and fourth network elements). If this unexpected anomaly persists, it will cause the success rate of service requests initiated by the third network element to the fourth network element to continuously decrease, which will seriously affect the implementation of service processes associated with the third and fourth network elements.

[0228] To address this problem, this application provides another communication method. It should be noted that this communication method is applicable to situations where there is service interaction between a third network element and a fourth network element. The third network element can send service requests corresponding to different service processes to the fourth network element. Please refer to Figure 9, which is a flowchart illustrating another communication method provided in this application. As shown in Figure 9, this communication method may include the following steps:

[0229] S901, the third network element determines that the first service request initiated to the fourth network element has unexpectedly failed.

[0230] In some feasible implementations, during the process of a third network element initiating multiple service requests to a fourth network element, when the third network element determines that its first service request to the fourth network element has failed, the third network element can further determine whether the failure of the first service request was unexpected. Unexpected failures do not include protocol-defined exceptions or custom exceptions. In other words, an unexpected failure is a failure caused by an unexpected exception, which is an exception other than protocol-defined exceptions and custom exceptions. It should be understood that in the embodiments of this application, protocol-defined exceptions and custom exceptions are generally exceptions that cannot be recovered by switching service paths. For example, protocol-defined exceptions include, but are not limited to, reasons for service process failure specified in the current communication protocol and future communication protocols, such as overdue payments or contract restrictions. Custom exceptions mainly refer to reasons for service process failure that can be flexibly configured by the user, such as not supporting IPv6 access types.

[0231] It should also be noted that, in the embodiments of this application, the unexpected anomaly causing the first service request to fail unexpectedly may occur on the fourth network element, or it may occur on the communication link between the third and fourth network elements. This application does not impose specific limitations on this. In addition, the unexpected failure of the first service request initiated to the fourth network element can be understood as an unexpected anomaly existing in the service path between the third and fourth network elements.

[0232] In one possible implementation, when the third network element determines that the first service request has failed, it can obtain the corresponding failure reason value. Then, the third network element can determine whether the failure reason value corresponds to a protocol-specified exception or a custom exception. If the third network element determines that the failure reason value does not correspond to a protocol-specified exception or a custom exception, it can be determined that the first service request failed due to an exception other than the protocol-specified exception or the custom exception, i.e., the first service request has experienced an unexpected failure.

[0233] S902, the third network element adjusts the number of service requests it initiates to the fourth network element based on the success rate of service requests between the third network element and the fourth network element.

[0234] In some feasible implementations, when an unexpected failure of the first service request is determined, the third network element can adjust the number of service requests it initiates to the fourth network element based on the success rate of service requests between the third and fourth network elements. Specifically, the number of service requests initiated by the third network element to the fourth network element is positively correlated with the success rate of service requests between the fourth and third network elements. That is, the number of service requests initiated by the third network element to the fourth network element increases as the success rate of service requests increases, and decreases as the success rate of service requests decreases. In other words, the higher the success rate of service requests between the fourth and third network elements, the more service requests the third network element initiates to the fourth network element; the lower the success rate of service requests between the fourth and third network elements, the fewer service requests the third network element initiates to the fourth network element.

[0235] In the above implementation, when the first service request initiated to the fourth network element fails unexpectedly, the third network element dynamically adjusts the number of service requests initiated to the fourth network element based on the success rate of service requests between the third and fourth network elements. This ensures that the number of service requests initiated to the fourth network element is positively correlated with the success rate of service requests, meaning that a high success rate results in more service requests being initiated, and a low success rate results in fewer service requests being initiated. This reduces the impact of unexpected anomalies on the service path between the third and fourth network elements on service requests initiated by the third network element to the fourth network element, thereby improving the success rate of service requests.

[0236] In the first possible implementation, if the success rate of service requests between the fourth network element and the third network element is less than the first success rate threshold but greater than the second success rate threshold, the third network element can adjust the number of service requests initiated to the fourth network element according to the positive correlation between the success rates of service requests.

[0237] In the above implementation, only when the success rate of service requests between the fourth network element and the third network element is less than the first success rate threshold but greater than the second success rate threshold, the number of service requests initiated to the fourth network element is adjusted according to the positive correlation of the service request success rate. This ensures that the number of service requests initiated to the fourth network element is not too small, thus guaranteeing the effective use of the service path between the fourth network element and the third network element.

[0238] Optionally, if the success rate of service requests between the fourth network element and the third network element is less than the first success rate threshold but greater than the second success rate threshold, the third network element may first obtain the first mapping relationship. This first mapping relationship indicates the number of different service requests corresponding to different service request success rates, and the two are positively correlated.

[0239] For example, the first mapping relationship can indicate whether the success rate of a business request and the number of business requests satisfy the following formula (1): Q=K*S (1)

[0240] Where Q is the number of business requests, K is a preset positive integer with a value greater than 1, and S is the success rate of business requests.

[0241] For example, the first mapping relationship can indicate multiple different business request success rate ranges, and the number of business requests corresponding to each of these multiple business request success rate ranges. Furthermore, the larger the upper limit of a business request success rate range, the larger the number of business requests it corresponds to. For instance, the first mapping relationship can indicate six business request success rate ranges: (0.8,0.9], (0.7,0.8], (0.6,0.7], (0.5,0.6], (0.4,0.5], and (0.3,0.4], corresponding to 50, 45, 40, 35, 30, and 25 business requests respectively.

[0242] It should be understood that the above description of the first mapping relationship is only illustrative. In actual implementation, the first mapping relationship can also be implemented in other possible ways, as long as the success rate of business requests is positively correlated with the number of corresponding business requests.

[0243] Furthermore, the third network element can determine the number of service requests that are positively correlated with the first mapping relationship and the service request success rate between the fourth network element and the third network element, and determine the number of service requests as the number of service requests initiated by the third network element to the fourth network element, thereby adjusting the number of service requests initiated to the fourth network element according to the positive correlation of the service request success rate.

[0244] For example, assuming the success rate of service requests between the fourth network element and the third network element is 75%, and the value of K in the above formula (1) is 100, then according to the above formula (1), the third network element can determine that the number of service requests initiated to the fourth network element is 75. Furthermore, assuming the success rate of service requests between the fourth network element and the third network element decreases to 70%, then according to the above formula (1), the third network element can determine that the number of service requests initiated to the fourth network element is 70.

[0245] Optionally, since the success rate of service requests is dynamic and may increase or decrease, the third network element can gradually reduce the number of service requests initiated to the fourth network element when it determines that the success rate of service requests is decreasing from the first success rate threshold to the second success rate threshold. For example, when the third network element determines that the success rate of service requests is continuously decreasing from the first success rate threshold to the second success rate threshold, it can reduce the number of service requests initiated to the fourth network element by a fixed value at fixed intervals. Alternatively, the third network element can reduce the number of service requests initiated to the fourth network element by a fixed value each time it determines that the success rate of service requests is decreasing from the first success rate threshold to the second success rate threshold. It should be understood that during the process of the success rate of service requests decreasing from the first success rate threshold to the second success rate threshold, the third network element can also use other methods to reduce the number of service requests initiated to the fourth network element. This application does not impose specific restrictions on this.

[0246] Correspondingly, the third network element can also gradually increase the number of service requests initiated to the fourth network element as the success rate of service requests increases from the second success rate threshold to the first success rate threshold. For example, when the third network element determines that the success rate of service requests is continuously increasing from the second success rate threshold to the first success rate threshold, it can increase the number of service requests initiated to the fourth network element by a fixed value at fixed intervals. Alternatively, the third network element can increase the number of service requests initiated to the fourth network element by a fixed value each time it determines that the success rate of service requests is increasing from the second success rate threshold to the first success rate threshold. It should be understood that during the process of the success rate of service requests increasing from the second success rate threshold to the first success rate threshold, the third network element can also use other methods to increase the number of service requests initiated to the fourth network element, and this application does not impose specific restrictions on this.

[0247] In the second possible implementation, if the success rate of service requests between the fourth network element and the third network element is less than the second success rate threshold, the third network element can adjust the number of service requests initiated to the fourth network element to the minimum number of service requests. It should be understood that the value of the minimum number of service requests involved in this application can be determined according to actual application requirements, and this application does not impose specific restrictions on it. Furthermore, the minimum number of service requests is usually less than the number of service requests in the case where the service request success rate is less than the first success rate threshold but greater than the second success rate threshold.

[0248] In the above implementation, when the success rate of business requests between the fourth network element and the third network element is less than the second success rate threshold, it indicates that there is a significant problem with the business path between the fourth network element and the third network element. In this case, only the minimum number of business requests is guaranteed, which can minimize the impact of unexpected anomalies on business requests.

[0249] In the third possible implementation, if the success rate of service requests between the fourth and third network elements is equal to or greater than the first success rate threshold, the third network element does not limit the number of service requests it can send to the fourth network element. In other words, if the success rate of service requests between the fourth and third network elements is equal to or greater than the first success rate threshold, the third network element can send service requests to the fourth network element according to actual business needs without imposing additional restrictions on the number of service requests it can send to the fourth network element.

[0250] In the above implementation, when the success rate of service requests between the fourth network element and the third network element is greater than the first success rate threshold, it indicates that the reliability of the service path between the fourth network element and the third network element is high. At this time, the number of service requests initiated to the fourth network element is not limited, which can ensure the utilization rate of the service path.

[0251] In some possible implementations, if the success rate of service requests between the fourth and third network elements changes from being greater than a first success rate threshold to being less than the first success rate threshold, the third network element can send a second message to the Operation and Maintenance Center (OMC). This second message indicates an anomaly in the service path between the fourth and third network elements. In other words, if the success rate of service requests between the fourth and third network elements changes from being greater than the first success rate threshold to being less than the first success rate threshold, the third network element can report this unexpected anomaly to the OMC via the second message.

[0252] Optionally, if the success rate of service requests between the fourth and third network elements changes from being less than the first success rate threshold to being greater than or equal to the first success rate threshold, the third network element may also send a third message to the operation and maintenance center. This third message indicates that the service path between the fourth and third network elements has returned to normal. In other words, if the success rate of service requests between the fourth and third network elements changes from being greater than the second success rate threshold to being equal to or greater than the first success rate threshold, the third network element can report the unexpected anomaly to the operation and maintenance center via the third message that the anomaly has been resolved.

[0253] In the above implementation, the third network element can report the actual status of the service path between the fourth network element and the third network element to the operation and maintenance center based on the success rate of service requests, which facilitates resource scheduling of the communication system.

[0254] In some possible implementations, the third network element also sends a second service request to the fifth network element. This second service request is a service request that was reduced during the process of adjusting the number of service requests initiated to the fourth network element. The fifth network element and the fourth network element are different network elements. That is, during the process of adjusting the number of service requests initiated to the fourth network element based on the success rate of service requests between the fourth and third network elements, if the second service request needs to be initiated by the third network element, but the number of service requests initiated by the third network element to the fourth network element has already reached the limit, then the third network element can initiate the aforementioned second service request to the fifth network element (other than the fourth network element). In other words, the third network element can send service requests that are limited due to the service request success rate to the fifth network element (other than the fourth network element).

[0255] In the above implementation, the third network element can send the second service request that is restricted due to the success rate of the service request to other network elements. This allows these restricted service requests to be processed in a timely manner, thereby reducing service latency.

[0256] It should be further noted that, in this embodiment, the third network element and the fourth network element can be any two network elements in the core network that have service paths. For example, the third network element can be an AMF network element, and the fourth network element can be an SMF network element. Alternatively, the third network element can be an AMF network element, and the fourth network element can be a PCF network element. Furthermore, the first service request can be a service request corresponding to a service process associated with the third and fourth network elements. For example, the first service request can be certain service requests in the initial registration process initiated by the terminal device, certain service requests in the PDU session establishment process initiated by the terminal device, or certain service requests in the serving cell handover process of the terminal device. This application does not limit the specific implementation of the first service request.

[0257] The communication method provided by the embodiments of this application has been described in detail above with reference to Figures 1 to 9. The communication device provided by the embodiments of this application will now be described in detail with reference to Figures 10 to 12. It should be understood that the description of the embodiments of the communication device corresponds to the description of the embodiments of the communication method; therefore, any parts not described in detail can be referred to the foregoing method embodiments.

[0258] Please refer to Figure 10, which is a schematic diagram of the structure of a communication device provided in this application. As shown in Figure 10, the communication device 100 may include a transceiver unit 101 and a processing unit 102. Here, the transceiver unit 101 may also be referred to as a transceiver module, and the processing unit 102 may also be referred to as a processing module.

[0259] In some feasible implementations, the communication device 100 may correspond to the first network element in the methods shown in Figures 4 to 8, or a component (such as a circuit, processor, chip, or chip system) configured in the first network element. The communication device 100 may include modules, units, or means that implement the communication methods performed by the first network element shown in Figures 4 to 8. These modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software implementations. The software or hardware may include one or more modules or units corresponding to the aforementioned functions.

[0260] In a specific implementation, the transceiver unit 101 is used to send sensing auxiliary data to at least one first terminal device and at least one first network device. This sensing auxiliary data can be used for the transmission and / or measurement of sensing signals. The at least one first terminal device is managed by the at least one first network device, and this at least one first network device serves the first network element. The transceiver unit 101 is used to receive N1 sensing measurement information from the at least one first terminal device. The N1 sensing measurement information can be obtained based on the sensing signals. The sensing signals can be sent by the at least one first network device and received by the at least one first terminal device. N1 is a positive integer greater than or equal to 1. The processing unit 102 is used to determine the sensing result of the object to be sensed based on the N1 sensing measurement information.

[0261] For example, processing unit 102 is used to determine a second network element when the first service process fails unexpectedly. The second network element is a backup network element for the first network element, and the cause of the unexpected failure does not include protocol-defined exceptions or custom exceptions. Processing unit 102 is used to migrate the first service process to the second network element via transceiver unit 101, thereby instructing subsequent processes of the first service process to be initiated through the second network element.

[0262] For example, in the case of service failure recovery via redirection, the transceiver unit 101 is used to send a first request message to the second network element. The first request message provides the second network element with the already generated session information corresponding to the first service process, and this generated session information is used for the failure recovery of the first service process.

[0263] For example, the first request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, the terminal device context information of the first service process, or first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to unexpected failure.

[0264] For example, in the case of service failure and recovery to rerouting mode, the transceiver unit is used to send a second request message to the network device to migrate the first service process to the second network element, wherein the second request message is used to instruct the network device to reroute the first service process to the second network element.

[0265] For example, the second request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, and identification information of the second network element.

[0266] For example, the transceiver unit 101 is used to send a third request message to the second network element to migrate the first service process to the second network element. The third request message instructs the second network element to reconstruct the session information of the first service process.

[0267] For example, the third request message includes: identification information of the network device, identification information of the next-generation application protocol corresponding to the terminal device initiating the first service process, or first information. The first information is used to indicate that the first service process has unexpectedly failed and is being migrated from the first network element to the second network element.

[0268] For example, processing unit 102 is configured to: obtain a failure reason value in the event of a failure of the first business process; and determine, based on the failure reason value, that the cause of the failure of the first business process does not include exceptions specified in the protocol and custom exceptions, that the failure of the first business process is an unexpected failure.

[0269] In some feasible implementations, the communication device 100 may correspond to the second network element in the methods shown in Figures 4 to 8, or to a component (such as a circuit, processor, chip, or chip system) configured in the second network element. The communication device 100 may include modules, units, or means that implement the communication methods performed by the second network element shown in Figures 4 to 8. These modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software implementations. The software or hardware may include one or more modules or units corresponding to the aforementioned functions.

[0270] In specific implementation, if the first service process experiences an unexpected failure on the first network element and is migrated to the second network element, and if the first service process fails again on the second network element, the processing unit 102 determines whether the second failure is an unexpected failure. The cause of this unexpected failure does not include protocol-defined exceptions or custom exceptions. If the processing unit 102 determines that the second failure is an unexpected failure, and if the processing unit 102 determines that the first time interval between the two unexpected failures of the first service process on the first and second network elements is less than or equal to a time interval threshold, then the processing unit 102 will no longer migrate the first service process to the first network element through the transceiver unit 101.

[0271] For example, if the first time interval is greater than the time interval threshold, the processing unit 102 migrates the first service process to the first network element through the transceiver unit 101.

[0272] For example, the transceiver unit 101 is used to receive a first request message from a first network element. The first request message is used to provide the second network element with already generated session information corresponding to the first service process, so as to realize the migration of the first service process to the second network element. The already generated session information is used for failure recovery of the first service process. In this case, the aforementioned first time interval is the time interval between the first moment of receiving the first request message and the second moment when an unexpected failure occurs again on the second network element.

[0273] For example, the first request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, the terminal device context information of the first service process, or first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to unexpected failure.

[0274] For example, the transceiver unit 101 is configured to receive a third request message from a first network element to migrate a first service process to a second network element, wherein the third request message is used to instruct the second network element to rebuild the session information of the first service process. In this case, the first time interval is the time interval between the third moment of receiving the third request message and the second moment when an unexpected failure occurs again on the second network element.

[0275] For example, the third request message includes: identification information of the network device, identification information of the next-generation application protocol corresponding to the terminal device initiating the first service process, or first information. The first information is used to indicate that the first service process has unexpectedly failed and is being migrated from the first network element to the second network element.

[0276] In some feasible implementations, the communication device 100 may also correspond to the third network element in the method shown in FIG9, or a component (such as a circuit, processor, chip, or chip system) configured in the third network element. The communication device 100 may include modules, units, or means that implement the communication methods performed by the third network element shown in FIGS. 4 to 8. These modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software implementations. The software or hardware may include one or more modules or units corresponding to the aforementioned functions.

[0277] In its specific implementation, processing unit 102 determines that the first service request initiated to the fourth network element has unexpectedly failed. The reasons for unexpected failure do not include protocol-defined exceptions or custom exceptions. Processing unit 102 adjusts the number of service requests initiated to the fourth network element based on the success rate of service requests between the fourth and third network elements. The number of service requests initiated to the fourth network element is positively correlated with the service request success rate.

[0278] For example, if the success rate of service requests between the fourth network element and the third network element is less than the first success rate threshold but greater than the second success rate threshold, the processing unit 102 is used to adjust the number of service requests initiated to the fourth network element according to the positive correlation between the success rates of service requests.

[0279] For example, when the success rate of a service request decreases from a first success rate threshold to a second success rate threshold, the processing unit 102 reduces the number of service requests initiated to the fourth network element. When the success rate of a service request increases from the second success rate threshold to the first success rate threshold, the processing unit 102 increases the number of service requests initiated to the fourth network element.

[0280] For example, if the success rate of service requests between the fourth network element and the third network element is less than the second success rate threshold, the processing unit 102 is used to adjust the number of service requests initiated to the fourth network element to the minimum number of service requests.

[0281] For example, if the success rate of service requests between the fourth network element and the third network element is equal to or greater than the first success rate threshold, the processing unit 102 does not limit the number of service requests initiated to the fourth network element.

[0282] For example, when the success rate of service requests between the fourth network element and the third network element changes from being greater than the first success rate threshold to being less than the first success rate threshold, the transceiver unit 101 is used to send second information to the operation and maintenance center, wherein the second information is used to indicate that there is an anomaly in the service path between the fourth network element and the third network element.

[0283] For example, when the success rate of service requests between the fourth network element and the third network element changes from being less than a first success rate threshold to being greater than or equal to the first success rate threshold, the transceiver unit 101 is used to send third information to the operation and maintenance center. This third information indicates that the service path between the fourth network element and the third network element has returned to normal.

[0284] For example, the transceiver unit 101 is used to send a second service request to the fifth network element, wherein the second service request is a service request that was reduced during the process of adjusting the number of service requests initiated to the fourth network element.

[0285] It is understood that, in order to achieve the functions in the above embodiments, the first network element, second network element, or third network element mentioned above includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and method steps of the various examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware, software, or a combination of hardware and software. Whether a certain function is executed in hardware, software, or by computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0286] Please refer to Figure 11, which is a schematic diagram of another communication device provided in this application. This communication device 110 can be used for operations performed by the first network element, the second network element, or the third network element in the sensing methods shown in Figures 4 to 9. Alternatively, the communication device 110 can be the first network element, the second network element, or the third network element in the communication methods shown in Figures 4 to 9. The communication device 110 includes a processor 111.

[0287] Optionally, the communication device may also include a memory 112.

[0288] Memory 112 is used to store related instructions and data. Memory 112 stores the following elements: executable modules or data structures, or subsets thereof, or extended sets thereof:

[0289] Operation instructions: This includes various operation instructions used to perform various operations.

[0290] Operating system: includes various system programs used to implement various basic business functions and handle hardware-based tasks.

[0291] Figure 11 shows only one memory, but of course, multiple memories can be set as needed.

[0292] Optionally, the communication device 110 may also include a transceiver 114. The transceiver 114 may be a communication module or a transceiver circuit. In the embodiments of this application, the transceiver 114 is used to perform the message or information transmission and reception operations involved in the methods shown in Figures 4 to 9 above.

[0293] Processor 111 can be a controller, a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. Processor 111 can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0294] Optionally, the communication device may also include a bus system 113. In specific applications, the various components of the communication device 110 are coupled together through the bus system 113, which may include, in addition to the data bus, a power bus, a control bus, and a status signal bus, etc. However, for clarity, all buses are labeled as bus system 113 in Figure 11. For ease of illustration, Figure 11 is only schematically shown.

[0295] In specific implementation, the communication device 110 can execute the steps of the method performed by the first network element, the second network element, or the third network element in the communication method shown in Figures 4 to 9. Specifically, when the communication device 110 is used to implement the various steps performed by the first network element, the second network element, or the third network element in the communication method shown in Figures 4 to 9, the processor 111 can implement the function of the processing unit 102, and the transceiver 114 can implement the function of the transceiver unit 101.

[0296] It should be noted that in practical applications, the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above methods.

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

[0298] This application also provides a computer-readable medium having a computer program stored thereon, which, when executed by a computer, implements the steps of the communication methods shown in Figures 4 to 9 above, performed by the first network element, the second network element, or the third network element.

[0299] This application also provides a computer program product that, when executed by a computer, implements the steps of the communication method shown in Figures 4 to 9 above, which are executed by the first network element, the second network element, or the third network element.

[0300] This application also provides a chip, which includes at least a processor. The processor is used to execute computer execution instructions to cause a device on which the chip is installed to perform the steps of the communication methods shown in Figures 4 to 9, which are executed by the first network element, the second network element, or the third network element.

[0301] Optionally, the chip may also include interface circuitry. This interface circuitry is used to receive computer execution instructions and transmit them to the processor.

[0302] This application also provides a chip system including a processor for supporting devices equipped with the chip system in implementing the steps of the communication methods shown in Figures 4 to 9, which are performed by the first network element, the second network element, or the third network element. For example, generating or processing the data and / or information involved in the above methods. In one possible design, the chip system further includes a memory for storing program instructions and data necessary for the data transmission device. The chip system can be composed of chips or may include chips and other discrete devices.

[0303] Please refer to Figure 12, which is a schematic diagram of another communication device provided in this application. The communication device 120 may include a processor 121 and an interface circuit 122. The interface circuit 122 can be used to receive signals from other communication devices besides the communication device 120 and transmit them to the processor, or to send signals from the processor to other communication devices besides the communication device 120. The processor 121 can be used to implement the sensing method described in the preceding embodiments through logic circuits or by executing computer programs or instructions.

[0304] In some possible designs, the communication device 120 can be the first network element, the second network element, or the third network element in the communication methods shown in Figures 4 to 9 above, or a device that includes the first network element, the second network element, or the third network element mentioned above, or a device contained in the first network element, the second network element, or the third network element mentioned above, such as a chip system.

[0305] This application also provides a communication system. The communication system may include the terminal device, network device, first network element, and second network element described above. These entities work together to implement the communication methods shown in Figures 4 to 8.

[0306] This application also provides a communication system. This communication system may include the third and fourth network elements described above. These entities work together to implement the communication method shown in Figure 9.

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

[0308] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0309] The terms “component,” “module,” “system,” etc., used in this specification are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process or execution thread, and components may be located on a single computer or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, or a network, such as the Internet interacting with other systems via signals).

[0310] It should be understood that the term "embodiment" used throughout this specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout this specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0311] It should be understood that in the embodiments of this application, the designations "first", "second", etc. are only for distinguishing different objects, such as different network devices, and do not constitute a limitation on the scope of the embodiments of this application. The embodiments of this application are not limited thereto.

[0312] It should also be understood that in this application, “when…”, “if” and “if” all refer to the network element making a corresponding processing under certain objective circumstances, and are not time-limited, nor do they require the network element to make a judgment when it is implemented, nor do they mean that there are other limitations.

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

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

[0315] In this application, expressions such as "the item includes one or more of the following: A, B, and C" generally mean, unless otherwise specified, that the item can be any one of the following: A; B; C; A and B; A and C; B and C; A, B and C; A and A; A, A and A; A, A and B; A, A and C, A, B and B; A, C and C; B and B, B, B and B, B, B and C, C and C; C, C and C, and other combinations of A, B, and C. The above example uses three elements, A, B, and C, to illustrate the possible entries for the item. When expressed as "the item includes at least one of the following: A, B, ..., and X," that is, when the expression contains more elements, then the applicable entries for the item can also be obtained according to the aforementioned rules.

[0316] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0317] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

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

[0321] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they 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 a portion 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.) 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.

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

Claims

1. A communication method, characterized in that, Applied to the first network element, the method includes: In the event of an unexpected failure in the first business process, a second network element is determined from the target network element set, wherein the target network element set includes one or more backup network elements of the first network element, and the cause of the unexpected failure does not include exceptions specified in the protocol or custom exceptions; The first business process is migrated to the second network element.

2. The method according to claim 1, characterized in that, The migration of the first service process to the second network element includes: When the service failure recovery of the first network element is in the redirection mode, a first request message is sent to the second network element to migrate the first service process to the second network element. The first request message is used to provide the second network element with the already generated session information corresponding to the first service process. The already generated session information is used for the failure recovery of the first service process.

3. The method according to claim 2, characterized in that, The first request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, terminal device context information of the first service process, or first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to the unexpected failure.

4. The method according to claim 1, characterized in that, The migration of the first service process to the second network element includes: If the service of the first network element fails and recovers to the rerouting mode, a second request message is sent to the network device to migrate the first service process to the second network element. The second request message is used to instruct the network device to reroute the first service process to the second network element.

5. The method according to claim 4, characterized in that, The second request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, and identification information of the second network element.

6. The method according to claim 1, characterized in that, The migration of the first service process to the second network element includes: A third request message is sent to the second network element to migrate the first service process to the second network element, wherein the third request message is used to instruct the second network element to rebuild the session information of the first service process.

7. The method of claim 6, wherein, The third request message includes at least one of the following: the identification information of the network device, the next-generation application protocol identification information corresponding to the terminal device that initiated the first service process, and first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to the unexpected failure.

8. A communication method characterized by comprising: Applied to a second network element, the method includes: In the event that the first business process fails on the second network element, it is determined whether the failure is an unexpected failure. The cause of the unexpected failure does not include exceptions specified in the protocol or custom exceptions. The first business process is the business process that is migrated to the second network element after the unexpected failure occurs on the first network element. If the failure is an unexpected failure, and the first time interval between the two unexpected failures of the first service process occurring on the first network element and the second network element is less than or equal to the time interval threshold, then the first service process will no longer be migrated to the first network element.

9. The method according to claim 8, characterized in that, The method further includes: If the first time interval is greater than the time interval threshold, the first service process is migrated to the first network element.

10. The method according to claim 8 or 9, characterized in that, The method further includes: Receive a first request message from a first network element, wherein the first request message is used to provide the second network element with the already generated session information corresponding to the first service process, and the already generated session information is used for failure recovery of the first service process; The first time interval is the time interval between the first moment when the first request message is received and the second moment when the unexpected failure occurs again on the second network element.

11. The method according to claim 10, characterized in that, The first request message includes at least one of the following: N1 interface information between the terminal device initiating the first service process and the first network element, terminal device context information of the first service process, or first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to the unexpected failure.

12. The method according to claim 8 or 9, characterized in that, The method further includes: A third request message is received from the first network element to migrate the first service process to the second network element, wherein the third request message is used to instruct the second network element to rebuild the session information of the first service process; The first time interval is the time interval between the third moment when the third request message is received and the second moment when the unexpected failure occurs again on the second network element.

13. The method according to claim 12, characterized in that, The third request message includes at least one of the following: the identification information of the network device, the next-generation application protocol identification information corresponding to the terminal device that initiated the first service process, and first information, wherein the first information is used to indicate that the first service process is migrated from the first network element to the second network element due to the unexpected failure.

14. A communication method, characterized in that, Applied to a third network element, the method includes: It is determined that the first service request initiated to the fourth network element has failed unexpectedly, wherein the reasons for the unexpected failure do not include exceptions specified in the protocol or custom exceptions; The number of service requests initiated to the fourth network element is adjusted based on the success rate of service requests between the fourth network element and the third network element, wherein the number of service requests initiated to the fourth network element is positively correlated with the success rate of the service requests.

15. The method according to claim 14, characterized in that, The step of adjusting the number of service requests initiated to the fourth network element based on the service request success rate between the fourth network element and the third network element includes: If the success rate of service requests between the fourth network element and the third network element is less than the first success rate threshold but greater than the second success rate threshold, the number of service requests initiated to the fourth network element is adjusted according to the positive correlation between the service request success rates.

16. The method according to claim 14, characterized in that, The step of adjusting the number of service requests initiated to the fourth network element based on the service request success rate between the fourth network element and the third network element includes: If the success rate of service requests between the fourth network element and the third network element is less than the second success rate threshold, the number of service requests initiated to the fourth network element will be adjusted to the minimum number of service requests.

17. The method according to any one of claims 14-16, characterized by, The method further includes: If the success rate of service requests between the fourth network element and the third network element changes from being greater than the first success rate threshold to being less than the first success rate threshold, a second message is sent to the operation and maintenance center, wherein the second message is used to indicate that there is an anomaly in the service path between the fourth network element and the third network element.

18. The method according to any one of claims 14-17, characterized by, The method further includes: When the success rate of service requests between the fourth network element and the third network element changes from less than the first success rate threshold to greater than or equal to the first success rate threshold, a third message is sent to the operation and maintenance center, wherein the third message is used to indicate that the service path between the fourth network element and the third network element has been restored to normal.

19. A communications device, characterized by The communication device includes: a module or unit for implementing the communication method as described in any one of claims 1-7, any one of claims 8-13, and any one of claims 14-18.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the communication method as claimed in any one of claims 1-7, any one of claims 8-13, and any one of claims 14-18.

21. A chip, characterized by Including the processor; The processor is configured to execute computer execution instructions to cause the device on which the chip is mounted to perform the communication method as claimed in any one of claims 1-7, any one of claims 8-13, or any one of claims 14-18.

22. The chip of claim 21, wherein, The chip also includes an interface circuit, which is used to receive computer execution instructions and transmit them to the processor.

23. A computer program product, said computer program product being executed by a computer using the communication method as claimed in any one of claims 1-7, any one of claims 8-13, or any one of claims 14-18.

24. A communications device, characterized by include: At least one processor and memory; The memory is used to store computer programs; The processor is configured to execute a computer program stored in the memory, such that the communication device performs the communication method as claimed in any one of claims 1-7, any one of claims 8-13, or any one of claims 14-18.

25. A communication system, characterized by The communication system includes a first network element and a second network element; The first network element is used to determine a second network element from a set of target network elements in the event of an unexpected failure in the first service process, wherein the set of target network elements includes one or more backup network elements of the first network element, and the cause of the unexpected failure does not include exceptions specified in the protocol or custom exceptions; and to migrate the first service process to the second network element. The second network element is used to initiate subsequent processes of the first service process.

26. The communication system according to claim 25, characterized in that, The second network element is further configured to determine whether the failure is an unexpected failure when the first service process fails on the second network element, wherein the cause of the unexpected failure does not include protocol-defined exceptions and custom exceptions, and the first service process is the service process that is migrated to the second network element after the unexpected failure occurs on the first network element; if the failure is an unexpected failure, and if it is determined that the first time interval between the two unexpected failures of the first service process occurring on the first network element and the second network element is less than or equal to the time interval threshold, then the first service process will no longer be migrated to the first network element.

27. A communication system, characterized by The communication system includes a third network element and a fourth network element; The third network element is used to determine that a first service request has unexpectedly failed during the process of initiating multiple service requests to the fourth network element, wherein the cause of the unexpected failure does not include protocol-defined exceptions and custom exceptions; and to adjust the number of service requests initiated to the fourth network element based on the service request success rate between the fourth network element and the third network element, wherein the number of service requests initiated to the fourth network element is positively correlated with the service request success rate, and the first service request is included in the multiple service requests.

Images