Request processing method, network node, and computer readable storage medium

Abstract

The present application provides a request processing method, a network node, and a computer readable storage medium. The method comprises: an I-CSCF receiving a service request for a second user equipment which is initiated by a first user equipment; on the basis of the service request, acquiring from a target network element address information of an S-CSCF registered by the second user equipment; and when acquisition of the address information fails, sending the service request to a plurality of S-CSCFs in a network, the plurality of S-CSCFs comprising the S-CSCF registered by the second user equipment.

Description

Request processing method, network node and computer-readable storage medium

[0001] Cross-references

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on April 3, 2024, with application number 202410403311.6 and invention name “Request processing method, network node and computer-readable storage medium”. The entire contents of the application are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of communication technology, and in particular to a request processing method, a network node, and a computer-readable storage medium. Background Art

[0004] Currently, in the voice network of the fourth generation mobile communication (4G), fifth generation mobile communication (5G) or sixth generation mobile communication (6G) based on the IP Multimedia Subsystem (IMS), when a first user device initiates a service request to a second user device, multiple network elements need to cooperate with each other to process and complete the service request. Taking the service request as a call request as an example, when the first user device initiates a call request to the second user device, the interrogating-call session control function (I-CSCF) on the second user device side (i.e., the called side) will first query multiple other network elements and obtain the address information of the serving call session control function (S-CSCF) registered by the second user device, and then send the service request to the S-CSCF corresponding to the address information, and the S-CSCF will execute the corresponding call service.

[0005] However, in the above service request processing flow, if an abnormality occurs in the link between the I-CSCF and other network elements (such as a flash disconnection or complete disconnection of the link), or an abnormality occurs in other network elements (such as overload, congestion, or equipment failure), then the I-CSCF will not be able to obtain the address information of the S-CSCF registered with the second user equipment, resulting in service failure and inability to provide normal service to the user. Summary of the Invention

[0006] The present application provides a request processing method, a network node, and a computer-readable storage medium.

[0007] In a first aspect, a request processing method is provided, which is applied to an I-CSCF, including: receiving a service request initiated by a first user equipment to a second user equipment; obtaining, based on the service request, address information of a service call session control function S-CSCF registered by the second user equipment from a target network element; and in the event that obtaining the address information from the target network element fails, sending the service request to multiple S-CSCFs in the network, the multiple S-CSCFs including the S-CSCF registered by the second user equipment.

[0008] In a second aspect, a request processing method is provided, which is applied to an S-CSCF, including: receiving a service request sent by an I-CSCF, where the service request is a service request from a first user device to a second user device, and the service request is sent by the I-CSCF when it fails to obtain the address information of the S-CSCF registered by the second user device from a target network element according to the service request; searching for user data of the second user device in locally registered user data according to the service request; and executing the service request when the user data of the second user device is found.

[0009] According to a third aspect, a network node is provided, comprising: a processor; and a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement the method as described in the first aspect or the second aspect.

[0010] In a fourth aspect, a computer-readable storage medium is provided. When the instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the method described in the first aspect or the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in this application or the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0012] FIG1 is a schematic diagram of a process for processing a call request in an IMS-based voice network in the related art;

[0013] FIG2 is a schematic diagram of a process flow of a request processing method according to an embodiment of the present application;

[0014] FIG3 is a schematic diagram of a POOL networking plan of multiple S-CSCFs in a voice network according to an embodiment of the present application;

[0015] FIG4 is a flow chart of a request processing method according to an embodiment of the present application;

[0016] FIG5 is a schematic diagram of a process of registering a user equipment with an S-CSCF according to an embodiment of the present application;

[0017] FIG6 is a flow chart of processing a service request in the case of an abnormal link between the I-CSCF and the SLF or an abnormal SLF according to an embodiment of the present application;

[0018] FIG7 is a flow chart of processing a service request in the case of an abnormal link between the I-CSCF and the HSS / UDM or an abnormal HSS / UDM according to an embodiment of the present application;

[0019] FIG8 is a flow chart of processing a service request in the case of an abnormal link between the I-CSCF and the DRA or an abnormal DRA according to an embodiment of the present application;

[0020] FIG9 is a schematic diagram of the structure of a network node according to an embodiment of the present application;

[0021] FIG10 is a schematic diagram of the structure of a request processing device according to an embodiment of the present application;

[0022] FIG11 is a schematic diagram of the structure of a request processing device according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] With the continued expansion of 4G commercialization and the continued expansion of 5G commercialization, mobile voice communications (4G Voice over Long-Term Evolution (VoLTE) and 5G Voice over New Radio (VoNR)) and packet system fallback (Evolved Packet System (EPS) fallback) face tremendous development opportunities, and the robustness requirements of voice networks are gaining increasing attention. However, IMS-based voice networks have a wide variety of network elements, and with the rapid growth of user base, the number of network elements is increasing, posing a severe challenge to the robustness of the entire network. Therefore, improving the robustness of voice networks has become a research priority.

[0024] Currently, in IMS-based 4G / 5G / 6G voice networks, when a first user device initiates a service request for a second user device, the I-CSCF on the second user device's side typically needs to interact with other network elements and obtain the address information of the S-CSCF with which the second user device is registered before processing the service request. For example, if the service request is a call request, the corresponding processing flow can be shown in Figure 1.

[0025] In Figure 1, when a first user equipment (i.e., the first UE (User Equipment) on the calling side) initiates a call request to a second user equipment (i.e., the second UE (called side)), the call request can be sent to the calling side's S-CSCF through the calling side's Proxy-Call Session Control Function (P-CSCF). The calling side's S-CSCF triggers the calling side's Application Server (AS) to execute the calling service and then sends the call request to the called side's I-CSCF. The I-CSCF on the called side obtains the address information of the S-CSCF registered with the second user equipment by querying the configured Home Subscriber Server (HSS) or Unified Data Management (UDM) (HSS is responsible for data subscription of VoLTE users, and UDM is responsible for data subscription of VoNR users), or queries the HSS / UDM corresponding to the second user equipment by querying the Subscription Locator Functional (SLF) (in the case where there are multiple HSS / UDMs in the voice network), and obtains the address information of the S-CSCF registered with the second user equipment through the HSS / UDM, or initiates a query request to the Diameter Routing Agent (DRA), and the DRA queries the corresponding HSS / UDM for the address information of the S-CSCF registered with the second user equipment. After obtaining the address information of the S-CSCF registered by the second user equipment, the I-CSCF on the called side sends the call request to the S-CSCF corresponding to the address information. The S-CSCF triggers the AS on the called side to execute the called service, and then sends the call request to the second user equipment through the P-CSCF on the called side to complete the call connection.

[0026] Based on the above service request processing flow, it can be seen that when the I-CSCF obtains the address information of the S-CSCF registered with the second user equipment, it needs to interact with one or more network elements among the SLF, DRA, HSS, and UDM. The SLF, DRA, HSS, and UDM are usually data center network elements with large user capacity and frequent message exchanges, resulting in a high probability of failure. For example, the link between the I-CSCF and the SLF, DRA, HSS, or UDM may be temporarily disconnected or completely disconnected, or the SLF, DRA, HSS, or UDM may be overloaded, congested, or have equipment failures. If the link between the I-CSCF and the SLF, DRA, HSS, or UDM fails, or if one or more network elements among the SLF, DRA, HSS, and UDM fail, the I-CSCF will be unable to obtain the address information of the S-CSCF registered with the second user equipment, resulting in service failure and the inability to provide normal service to the user.

[0027] The embodiment of the present application provides a request processing method, a network node, and a computer-readable storage medium. After an I-CSCF receives a service request for a second user device initiated by a first user device, if the I-CSCF fails to obtain the address information of the S-CSCF registered by the second user device from other network elements (such as one or more network elements of SLF, DRA, HSS, and UDM), the service request can be sent to multiple S-CSCFs in the network, including the S-CSCF registered by the second user device. In this way, by sending the service request to multiple S-CSCFs in the network, the S-CSCF registered by the second user device can be found, and the service request can be executed by the S-CSCF, thereby completing the service connection, avoiding service failure problems caused by link abnormalities between the I-CSCF and other network elements or other network element abnormalities, improving the robustness of the entire network, and ensuring that normal service is provided to the terminal.

[0028] In order to help those skilled in the art better understand the technical solutions of this application, the following will clearly and completely describe the technical solutions of this application in conjunction with the drawings of one or more embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0029] The terms "first," "second," and the like in this application and the claims are used to distinguish similar objects and are not used to describe a particular order or precedence. It should be understood that such terms are interchangeable where appropriate so that this application can be implemented in sequences other than those illustrated or described herein. In addition, the term "and / or" in this application and the claims refers to at least one of the connected objects, and the character " / " generally indicates that the connected objects are in an "or" relationship.

[0030] It should be noted that in each embodiment of the present application, the service request initiated by the first user equipment to the second user equipment may be a call request, an instant message request, a subscription message request (SUBSCRIBE), a reference message request (REFER) or a publish message request (PUBLISH). Of course, it may also be other service requests initiated by the first user equipment to the second user equipment and requiring the I-CSCF to query the address information of the S-CSCF registered by the second user equipment before it can be processed. The service requests will not be illustrated one by one here.

[0031] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0032] FIG2 is a flow chart of a request processing method according to an embodiment of the present application. The request processing method shown in FIG2 is applied to an I-CSCF. In other words, the request processing method shown in FIG2 can be executed by an I-CSCF (or software or hardware installed in an I-CSCF). The I-CSCF can be the I-CSCF on the second user equipment side. For example, when the service request is a call request initiated by a first user equipment to a second user equipment, the I-CSCF can be the I-CSCF on the called side. The request processing method shown in FIG2 includes the following steps.

[0033] Step S202: Receive a service request initiated by the first user equipment to the second user equipment.

[0034] When the first user equipment initiates a service request to the second user equipment, the I-CSCF (hereinafter abbreviated as I-CSCF) on the second user equipment side may receive the service request.

[0035] In some embodiments, when receiving a service request, the I-CSCF may receive it from the P-CSCF or S-CSCF on the first user equipment side. Specifically, when the first user equipment initiates a service request for the second user equipment, it may first send the service request to the P-CSCF on the first user equipment side, and then the P-CSCF on the first user equipment side forwards the service request to the I-CSCF. In this case, the I-CSCF may receive the service request from the P-CSCF on the first user equipment side. Alternatively, when the first user equipment initiates a service request for the second user equipment, it may first send the service request to the P-CSCF on the first user equipment side, and then the P-CSCF on the first user equipment side forwards the service request to the S-CSCF on the first user equipment side. Finally, the S-CSCF on the first user equipment side sends the service request to the I-CSCF. In this case, the I-CSCF may receive the service request from the S-CSCF on the first user equipment side.

[0036] Step S204: According to the service request, the address information of the S-CSCF where the second user equipment is registered is obtained from the target network element.

[0037] After receiving the service request, the I-CSCF may obtain the address information of the S-CSCF registered with the second user equipment from the target network element, so as to execute the service request based on the S-CSCF registered with the second user equipment and complete the service connection.

[0038] In some embodiments, when the I-CSCF obtains the address information of the S-CSCF registered with the second user equipment from the target network element, it may include the following steps: sending a first query request to the SLF, the first query request being used to request a query of the first network element corresponding to the second user equipment, the first network element including the HSS or UDM; sending a second query request to the first network element, the second query request being used to request a query of the address information of the S-CSCF registered with the second user equipment.

[0039] Specifically, when multiple HSSs or UDMs are deployed in the network, the I-CSCF can send a first query request to the SLF when querying the address information of the S-CSCF registered with the second user equipment. After the SLF receives the first query request, if the service request corresponds to a VoLTE service, that is, the second user equipment is a VoLTE user equipment, the HSS corresponding to the second user equipment is queried (the HSS is responsible for the data subscription of the VoLTE user). If the service request corresponds to a VoNR service, that is, the second user equipment is a VoNR user equipment, the UDM corresponding to the second user equipment is queried (the UDM is responsible for the data subscription of the VoNR user). After querying the HSS or UDM corresponding to the second user equipment, the SLF returns the query result to the I-CSCF. After receiving the query result returned by the SLF, the I-CSCF can send a second query request to the HSS or UDM corresponding to the second user equipment. After receiving the second query request, the HSS or UDM can query the address information of the S-CSCF registered with the second user equipment from the local subscription data, and after querying the address information, return the address information to the I-CSCF.

[0040] In the above process of obtaining the S-CSCF address information by querying the HSS or UDM through the SLF, if the I-CSCF receives the S-CSCF address information returned by the HSS or UDM, it indicates that the I-CSCF has successfully obtained the S-CSCF address information. If any of the following occurs: SLF response timeout, SLF failure, SLF error response, HSS or UDM response timeout, HSS or UDM failure, or HSS or UDM error response, it indicates that the I-CSCF has failed to obtain the S-CSCF address information.

[0041] In some embodiments, when the I-CSCF obtains the address information of the S-CSCF registered by the second user equipment from the target network element, it may include the following steps: sending a second query request to the first network element, the first network element includes an HSS or UDM, and the second query request is used to request to query the address information of the S-CSCF registered by the second user equipment.

[0042] Specifically, when the number of HSS or UDM deployed in the network is one, the I-CSCF can send a second query request directly to the HSS or UDM. For example, if the service request corresponds to a VoLTE service, that is, the second user device is a VoLTE user device, the I-CSCF can send a second query request directly to the HSS (HSS is responsible for the data contract of the VoLTE user). If the service request corresponds to a VoNR service, that is, the second user device is a VoNR user device, the I-CSCF can send a second query request directly to the UDM (UDM is responsible for the data contract of the VoNR user). After receiving the second query request, the HSS or UDM can query the address information of the S-CSCF registered by the second user device from the local contract data, and after querying the address information, return the address information to the I-CSCF.

[0043] In the above process of obtaining the S-CSCF address information by querying the HSS or UDM, if the I-CSCF receives the S-CSCF address information returned by the HSS or UDM, it indicates that the I-CSCF has successfully obtained the S-CSCF address information. If any of the following situations occurs: the HSS or UDM response times out, the HSS or UDM fails, or an error response is received from the HSS or UDM, it indicates that the I-CSCF has failed to obtain the S-CSCF address information.

[0044] In some embodiments, when the I-CSCF obtains the address information of the S-CSCF registered with the second user equipment from the target network element, it may include the following steps: sending a third query request to the DRA, the third query request being used to request querying the first network element for the address information of the S-CSCF registered with the second user equipment, the first network element including the HSS or UDM corresponding to the second user equipment.

[0045] Specifically, when DRA is deployed in the network, the I-CSCF can query the address information of the S-CSCF registered by the second user equipment through DRA. If the service request corresponds to a VoLTE service, that is, the second user equipment is a VoLTE user equipment, then after receiving the third query request, the DRA can query the address information of the S-CSCF registered by the second user equipment from the HSS, and return the queried address information to the I-CSCF (HSS is responsible for the data contract of the VoLTE user). If the service request corresponds to a VoNR service, that is, the second user equipment is a VoNR user equipment, then after receiving the third query request, the DRA can query the address information of the S-CSCF registered by the second user equipment from the UDM, and return the queried address information to the I-CSCF (HSS is responsible for the data contract of the VoNR user).

[0046] In the above process of querying the HSS or UDM through DRA to obtain the address information of the S-CSCF, if the I-CSCF receives the address information of the S-CSCF returned by the DRA, HSS or UDM, it indicates that the I-CSCF has successfully obtained the address information of the S-CSCF. If any of the following situations occurs: the DRA, HSS or UDM response times out; the DRA, HSS or UDM fails; or an error response is received from the DRA, HSS or UDM, it indicates that the I-CSCF has failed to obtain the address information of the S-CSCF.

[0047] After the I-CSCF obtains the address information of the S-CSCF registered with the second user equipment from the target network element, if the S-CSCF address information is successfully obtained, the service connection can be completed based on the existing service processing flow. For example, the I-CSCF can send a service request to the S-CSCF corresponding to the address information (i.e., the S-CSCF registered with the second user equipment). After receiving the service request, the S-CSCF can trigger the AS on the second user equipment side to execute the service request. The service request is then sent to the second user equipment via the P-CSCF on the second user equipment side, completing the service connection. If the S-CSCF address information cannot be obtained, S206 can be executed.

[0048] Step S206: Send a service request to multiple S-CSCFs in the network, where the multiple S-CSCFs include the S-CSCF where the second user equipment is registered.

[0049] The multiple S-CSCFs in the network may be all the S-CSCFs in the network, and these S-CSCFs must include the S-CSCF registered with the second user equipment. In the case where the I-CSCF fails to obtain the address information of the S-CSCF registered with the second user equipment, the service request may be sent to multiple S-CSCFs in the network. Since the multiple S-CSCFs include the S-CSCF registered with the second user equipment, by sending the service request to the multiple S-CSCFs, the S-CSCF registered with the second user equipment can be found, and the service request can be executed by the S-CSCF, thereby completing the service connection. This avoids the service failure problem caused by the I-CSCF being unable to obtain the address information of the S-CSCF registered with the second user equipment due to link abnormalities between the I-CSCF and other network elements or other network element abnormalities, thereby improving the robustness of the entire network and ensuring the provision of normal business services to the terminal.

[0050] In some implementations, before sending a service request to multiple S-CSCFs in the network, the I-CSCF may perform the following operations: adding indication information to the service request, where the indication information is used to instruct to search for user data of the second user equipment in locally registered user data.

[0051] Specifically, to facilitate multiple S-CSCFs in the network to respond to service requests after receiving them, the I-CSCF can add indication information to the service requests before sending them to the multiple S-CSCFs in the network, and then send the service requests carrying the indication information to the multiple S-CSCFs in the network. In this way, after receiving the service requests, the multiple S-CSCFs in the network, if they determine that the service requests carry the indication information, can respond to the service requests according to the indication information, namely, by searching for the user data of the second user equipment in the locally registered user data. This allows them to correctly respond to the service requests and ensure service continuity.

[0052] The indication information added by the I-CSCF in the service request can include various forms, which are not specifically limited here. Optionally, the indication information can be an indication identifier, such as an HSS fault release identifier. For multiple S-CSCFs in the network, when the received service request carries the HSS fault release identifier, the user data of the second user device can be searched in the locally registered user data to complete the service continuation. Taking the service request as a call request INVITE as an example, when the I-CSCF adds indication information in the call request, it can add an X-3GPP-Subject extension header to the original INVITE signaling, carrying the HSSBYPASS identifier (i.e., the HSS fault release identifier). The HSSBYPASS identifier is used to notify the S-CSCF to perform special processing, that is, to search for the user data of the second user device in the locally registered user data to complete the call service continuation.

[0053] In some implementations, when an I-CSCF sends a service request to multiple S-CSCFs in a network, it can send the service requests to multiple S-CSCFs in parallel to improve service processing efficiency. When an I-CSCF sends service requests to multiple S-CSCFs in a network in parallel and the service requests carry an HSS fail-safe flag, this can be considered to have triggered the I-CSCF's FORK call function. By using the FORK process to attempt to call S-CSCFs in the network in parallel, normal service continuity can be ensured.

[0054] In actual applications, due to the large user capacity of IMS networks, a large number of S-CSCFs are typically deployed in the network, with some locations even having dozens of S-CSCFs deployed. When an I-CSCF sends a service request to multiple S-CSCFs in the network, if the service request is sent to all S-CSCFs in the network, traffic consumption and performance costs will increase. To reduce traffic consumption and performance costs, in some embodiments, the I-CSCF sending a service request to multiple S-CSCFs in the network may include the following steps: sending the service request to some of the multiple S-CSCFs, including the S-CSCF with which the second user equipment is registered.

[0055] In this way, since service requests can be sent to some S-CSCFs in the network, the scope of S-CSCFs can be narrowed, reducing the number of S-CSCFs to which service requests need to be sent, thereby reducing traffic consumption and performance costs. In addition, since these S-CSCFs include the S-CSCF where the second user equipment is registered, sending service requests to these S-CSCFs can locate the S-CSCF where the second user equipment is registered, ensuring service continuity. Optionally, when sending service requests to some S-CSCFs among multiple S-CSCFs, the I-CSCF can send service requests to these S-CSCFs in parallel, thereby improving service processing efficiency.

[0056] To facilitate the I-CSCF sending service requests to some S-CSCFs in the network, in some implementations, multiple S-CSCFs in the network can be divided into multiple S-CSCF resource pools (which can also be represented as multiple POOL networks) according to location areas (for example, by province, city, and district). Different S-CSCF resource pools correspond to different location areas, and each S-CSCF resource group includes multiple S-CSCFs. Taking Figure 3 as an example, Figure 3 shows three S-CSCF resource pools, each of which includes multiple S-CSCFs. Assuming that these three S-CSCF resource pools are divided according to the prefecture-level cities in Jiangsu Province, the correspondence between each resource pool and the prefecture-level city area can be shown in Table 1.

[0057] Table 1

[0058] When registering with an S-CSCF, a user device can register with the S-CSCF resource pool corresponding to the location area of ​​the home location. For example, based on Table 1 above, assuming that the home location of the user device is Nanjing, when registering with the S-CSCF, it can register with an S-CSCF in S-CSCF POOL1. Assuming that the home location of the user device is Xuzhou, when registering with the S-CSCF, it can register with an S-CSCF in S-CSCF POOL2. Assuming that the home location of the user device is Nantong, when registering with the S-CSCF, it can register with an S-CSCF in S-CSCF POOL3. In this way, based on the home location of the second user device and multiple S-CSCF resource pools, the purpose of the I-CSCF sending service requests to some S-CSCFs in the network can be achieved.

[0059] Specifically, when the first user equipment initiates a service request for the second user equipment, the service request may include the home identifier of the second user equipment. In this way, when the I-CSCF sends the service request to some of the multiple S-CSCFs, the following steps may be included:

[0060] Determine a home location of the second user equipment according to the home location identifier; determine a target S-CSCF resource pool according to the home location of the second user equipment, where the location area corresponding to the target S-CSCF resource pool includes the home location of the second user equipment;

[0061] Send the service request to the S-CSCF in the target S-CSCF resource pool.

[0062] The location identifier of the second user device can represent the location of the second user device. The location of the second user device can be determined based on the location identifier of the second user device. Optionally, the location identifier can be the H-code of the second user device. In digital mobile phones, codes such as "H0H1H2H3" can be used to represent the regional identification code of the user's network access location, i.e., the H-code. These codes can represent specific regions, and mobile users in the same region may have multiple different H-codes. There is a correspondence between H-codes and regional areas. The city area corresponding to the user device's H-code is the user device's location. Taking Nanjing, Xuzhou, and Nantong in Table 1 above as examples, the correspondence between these cities and the user device's H-code can be shown in Table 2.

[0063] Table 2

[0064] Based on Table 2, if the H code of the second user device is 1380025, the home location of the second user device is Nanjing, if the H code of the second user device is 1380520, the home location of the second user device is Xuzhou, and if the H code of the second user device is 1380146, the home location of the second user device is Nantong.

[0065] After determining the home location of the second user equipment, a resource pool corresponding to the home location can be determined from multiple S-CSCF resource pools. This resource pool is the target S-CSCF resource pool. The target S-CSCF resource pool includes the S-CSCF with which the second user equipment is registered. Taking Table 2 above as an example, in combination with Table 1 above, the target S-CSCF resource pool determined based on the home location identifier (H code) can be as shown in Table 3.

[0066] Table 3

[0067] Based on Table 3, if the H code of the second user equipment is 1380025, the target S-CSCF resource pool is S-CSCF POOL1, if the H code of the second user equipment is 1380520, the target S-CSCF resource pool is S-CSCF POOL2, and if the H code of the second user equipment is 1380146, the target S-CSCF resource pool is S-CSCF POOL3.

[0068] After determining the target S-CSCF resource pool, the I-CSCF can send service requests to the S-CSCFs in the target S-CSCF resource pool (which can be sent in parallel), thereby narrowing the range of S-CSCFs to which the FORK call attempt is made and reducing the number of S-CSCFs to which the service request needs to be sent, thereby reducing traffic consumption and performance costs.

[0069] Optionally, in some implementations, a correspondence between an S-CSCF resource pool and a host within the resource pool may be established to facilitate locating an S-CSCF and sending a service request thereto. Taking the three S-CSCF resource pools shown in Table 1 as an example, a correspondence as shown in Table 4 may be established.

[0070] Table 4

[0071] It should be noted that, in actual applications, the I-CSCF may locally store the correspondence between the location area and the S-CSCF resource group (such as Table 1), the correspondence between the home location identifier of the user equipment and the home location (such as Table 2), and the correspondence between the S-CSCF POOL and the host in the POOL (such as Table 4). In this way, when the I-CSCF determines the target S-CSCF resource pool according to the home location identifier of the second user equipment, it can determine the target S-CSCF resource pool according to the locally stored correspondence.

[0072] The above examples illustrate how the I-CSCF determines some S-CSCFs from multiple S-CSCFs in the network and sends service requests to these S-CSCFs, i.e., determines the target S-CSCF resource pool based on the home location identifier of the second user equipment, and sends the service request to the S-CSCFs in the target S-CSCF resource pool. In other possible implementations, other methods may also be used. For example, all S-CSCFs in the network may be divided into multiple S-CSCF resource pools based on methods other than location areas (e.g., based on the traffic volume carried by the S-CSCFs, or a specified number of S-CSCFs may be divided into one S-CSCF resource pool, with the number of S-CSCFs in different resource pools being equal). For each user equipment in the network, after the user equipment successfully registers with the S-CSCF, the I-CSCF may establish a correspondence between the user equipment's device identifier and the S-CSCF resource group. In this way, when the first user equipment initiates a service request for the second user equipment, the service request can carry the device identifier of the second user equipment. When the I-CSCF sends the service request to the S-CSCF in the network, it can first determine the S-CSCF resource pool corresponding to the device identifier from multiple S-CSCF resource pools (including the S-CSCF registered with the second user equipment) based on the device identifier of the second user equipment, and then send the service request to the S-CSCF in the S-CSCF resource pool. In this way, the purpose of sending the service request to some S-CSCFs in the network can be achieved. Other possible implementation methods will not be described one by one as examples here.

[0073] In an embodiment of the present application, after receiving a service request from a first user device to a second user device, if the I-CSCF fails to obtain the address information of the S-CSCF registered with the second user device from other network elements (i.e., the target network element), the I-CSCF may send the service request to multiple S-CSCFs in the network, including the S-CSCF registered with the second user device. In this way, by sending the service request to multiple S-CSCFs in the network, the S-CSCF registered with the second user device can be found, and the service request can be executed by the S-CSCF, thereby completing the service connection, avoiding service failures caused by link abnormalities between the I-CSCF and other network elements or other network element abnormalities, improving the robustness of the entire network, and ensuring the provision of normal service to the terminal.

[0074] FIG4 is a flow chart of a request processing method according to an embodiment of the present application. The request processing method shown in FIG4 is applied to an S-CSCF. In other words, the request processing method shown in FIG4 can be executed by an S-CSCF (or software or hardware installed in an S-CSCF). The S-CSCF can be the S-CSCF on the second user equipment side. For example, when the service request is a call request initiated by a first user equipment to a second user equipment, the S-CSCF can be the S-CSCF on the called side. The request processing method shown in FIG4 includes the following steps.

[0075] Step S402: Receive a service request sent by the I-CSCF, where the service request is a service request from the first user equipment to the second user equipment.

[0076] When a first user device initiates a service request for a second user device, the I-CSCF can obtain the address information of the S-CSCF registered with the second user device from the target network element based on the service request. If the acquisition fails, the I-CSCF can send the service request to multiple S-CSCFs in the network. At this time, each of the multiple S-CSCFs can receive the service request sent by the I-CSCF. The specific implementation method of the I-CSCF obtaining the address information of the S-CSCF registered with the second user device from the target network element based on the service request, the specific implementation method of the I-CSCF confirming the failure to obtain the address information, and the specific implementation method of the I-CSCF sending the service request to multiple S-CSCFs in the network can all be referred to the specific implementation of the corresponding steps in the embodiment shown in Figure 2, and will not be repeated here.

[0077] Step S404: searching for user data of the second user equipment in locally registered user data according to the service request.

[0078] After receiving the service request, the S-CSCF may search for the user data of the second user equipment in the locally registered user data according to the service request to determine whether the second user equipment is locally registered, and further determine whether the S-CSCF is the S-CSCF registered by the second user equipment.

[0079] In some embodiments, to facilitate the S-CSCF's ability to respond to a service request after receiving it, i.e., to search for the user data of the second user device in locally registered user data based on the service request, the I-CSCF may, when sending a service request to the S-CSCF, include indication information in the service request. This indication information is used to instruct the S-CSCF to search for the user data of the second user device in locally registered user data. Thus, upon receiving the service request from the I-CSCF and determining that the service request carries the indication information, the S-CSCF may search for the user data of the second user device in locally registered user data based on the indication information to complete service continuation. The indication information may be an indication identifier, such as an HSS fault clearing identifier. If the S-CSCF determines that the service request sent by the I-CSCF carries the HSS fault clearing identifier, it may search for the user data of the second user device in locally registered user data to complete service continuation.

[0080] After the S-CSCF searches for the user data of the second user equipment in the locally registered user data, if the user data of the second user equipment is found, it can be indicated that the second user equipment is locally registered, the S-CSCF is the S-CSCF registered with the second user equipment, and the S-CSCF can execute S406. If the user data of the second user equipment is not found, it can be indicated that the second user equipment is not locally registered, the S-CSCF is not the S-CSCF registered with the second user equipment, and optionally, the S-CSCF can execute S408.

[0081] Step S406: Execute the service request.

[0082] When executing a service request, the S-CSCF can follow existing service processing procedures. For example, if the service request is a call request, the S-CSCF can trigger the AS on the called party to execute the called service. The S-CSCF then sends the call request to the second user equipment via the P-CSCF on the called party, completing the call connection.

[0083] In some implementations, when a service request carries indication information, the S-CSCF may first delete the indication information in the service request when executing the service request, and then execute the service request after deleting the indication information, so as to avoid the indication information affecting subsequent processes and ensure the normal execution of the service.

[0084] Step S408: Return a failure response to the I-CSCF.

[0085] When receiving the failure response, the I-CSCF may confirm that the S-CSCF is not the S-CSCF registered with the second user equipment.

[0086] In an embodiment of the present application, since the I-CSCF can send the service request to multiple S-CSCFs in the network when it fails to obtain the address information of the S-CSCF registered by the second user equipment, the S-CSCF registered by the second user equipment can be found, and the service request can be executed by the S-CSCF, thereby completing the service connection, avoiding service failure problems caused by link abnormalities between the I-CSCF and other network elements or abnormalities of other network elements, improving the robustness of the entire network, and ensuring that normal business services are provided to the terminal.

[0087] To facilitate understanding of the request processing method provided in the embodiments of the present application, some more specific implementation methods are described below as examples.

[0088] An IMS-based voice network includes multiple S-CSCF network elements. When a user initially registers, the I-CSCF can select one of the S-CSCFs for registration based on the HSS or UDM contracted capability set. When the user subsequently re-registers, the address of the S-CSCF where the user registered remains unchanged. The specific registration process can be shown in Figure 5. Figure 5 is a schematic diagram of the process for user equipment registration with an S-CSCF according to an embodiment of the present application, which may include the following steps.

[0089] Step 1: The UE's initial registration request is sent to the I-CSCF.

[0090] In some implementations, the registration request of the UE may be forwarded to the I-CSCF via the P-CSCF (not shown in FIG. 5 ).

[0091] Step 2: The I-CSCF sends a UAR query to the HSS / UDM via the SLF / DRA.

[0092] Among them, HSS is responsible for VoLTE user data contracting, and UDM is responsible for VoNR user data contracting.

[0093] Step 3: The I-CSCF receives the UAA response, which carries the S-CSCF capability set.

[0094] The capability set subscribed to in the HSS / UDM is typically configured by city / region, such as the long-distance area code of the user's number. The I-CSCF can configure the mapping between the capability set and the S-CSCF pool to ensure that users are registered in the S-CSCF pool corresponding to the city.

[0095] Step 4: The I-CSCF selects an S-CSCF in the S-CSCF POOL to which the user belongs for registration based on the local configuration and capability set.

[0096] Step 5: The S-CSCF sends a SAR to the HSS / UDM to query the user's subscription data.

[0097] Step 6: The S-CSCF receives the SAA response from the HSS / UDM.

[0098] Step 7: The S-CSCF returns a 200 OK to the I-CSCF.

[0099] Step 8: The I-CSCF sends a 200 OK to the UE.

[0100] For the second user equipment in the embodiment of the present application, the S-CSCF can be registered based on the steps in the embodiment shown in Figure 5. After the registration is successful (assuming that the second user equipment is registered with the S-CSCF2 in the S-CSCF POOL corresponding to the home location of the second user equipment), when the first user equipment initiates a service request for the second user equipment, the processing flow can be as shown in Figures 6 to 8.

[0101] Figure 6 is a flow chart of processing a service request in the case of an abnormal link between the I-CSCF and the SLF or an abnormal SLF according to an embodiment of the present application. The embodiment shown in Figure 6 includes the following steps.

[0102] Step 1: The I-CSCF receives a service request initiated by a first user equipment to a second user equipment.

[0103] Step 2: The I-CSCF sends a first query request to the SLF to query the HSS / UDM corresponding to the second user equipment.

[0104] When the I-CSCF determines that the SLF is online, it may send a first query request to the SLF. Optionally, the I-CSCF may set a timer for waiting for a response to determine whether the response of the SLF has timed out.

[0105] Step 3: The I-CSCF determines that the SLF response times out or receives an error response.

[0106] Step 4: The I-CSCF uses the H code of the second user equipment to analyze the home location of the second user equipment, and searches the local configuration for the S-CSCF POOL to which the second user equipment is registered based on the home location.

[0107] The local configuration here can be a correspondence table between the home location of the user equipment and the S-CSCF POOL. The correspondence table can be stored locally in the I-CSCF. The I-CSCF can determine the S-CSCF POOL corresponding to the home location of the second user equipment (that is, the S-CSCF POOL to which the second user equipment is registered) by querying the correspondence table.

[0108] Step 5: The I-CSCF adds the HSS BYPASS identifier to the service request and sends the service request in parallel FOKR to all S-CSCFs in the S-CSCF POOL.

[0109] FIG6 takes an example in which the S-CSCF POOL includes two S-CSCFs, namely S-CSCF1 and S-CSCF2, for explanation. S-CSCF2 is the S-CSCF registered with the second user equipment.

[0110] Step 6: The S-CSCF in the S-CSCF POOL searches for locally registered user data.

[0111] After receiving the service request, S-CSCF1 and S-CSCF2 in the S-CSCF POOL can search the locally registered user data to see whether the user data registered by the second user equipment is included if it determines that the service request carries the HSS BYPASS identifier, so as to determine whether the second user equipment is registered in this S-CSCF.

[0112] Step 7: S-CSCF1 returns a failure response to I-CSCF.

[0113] Since S-CSCF1 is not the S-CSCF registered with the second user equipment, S-CSCF1 cannot find the user data of the second user equipment locally. In the case of failing to find the user data of the second user equipment, S-CSCF1 may return a failure response to the I-CSCF.

[0114] Step 8: S-CSCF2 deletes the HSS BYPASS identifier and executes the service request.

[0115] Since S-CSCF2 is the S-CSCF where the second user device is registered, S-CSCF2 will locally locate the user data of the second user device. Once the user data is found, S-CSCF2 can execute the service request. When executing the service request, S-CSCF2 can first remove the HSS BYPASS identifier from the service request and then proceed with the service request according to the normal process.

[0116] The specific implementation of steps 1 to 8 shown in FIG6 can be found in the specific implementation of the corresponding steps in the embodiments shown in FIG2 to FIG4 , and will not be repeated here. It should be noted that steps 2 and 3 shown in FIG6 are optional steps. If the I-CSCF determines that the SLF is faulty or the link to the SLF is faulty, the process can proceed directly from step 1 to step 4. Alternatively, if the I-CSCF determines that the SLF is manually bypassed (e.g., a manually set SLF fault), the process can also proceed directly from step 1 to step 4.

[0117] Figure 7 is a flow chart of processing a service request in the case of an abnormal link between the I-CSCF and the HSS / UDM or an abnormal HSS / UDM according to an embodiment of the present invention. The embodiment shown in Figure 7 includes the following steps.

[0118] Step 1: The I-CSCF receives a service request initiated by a first user equipment to a second user equipment.

[0119] Step 2: The I-CSCF sends a first query request to the SLF to query the HSS / UDM corresponding to the second user equipment.

[0120] When the I-CSCF determines that the SLF is online, it may send a first query request to the SLF. Optionally, the I-CSCF may set a timer for waiting for a response to determine whether the response of the SLF has timed out.

[0121] Step 3: The I-CSCF receives a first query response sent by the SLF. The first query response carries the HSS / UDM corresponding to the second user equipment.

[0122] Optionally, if the I-CSCF sets a timer in step 2, then in step 3, upon receiving the first query response, the I-CSCF may stop the set timer.

[0123] Step 4: The I-CSCF sends a second query request to the HSS / UDM to query the address information of the S-CSCF where the second user equipment is registered.

[0124] When the I-CSCF determines that the HSS / UDM is online, the I-CSCF sends a second query request to the HSS / UDM. Optionally, the I-CSCF may set a timer for waiting for a response to determine whether the response from the HSS / UDM has timed out.

[0125] Step 5: The I-CSCF determines that the HSS / UDM response times out or receives an error response.

[0126] Step 6: The I-CSCF uses the H code of the second user equipment to analyze the home location of the second user equipment, and searches the local configuration for the S-CSCF POOL to which the second user equipment is registered based on the home location.

[0127] The local configuration here may be a correspondence table between the home location of the user equipment and the S-CSCF POOL. The correspondence table may be stored locally in the I-CSCF. The I-CSCF may determine the S-CSCF POOL corresponding to the home location of the second user equipment by querying the correspondence table.

[0128] Step 7: The I-CSCF adds the HSS BYPASS identifier to the service request and sends the service request in parallel FOKR to all S-CSCFs in the S-CSCF POOL.

[0129] FIG7 illustrates an example in which the S-CSCF POOL includes two S-CSCFs, namely S-CSCF1 and S-CSCF2. S-CSCF2 is the S-CSCF registered with the second user equipment.

[0130] Step 8: The S-CSCF in the S-CSCF POOL searches for locally registered user data.

[0131] After receiving the service request, S-CSCF1 and S-CSCF2 in the S-CSCF POOL can search the locally registered user data to see whether the user data registered by the second user equipment is included if it determines that the service request carries the HSS BYPASS identifier, so as to determine whether the second user equipment is registered in this S-CSCF.

[0132] Step 9: S-CSCF1 returns a failure response to I-CSCF.

[0133] Since S-CSCF1 is not the S-CSCF registered with the second user equipment, S-CSCF1 cannot find the user data of the second user equipment locally. In the case of failing to find the user data of the second user equipment, S-CSCF1 may return a failure response to the I-CSCF.

[0134] Step 10: S-CSCF2 deletes the HSS BYPASS identifier and executes the service request.

[0135] Since S-CSCF2 is the S-CSCF where the second user device is registered, S-CSCF2 will locally locate the user data of the second user device. Once the user data is found, S-CSCF2 can execute the service request. When executing the service request, S-CSCF2 can first remove the HSS BYPASS identifier from the service request and then proceed with the service request according to the normal process.

[0136] The specific implementation of steps 1 to 10 shown in FIG7 can refer to the specific implementation of the corresponding steps in the embodiments shown in FIG2 to FIG4 , and will not be repeated here. It should be noted that steps 4 and 5 shown in FIG7 are optional steps. If the I-CSCF determines that the HSS / UDM is faulty or the link to the HSS / UDM is faulty, the process can proceed directly from step 3 to step 6. Alternatively, if the I-CSCF determines that the HSS / UDM is manually bypassed (for example, an HSS / UDM fault is manually set), the process can also proceed directly from step 3 to step 6.

[0137] Figure 8 is a flow chart of processing a service request in the case of an abnormal link between the I-CSCF and the DRA or an abnormal DRA according to an embodiment of the present application. The embodiment shown in Figure 8 includes the following steps.

[0138] Step 1: The I-CSCF receives a service request initiated by a first user equipment to a second user equipment.

[0139] Step 2: The I-CSCF sends a third query request to the DRA, requesting the DRA to query the address information of the S-CSCF where the second user equipment is registered from the HSS / UDM.

[0140] When the I-CSCF determines that the DRA / HSS / UDM is online, the I-CSCF may send a third query request to the DRA. Optionally, the I-CSCF may set a timer for waiting for a response to determine whether the response from the DRAHSS / UDM has timed out.

[0141] Step 3: The I-CSCF determines that the DRA / HSS / UDM response times out or receives an error response.

[0142] Step 4: The I-CSCF uses the H code of the second user equipment to analyze the home location of the second user equipment, and searches the local configuration for the S-CSCF POOL to which the second user equipment is registered based on the home location.

[0143] The local configuration here may be a correspondence table between the home location of the user equipment and the S-CSCF POOL. The correspondence table may be stored locally in the I-CSCF. The I-CSCF may determine the S-CSCF POOL corresponding to the home location of the second user equipment by querying the correspondence table.

[0144] Step 5: The I-CSCF adds the HSS BYPASS identifier to the service request and sends the service request in parallel FOKR to all S-CSCFs in the S-CSCF POOL.

[0145] FIG8 illustrates an example in which the S-CSCF POOL includes two S-CSCFs, namely S-CSCF1 and S-CSCF2. S-CSCF2 is the S-CSCF registered with the second user equipment.

[0146] Step 6: The S-CSCF in the S-CSCF POOL searches for locally registered user data.

[0147] After receiving the service request, S-CSCF1 and S-CSCF2 in the S-CSCF POOL can search the locally registered user data to see whether the user data registered by the second user equipment is included if it determines that the service request carries the HSS BYPASS identifier, so as to determine whether the second user equipment is registered in this S-CSCF.

[0148] Step 7: S-CSCF1 returns a failure response to I-CSCF.

[0149] Since S-CSCF1 is not the S-CSCF registered with the second user equipment, S-CSCF1 cannot find the user data of the second user equipment locally. In the case of failing to find the user data of the second user equipment, S-CSCF1 may return a failure response to the I-CSCF.

[0150] Step 8: S-CSCF2 deletes the HSS BYPASS identifier and executes the service request.

[0151] Since S-CSCF2 is the S-CSCF where the second user device is registered, S-CSCF2 will locally locate the user data of the second user device. Once the user data is found, S-CSCF2 can execute the service request. When executing the service request, S-CSCF2 can first remove the HSS BYPASS identifier from the service request and then proceed with the service request according to the normal process.

[0152] The specific implementation of steps 1 to 8 shown in FIG8 can refer to the specific implementation of the corresponding steps in the embodiments shown in FIG2 to FIG4 , and will not be repeated here. It should be noted that steps 2 and 3 shown in FIG8 are optional steps. If the I-CSCF determines that the DRA / HSS / UDM is faulty or the link to the DRA / HSS / UDM is faulty, the process can proceed directly from step 1 to step 4. Alternatively, if the I-CSCF determines that the DRA / HSS / UDM is manually bypassed (for example, a DRA / HSS / UDM fault is manually set), the process can also proceed directly from step 1 to step 4.

[0153] As can be seen from Figures 6 to 8 above, if the I-CSCF cannot obtain the address information of the S-CSCF with which the second user device is registered from the SLF / DRA / HSS / UDM, it can determine the city / region to which the second user device belongs based on the user number H code of the second user device. Based on the city / region, it determines the S-CSCF POOL to which the second user device is registered. It then sends a service request in parallel to all S-CSCFs within the S-CSCF POOL, i.e., it FORKs all S-CSCFs within the POOL in parallel, and carries the HSS BYPASS identifier (HSS failover identifier) ​​in the service request. For the S-CSCFs within the POOL, if it determines that the service request carries the HSS BYPASS identifier, it searches locally for the registration data of the second user device. If the registration data for the second user device is not locally available, a failure response is returned to the I-CSCF. If the registration data for the second user device is locally available, the service request is processed normally. In this way, by FORK-polling all S-CSCFs within the POOL, the S-CSCF with which the second user device is registered can be found, ensuring normal service continuity.

[0154] Based on the technical solution provided in the embodiment of the present application, after receiving a service request from a first user device to a second user device, the I-CSCF can send the service request to multiple S-CSCFs in the network if it fails to obtain the address information of the S-CSCF registered by the second user device from other network elements (i.e., the target network element). The multiple S-CSCFs include the S-CSCF registered by the second user device. In this way, by sending the service request to multiple S-CSCFs in the network, the S-CSCF registered by the second user device can be found, and the service request can be executed by the S-CSCF, thereby completing the connection of the service request, avoiding service failure problems caused by link abnormalities between the I-CSCF and other network elements or abnormalities of other network elements, improving the robustness of the entire network, and ensuring that normal service is provided to the terminal. In addition, since service requests can be sent in parallel to multiple S-CSCFs in the network, service processing efficiency can be improved. Since the service request can be sent to some S-CSCFs in the network, for example, the target S-CSCF resource pool corresponding to the home location of the second user equipment is determined according to the home location identifier of the second user equipment, and the service request is sent only to the S-CSCFs in the resource pool, the scope of the Fork call attempt can be reduced, thereby reducing traffic consumption and performance costs.

[0155] The foregoing description describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0156] Figure 9 is a schematic diagram of the structure of a network node according to an embodiment of the present application. Referring to Figure 9 , at the hardware level, the network node includes a processor, and optionally an internal bus, a network interface, and a memory. The memory may include internal memory, such as high-speed random access memory (RAM), and may also include non-volatile memory, such as at least one disk storage device. Of course, the network node may also include hardware required for other services.

[0157] The processor, network interface, and memory can be interconnected via an internal bus, such as an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. These buses can be classified as address buses, data buses, and control buses. For ease of illustration, FIG9 shows only one bidirectional arrow, but this does not imply that there is only one bus or only one type of bus.

[0158] The memory is used to store programs. Specifically, the program may include program code, which includes computer operating instructions. The memory may include internal memory and non-volatile memory, and provides instructions and data to the processor.

[0159] The processor reads the corresponding computer program from the non-volatile memory into the internal memory and then runs it, forming a request processing device at the logical level. The processor executes the program stored in the memory and is specifically configured to perform the following operations: receive a service request initiated by a first user equipment for a second user equipment; obtain address information of a Serving Call Session Control Function (S-CSCF) registered with the second user equipment from a target network element based on the service request; and, if obtaining the address information from the target network element fails, send the service request to multiple S-CSCFs in the network, including the S-CSCF registered with the second user equipment.

[0160] Or, used to perform the following operations: receiving a service request sent by an I-CSCF, where the service request is a service request from a first user device to a second user device, and the service request is sent by the I-CSCF when it fails to obtain the address information of the S-CSCF registered by the second user device from the target network element according to the service request; searching for user data of the second user device in locally registered user data according to the service request; and executing the service request when the user data of the second user device is found.

[0161] The method performed by the request processing device disclosed in the embodiment shown in FIG9 of the present application can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the method can be completed by hardware integrated logic circuits in the processor or by software instructions. The processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be 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. The methods, steps, and logic block diagrams disclosed in this application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0162] The network node can also execute the methods of Figures 2 and 4 and implement the functions of the request processing device in the embodiments shown in Figures 2 and 4, which will not be described in detail in this application.

[0163] Of course, in addition to software implementation, the network node of this application does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0164] The present application also proposes a computer-readable storage medium, which stores one or more programs, which include instructions. When the instructions are executed by a portable electronic device including multiple application programs (such as the above-mentioned network node), the portable electronic device can execute the method of the embodiments shown in Figures 2 and 4, and is specifically used to perform the following operations: receiving a service request for a second user device initiated by a first user device; obtaining address information of the service call session control function S-CSCF registered by the second user device from a target network element according to the service request; and in the event that the address information fails to be obtained from the target network element, sending the service request to multiple S-CSCFs in the network, wherein the multiple S-CSCFs include the S-CSCF registered by the second user device.

[0165] Or, used to perform the following operations: receiving a service request sent by an I-CSCF, where the service request is a service request from a first user device to a second user device, and the service request is sent by the I-CSCF when it fails to obtain the address information of the S-CSCF registered by the second user device from the target network element according to the service request; searching for user data of the second user device in locally registered user data according to the service request; and executing the service request when the user data of the second user device is found.

[0166] FIG10 is a schematic diagram of the structure of a request processing apparatus 100 according to an embodiment of the present application. Referring to FIG10 , in a software implementation, the request processing apparatus 100 may include: a receiving module 101, an obtaining module 102, and a sending module 103, wherein: the receiving module 101 receives a service request initiated by a first user equipment for a second user equipment; the obtaining module 102 obtains, from a target network element, address information of a Serving Call Session Control Function (S-CSCF) registered with the second user equipment based on the service request; and the sending module 103, if acquisition of the address information from the target network element fails, sends the service request to multiple S-CSCFs in the network, including the S-CSCF registered with the second user equipment.

[0167] In some embodiments, the device 100 further includes an adding module, which adds indication information to the service request before the sending module 103 sends the service request to multiple S-CSCFs in the network, wherein the indication information is used to indicate that the user data of the second user device is searched in the locally registered user data.

[0168] In some implementations, the sending module 103 sending the service request to multiple S-CSCFs in the network includes: sending the service request to the multiple S-CSCFs in parallel.

[0169] In some implementations, the sending module 103 sends the service request to multiple S-CSCFs in the network, including: sending the service request to some S-CSCFs among the multiple S-CSCFs, where the some S-CSCFs include the S-CSCF where the second user equipment is registered.

[0170] In some embodiments, the service request carries the home location identifier of the second user equipment, the multiple S-CSCFs are divided into multiple S-CSCF resource pools according to location areas, each S-CSCF resource group includes multiple S-CSCFs, and different S-CSCF resource pools correspond to different location areas; the sending module 103 sends the service request to some S-CSCFs in the multiple S-CSCFs, including: determining the home location of the second user equipment according to the home location identifier; determining the target S-CSCF resource pool according to the home location of the second user equipment, the location area corresponding to the target S-CSCF resource pool includes the home location of the second user equipment; and sending the service request to the S-CSCF in the target S-CSCF resource pool.

[0171] The request processing device 100 provided in this application can also execute the method of Figure 2 and realize the functions of the request processing device 100 in the embodiment shown in Figure 2, which will not be repeated in this application.

[0172] FIG11 is a schematic diagram of the structure of a request processing device 110 according to an embodiment of the present application. Referring to FIG11 , in a software implementation, the request processing device 110 may include: a receiving module 111, a search module 112, and a processing module 113, wherein: the receiving module 111 receives a service request sent by an I-CSCF, wherein the service request is a service request from a first user equipment to a second user equipment, and the service request is sent by the I-CSCF when it fails to obtain the address information of the S-CSCF registered with the second user equipment from the target network element according to the service request; the search module 112 searches for the user data of the second user equipment in locally registered user data according to the service request; and the processing module 113 executes the service request when the user data of the second user equipment is found.

[0173] In some embodiments, the service request carries indication information; the search module 112 searches for user data of the second user device in the locally registered user data according to the service request, including: searching for user data of the second user device in the locally registered user data according to the indication information.

[0174] In some implementations, the processing module 113 executes the service request, including: executing the service request after deleting the indication information in the service request.

[0175] In some implementations, the apparatus 110 further includes a sending module, which returns a failure response to the I-CSCF if the searching module 112 fails to find the user data of the second user equipment.

[0176] The request processing device 110 provided in this application can also execute the method of Figure 4 and realize the functions of the request processing device 110 in the embodiment shown in Figure 4, which will not be repeated in this application.

[0177] In short, the above description is only a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

[0178] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0179] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0180] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0181] The various embodiments in this application are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the system embodiment is generally similar to the method embodiment, so the description is relatively simple. For relevant parts, refer to the partial description of the method embodiment.

Claims

1. A request processing method, applied to querying a call session control function (I-CSCF), comprising: receiving a service request initiated by the first user equipment to the second user equipment; Obtaining, from the target network element, address information of a serving call session control function (S-CSCF) with which the second user equipment is registered, according to the service request; In case that obtaining the address information from the target network element fails, the service request is sent to multiple S-CSCFs in the network, where the multiple S-CSCFs include the S-CSCF with which the second user equipment is registered.

2. The method according to claim 1, before sending the service request to multiple S-CSCFs in the network, the method further comprises: Instruction information is added to the service request, where the instruction information is used to instruct to search for the user data of the second user equipment in the locally registered user data.

3. The method according to claim 1, wherein sending the service request to multiple S-CSCFs in the network comprises: The service request is sent to the multiple S-CSCFs in parallel.

4. The method according to claim 1, wherein sending the service request to multiple S-CSCFs in the network comprises: The service request is sent to some S-CSCFs among the multiple S-CSCFs, where the some S-CSCFs include the S-CSCF with which the second user equipment is registered.

5. The method according to claim 4, wherein the service request carries a home location identifier of the second user equipment, the multiple S-CSCFs are divided into multiple S-CSCF resource pools according to location areas, each S-CSCF resource group includes multiple S-CSCFs, and different S-CSCF resource pools correspond to different location areas; The sending the service request to some S-CSCFs among the multiple S-CSCFs includes: determining a home location of the second user equipment according to the home location identifier; Determine a target S-CSCF resource pool according to the home location of the second user equipment, where the location area corresponding to the target S-CSCF resource pool includes the home location of the second user equipment; The service request is sent to the S-CSCF in the target S-CSCF resource pool.

6. A request processing method, applied to an S-CSCF, comprising: receiving a service request sent by an I-CSCF, where the service request is a service request from a first user equipment to a second user equipment, and the service request is sent by the I-CSCF when acquiring, from a target network element according to the service request, address information of an S-CSCF with which the second user equipment is registered fails; searching for user data of the second user equipment in locally registered user data according to the service request; When the user data of the second user equipment is found, the service request is executed.

7. The method according to claim 6, wherein the service request carries indication information; and searching for user data of the second user equipment in locally registered user data according to the service request comprises: Search the locally registered user data for the second user equipment according to the instruction information.

8. The method according to claim 7, wherein executing the service request comprises: After deleting the indication information in the service request, executing the service request.

9. A network node, comprising: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the method according to any one of claims 1 to 8. 10 . A computer-readable storage medium, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the method according to claim 1 .

Images