Service management method, system, electronic device, and storage medium

Abstract

This invention provides a service management method, system, electronic device, and storage medium, belonging to the field of core network technology. The method includes: receiving a service registration request sent by a first network function entity, wherein the service registration request carries configuration information including the network element type of the first network function entity; determining the target parameter category that the first network function entity needs to carry during registration based on the network element type; verifying the configuration information; and rejecting the service registration request and returning a registration failure response when it is determined that the configuration information does not contain valid parameter information corresponding to the target parameter category. This invention prevents network function entities that do not carry key parameters from completing registration by performing differentiated key parameter verification on the configuration information based on the network element type during the service registration process. This avoids users being incorrectly redirected due to missing key parameters during subsequent service discovery, thereby improving the reliability and accuracy of the service registration mechanism.

Description

Technical Field

[0001] This invention relates to the field of core network technology, and in particular to a service management method, system, electronic device, and storage medium. Background Technology

[0002] In the service-oriented architecture of the 5G core network, each network function entity needs to register its services with the network storage function entity so that other network function entities can discover services through the network storage function entity, thereby establishing service invocation and signaling interaction.

[0003] In the existing service registration and discovery process, when a network function entity initiates registration with a network storage function entity, it registers its configuration information with the network storage function entity. According to existing communication protocols, various network function entities are allowed to omit specific key identification parameters when registering for services. For example, number segment-type network elements are allowed to omit number segment range information when registering with a network storage function entity, and location-type network elements are allowed to omit tracking area identifier list information during registration.

[0004] Because current technology allows network function entities (NFEntities) to complete service registration even without key identification parameters, these NFEntities are subsequently returned to service consumer NFEntities as unconditional wildcard matches during the service discovery process. If such NFEntities, lacking key parameters, successfully register, a large number of user requests will be incorrectly redirected to non-homed NFEntities, causing network-wide service routing anomalies and processing failures, thus affecting the reliability and accuracy of the service registration mechanism. Summary of the Invention

[0005] This invention provides a service management method, system, electronic device, and storage medium to address the deficiencies in the prior art and improve the reliability and accuracy of the service registration mechanism in the 5G core network.

[0006] This invention provides a service management method, comprising the following steps: Receive a service registration request sent by a first network function entity, wherein the service registration request carries configuration information of the first network function entity, and the configuration information includes the network element type of the first network function entity; Based on the network element type, the target parameter category that the first network function entity needs to carry during registration is determined, wherein there is a preset correspondence between the target parameter category and the network element type; The configuration information is verified, and if it is determined that the configuration information does not contain valid parameter information corresponding to the target parameter category, the service registration request is rejected, and a registration failure response is returned to the first network function entity.

[0007] According to a service management method provided by the present invention, the method further includes: Receive a service discovery request sent by a second network function entity, wherein the service discovery request carries discovery condition parameters; Based on the discovery condition parameters, multiple candidate network function entities are obtained by matching from the configuration information of each stored network function entity. Extract the region identifier and province identifier from the instance identifier of each candidate network functional entity; When it is determined that there are differences in the region identifier or province identifier between the candidate network functional entities, the region identifier and province identifier of each candidate network functional entity are compared with the region identifier and province identifier of the second network functional entity; From the plurality of candidate network function entities, candidate network function entities whose region identifier and province identifier are the same as those of the second network function entity are selected and returned as service discovery results.

[0008] The present invention also provides a service management system, comprising the following modules: The first processing module is configured to receive a service registration request sent by a first network function entity, wherein the service registration request carries configuration information of the first network function entity, and the configuration information includes the network element type of the first network function entity. The second processing module is used to determine the target parameter category that the first network function entity needs to carry during registration based on the network element type, wherein the target parameter category and the network element type have a preset correspondence. The third processing module is used to verify the configuration information, and when it is determined that the configuration information does not contain valid parameter information corresponding to the target parameter category, it rejects the service registration request and returns a registration failure response to the first network function entity.

[0009] According to the service management system provided by the present invention, it further includes: The first processing module is further configured to receive a service discovery request sent by the second network function entity, wherein the service discovery request carries discovery condition parameters; The fourth processing module is used to match multiple candidate network functional entities from the configuration information of each network functional entity stored in the database according to the discovery condition parameters. The fifth processing module is used to extract the region identifier and province identifier from the instance identifiers of each of the candidate network functional entities; The sixth processing module is used to compare the region identifier and province identifier of each candidate network functional entity with the region identifier and province identifier of the second network functional entity when it is determined that there are differences between the region identifiers or province identifiers of the candidate network functional entities. The seventh processing module is used to filter out candidate network function entities from the plurality of candidate network function entities whose region identifier and province identifier are the same as those of the second network function entity, and return them as service discovery results.

[0010] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the service management method described above.

[0011] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the service management method as described above.

[0012] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the service management method as described above.

[0013] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: By determining the corresponding target parameter category based on the network element type of the first network functional entity and verifying whether the configuration information contains valid parameter information corresponding to the target parameter category, differentiated key parameter verification is performed on network functional entities of different network element types during the service registration process. By rejecting service registration requests when the configuration information does not contain valid parameter information, network functional entities without key parameters are prevented from registering in the network storage functional entity, ensuring that all configuration information stored in the network storage functional entity contains valid key parameters. By preventing configuration information lacking key parameters from entering the network storage functional entity at the source of service registration, the erroneous configuration of a single network functional entity is prevented from spreading to the entire network through the service discovery mechanism, thus improving the reliability and accuracy of the service registration mechanism in the 5G core network. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of a scenario involving incorrect traffic redirection provided by the present invention.

[0016] Figure 2 This is one of the flowcharts illustrating the service management method provided by the present invention.

[0017] Figure 3 This is the second flowchart of the service management method provided by the present invention.

[0018] Figure 4 This is a schematic diagram of the service management system provided by the present invention.

[0019] Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0021] It should be noted that in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The terms "upper," "lower," etc., indicating orientation or positional relationships according to the accompanying drawings, are only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the system or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0022] The terms "first," "second," etc., used in this invention are used to distinguish similar objects, not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0023] The following is combined Figures 1 to 5 This invention describes the service management methods, systems, electronic devices, storage media, and computer program products provided by this invention.

[0024] This application provides a service management method applied to a Service-Based Architecture (SBA) scenario in a 5G core network. In a SBA, each network function entity needs to register its services with a Network Repository Function (NRF) entity so that other network function entities can discover services through the NRF entity and find suitable target network function entities. The service management method described in this application is executed by the NRF entity. In actual deployment, the functionality of the NRF entity is carried out by servers, processors, or network devices with data processing capabilities deployed in the core network. In the following embodiments, the NRF entity is selected as the execution entity for description.

[0025] In the existing 3rd Generation Partnership Project (3GPP) technical specification TS29.510, various network function entities are allowed to omit key parameter information associated with their own network element type when registering with network storage function entities. For example, number segment-based network function entities such as Unified Data Management (UDM), Authentication Server Function (AUSF), and Policy Control Function (PCF) are allowed to omit number segment information during registration; location-based network function entities such as Access and Mobility Management Function (AMF) and Session Management Function (SMF) are allowed to omit the Tracking Area Identity (TAI) list during registration; and Binding Support Function (BSF) entities are allowed to omit the user Internet Protocol (IP) address list during registration. The absence of these key parameters will lead to incorrect traffic routing during service discovery, resulting in service failure.

[0026] To address the aforementioned problems, this application proposes a service management method. The following embodiments, in conjunction with specific application scenarios, demonstrate this method. Figure 1 The technical solutions of the embodiments of this application will be described in detail.

[0027] Reference Figure 1 , Figure 1 This is a schematic diagram illustrating a scenario of erroneous traffic redirection provided by the present invention. In this embodiment, a 5G core network deployed across regions is used as the application scenario for illustration. Figure 1 As shown, in this application scenario, the network deploys two data centers (DCs), namely the first data center DC1 and the second data center DC2.

[0028] The first data center deploys the first unified data management entity UDM1, the first network storage function entity NRF1, the first access and mobility management function entity AMF1, and the session management function entity SMF. The first unified data management entity is configured with two number segments, namely the number segment "138010 10000~19999" and the number segment "138010 20000~29999".

[0029] The second data center deploys the second unified data management entity UDM2, the third unified data management entity UDM3, the second network storage function entity NRF2, the second access and mobility management function entity AMF2, and the session management function entity SMF. The second unified data management entity is configured with two number ranges: "138010 00000~99999" and "138011 20000~29999". The third unified data management entity has no number range configuration; that is, no number range information is configured for the third unified data management entity.

[0030] Under existing technology, because the 3rd Generation Partnership Project (3GPP) technical specifications allow network function entities with number ranges to register with network storage function entities without carrying the number range, the third unified data management entity sends a service registration request to the second network storage function entity without carrying any Subscription Permanent Identifier (SUPI) range or Generic Public Subscription Identifier (GPSI) range. The second network storage function entity accepts the service registration request and stores the configuration information of the third unified data management entity locally. According to the agreement, a network function entity without a number range can be used as a service discovery result when using any number as a discovery criterion during service discovery. Therefore, if... Figure 1 As indicated by the annotation "② Error redirection 2", when the second access and mobility management function entity in the second data center performs service discovery using any user's subscribed permanent identifier, it will return the third unified data management entity as the discovery result, causing all users in the second data center to be incorrectly redirected to the third unified data management entity, resulting in damage to the entire network services of the second data center.

[0031] Furthermore, such as Figure 1 As shown, there is a cross-data center communication connection between the first network storage function entity and the second network storage function entity. When the first access and mobility management function entity in the first data center initiates a cross-regional service discovery request, and the first network storage function entity queries the second network storage function entity for the unified data management entity, the second network storage function entity will also return the third unified data management entity, which does not carry the number range, as the discovery result. Figure 1 As indicated by the annotation "① Error Redirection 1", the first access and mobility management function entity in the first data center incorrectly selects the third unified data management entity, causing service disruptions for all users in the first data center. Consequently, the misconfiguration of this single network function entity, the third unified data management entity, spreads throughout the entire network, resulting in service disruptions across the entire network.

[0032] Based on the above application scenarios, referring to Figure 2 , Figure 2 This is one of the flowcharts illustrating the service management method provided by this invention. The service management method described in this application includes the following steps: Step 110: Receive a service registration request sent by the first network function entity. The service registration request carries the configuration information of the first network function entity, including the network element type of the first network function entity.

[0033] In the service-oriented architecture of the 5G core network, when a network function entity (NF) needs to provide services to other NF entities in the network, the first NF entity first sends a service registration request to the network storage function entity. The service registration request carries the configuration information of the first NF entity, which is organized in the form of a network function profile (NF Profile). The NF Profile contains the network element type of the first NF entity, which identifies the functional role the first NF entity plays in the core network. Specific values ​​for the network element type include, but are not limited to, unified data management type, authentication server function type, policy control function type, access and mobility management function type, session management function type, and binding support function type.

[0034] exist Figure 1 In the application scenario shown, the third unified data management entity, acting as the first network function entity, sends a service registration request to the second network storage function entity. The configuration information carried in the service registration request includes a network element type of unified data management, while the subscribed permanent identifier range field and the general public subscribed identifier range field in the configuration information are both empty.

[0035] Step 120: Based on the network element type, determine the target parameter category that the first network function entity needs to carry during registration, wherein there is a preset correspondence between the target parameter category and the network element type.

[0036] Upon receiving a service registration request, the network storage function entity extracts the network element type of the first network function entity from the configuration information and determines the target parameter categories that the first network function entity needs to carry during registration based on the network element type. There is a preset correspondence between the target parameter categories and the network element types. The network storage function entity maintains a mapping table between network element types and target parameter categories in advance, which records the parameter categories that different network element types must carry during registration.

[0037] Specifically, when the network element type is a number segment-type network function entity, the target parameter category is the number segment parameter category. Number segment-type network function entities include unified data management entities, authentication server function entities, and policy control function entities. The number segment parameter category requires that the configuration information must include either the subscribed permanent identifier range information or the general public subscribed identifier range information. When the network element type is a location-type network function entity, the target parameter category is the location parameter category. Location-type network function entities include access and mobility management function entities and session management function entities. The location parameter category requires that the configuration information must include the tracking area identifier list information. When the network element type is a binding support function entity, the target parameter category is the address parameter category. The address parameter category requires that the configuration information must include the user's Internet Protocol address list information.

[0038] exist Figure 1 In the application scenario shown, after receiving the service registration request from the third unified data management entity, the second network storage function entity extracts the network element type as the unified data management type from the configuration information. The second network storage function entity queries the preset mapping table to determine that the target parameter category corresponding to the unified data management type is the number segment parameter category. That is, the third unified data management entity must carry the contracted permanent identifier range information or the general public contracted identifier range information when registering.

[0039] The above mapping table is one implementation of this application. In other implementations, the correspondence between network element type and target parameter category can also be achieved through preset rules, configuration files or database records, as long as the corresponding target parameter category can be accurately determined according to the network element type.

[0040] Step 130: Verify the configuration information, and if it is determined that the configuration information does not contain valid parameter information corresponding to the target parameter category, reject the service registration request and return a registration failure response to the first network function entity.

[0041] After determining the target parameter category, the network storage function entity verifies the configuration information submitted by the first network function entity. The verification process is as follows: the network storage function entity checks whether the configuration information contains valid parameter information corresponding to the target parameter category. Valid parameter information refers to parameter information in the configuration information that contains parameter fields corresponding to the target parameter category, and whose values ​​are not empty, have a valid format, and have actual business significance.

[0042] When the network storage function entity determines that the configuration information does not contain valid parameter information corresponding to the target parameter category, the network storage function entity rejects the service registration request, does not store the configuration information of the first network function entity in its local database, and returns a registration failure response to the first network function entity. The registration failure response carries a status code indicating that the request is invalid. In one embodiment, the registration failure response carries a status code of "400 Bad Request," used to notify the first network function entity that the service registration request was rejected due to parameter validation failure. In another embodiment, the registration failure response may also carry specific failure reason description information, such as indicating missing permanent identifier range information or missing tracking area identifier list information, so that the first network function entity can correct the configuration according to the failure reason and re-initiate registration after receiving the registration failure response.

[0043] When the network storage function entity determines that the configuration information contains valid parameter information corresponding to the target parameter category, the network storage function entity accepts the service registration request, stores the configuration information of the first network function entity in the local database of the network storage function entity, and returns a registration success response to the first network function entity.

[0044] exist Figure 1 In the application scenario shown, the second network storage function entity verifies the configuration information of the third unified data management entity. Since both the "Subscription Permanent Identifier Range" and "General Public Subscription Identifier Range" fields in the third unified data management entity's configuration information are empty, the second network storage function entity determines that the configuration information does not contain valid parameter information corresponding to the number segment parameter category. Therefore, the second network storage function entity rejects the service registration request from the third unified data management entity and returns a registration failure response with a "400 Bad Request" status code. Through this verification mechanism, invalid configuration information from the third unified data management entity will not be stored in the second network storage function entity, thus avoiding... Figure 1 The issue marked "② Error Redirection 2" indicates that all users in the second data center were incorrectly redirected to the third unified data management entity, which also avoids... Figure 1 The issue of the third unified data management entity being incorrectly returned due to cross-regional service discovery in the first data center, marked "① Error redirection 1", prevents the misconfiguration of a single network function entity from spreading to the entire network.

[0045] According to the technical solution described in this application, after receiving a service registration request from a first network function entity, the network storage function entity determines the corresponding target parameter category based on the network element type of the first network function entity, and verifies whether the configuration information contains valid parameter information corresponding to the target parameter category. If the verification fails, the service registration request is rejected. This solution strictly controls the service registration process from the entry point, preventing network function entities without key parameters from registering with the network storage function entity. It prevents, from the source, problems such as incorrect user redirection, service failures, and the spread of misconfigurations from a single network function entity to the entire network due to missing key parameters, thus improving the reliability and accuracy of the service registration and service discovery mechanism in the 5G core network.

[0046] Based on the above embodiments, this embodiment further provides a legality verification mechanism for service update requests.

[0047] In the service-oriented architecture of the 5G core network, after a network function entity (NFEntity) completes service registration with the network storage function entity (FSA), when its own configuration information changes, the NFEntity sends a service update request to the FSA to partially update the registered configuration information. The service update request is implemented using a patch approach, meaning the NFEntity does not need to resubmit the complete network function configuration file; it only needs to specify the parameter fields to be changed and their corresponding changes in the service update request.

[0048] In the existing 3GPP TS29.510 protocol, network function entities (NFIs) are allowed to specify the array element to be updated using array indices when performing partial updates to array type parameters. However, in actual network operation, there may be inconsistencies between the array element order maintained by the network storage function entity and the order maintained by the NFI. When a NFI performs an array element deletion operation, the elements after the deleted element will shift forward sequentially, causing the indices of each element to shift. If the NFI continues to use the original indices to initiate an update operation, it will cause the network storage function entity to update the wrong array element, resulting in errors in the parameter data of the registered configuration information.

[0049] Let's take the above application scenario as an example for a specific explanation. In the second data center, a policy control function entity, acting as the first network function entity, has completed service registration with the network storage function entity. The configuration information registered by the policy control function entity includes a number segment array, which stores 10 number segment elements from index 0 to index 9. When the policy control function entity needs to delete the number segment element at index 8, it sends a delete operation request for index 8 to the network storage function entity. After the network storage function entity performs the delete operation, the original number segment element at index 9 moves forward to the position of index 8, at which point the maximum valid index of the number segment array becomes 8. If the policy control function entity subsequently sends a delete operation request for index 9 to the network storage function entity, since the element corresponding to index 9 no longer exists on the network storage function entity's side, the network storage function entity will be unable to correctly execute the delete operation, resulting in a number segment update failure. This data inconsistency problem caused by this index-based array update method will directly affect the correctness of the number segment information of the policy control function entity on the network storage function entity, and thus affect the accuracy of subsequent service discovery results based on number segments.

[0050] To address the aforementioned issues, this application embodiment, based on the registration verification mechanism described in the above embodiments, adds a validity check for service update requests. Specifically, it includes the following steps: Receive service update requests sent by the first network function entity; When a service update request is determined to be an indexed update operation for an array type parameter, the service update request is rejected, and an update failure response is returned to the first network function entity.

[0051] After the first network function entity completes service registration with the network storage function entity, when the first network function entity needs to perform a partial update to the registered configuration information, it sends a service update request to the network storage function entity. The service update request includes the path information of the parameter field to be updated, the operation type, and the operation content. Operation types include replacement, addition, and deletion. The path information of the parameter field indicates the specific location of the parameter to be updated in the network function configuration file.

[0052] Upon receiving a service update request, the network storage function entity parses the path information of the parameter fields carried in the request. First, it determines whether the parameter field to be updated is an array type parameter. Then, it checks whether the path information of the parameter field contains an array index. If the parameter field to be updated is an array type parameter and the path information contains an array index, the network storage function entity determines that the service update request is an indexed update operation for an array type parameter.

[0053] In its implementation, the network storage function entity identifies the presence of an array index by parsing the format of the path information in the parameter field of the service update request. When the path information in the parameter field contains an index position represented in numeric form, the network storage function entity determines that the service update request is an array update operation with subscripts. When the path information in the parameter field does not contain an array index, or the parameter field to be updated is not an array type parameter, the network storage function entity determines that the service update request is an update operation without subscripts, and the network storage function entity executes the update operation specified in the service update request according to the normal process.

[0054] The network storage function entity is pre-configured with a control switch to determine whether to enable the verification function for indexed update operations on array type parameters. When the control switch is on, the network storage function entity performs the aforementioned judgment logic for indexed update operations on received service update requests. When the control switch is off, the network storage function entity does not perform the aforementioned judgment logic and directly processes service update requests according to the normal process. By configuring the control switch, the network storage function entity can flexibly choose whether to enable the verification function for indexed update operations based on actual network deployment requirements.

[0055] When the network storage function entity determines that the service update request is an indexed update operation for an array type parameter, the network storage function entity will not execute the update operation specified in the service update request, will reject the service update request, and will return an update failure response to the first network function entity. The update failure response carries a status code indicating that the operation is prohibited.

[0056] In one implementation, the update failure response carries a status code of "403 Forbidden," which notifies the first network function entity that the service update request is rejected because it contains a prohibited indexed array update operation. In another implementation, the update failure response may also carry specific failure reason description information, indicating that the service update request was rejected because indexed update operations on array type parameters are not allowed, so that the first network function entity can adjust the update method according to the failure reason.

[0057] After receiving an update failure response, the first network function entity can re-initiate the service update request using a whole-instance replacement method without subscripts. That is, the first network function entity submits the complete array parameters as the update content to the network storage function entity, which then updates the entire content of the array type parameters by whole-instance replacement, thereby avoiding data update errors caused by subscript offset.

[0058] According to the technical solution described in this application, after receiving a service update request from a first network function entity, the network storage function entity performs a validity check on the service update request. If it determines that the service update request is an indexed update operation on array type parameters, it rejects the service update request and returns an update failure response. This solution controls the service update process, prohibiting indexed array update operations that could lead to data inconsistency, avoiding parameter data update errors caused by array element index offsets, ensuring the correctness of array type parameters in the configuration information of each network function entity on the network storage function entity, and thus improving the accuracy and reliability of service discovery based on configuration information.

[0059] This application embodiment further provides a verification mechanism for network element type change operations.

[0060] In the service-oriented architecture of the 5G core network, when each network function entity (NF) registers its services with the network storage function entity, the network storage function entity assigns or records a unique network function instance identifier (NF instanceId) for each NF. The NF instanceId uniquely identifies a registered NF entity within the network storage function entity, which then associates and stores the NF instanceId with the corresponding network function configuration file. The network function configuration file records various configuration information for the NF entity, such as its network element type, service address, and number range.

[0061] In the existing 3GPP TS29.510 protocol, network function entities (NFEntities) are allowed to send service update requests to network storage NFEntities to directly change the network element type associated with a registered NFEntity instance identifier. However, in actual network operation, when the network element type corresponding to a NFEntity instance identifier on a network storage NFEntity is directly changed, other NFEntities that have obtained and cached the NFEntity configuration file corresponding to the original network element type from the network storage NFEntity cannot detect the change. This situation leads to inconsistencies between the configuration information cached on each NFEntity and the configuration information actually stored on the network storage NFEntity, resulting in errors when NFEntities perform service routing or message forwarding based on the cached configuration information.

[0062] To address the aforementioned issues, this application embodiment, based on the registration verification mechanism described in the previous embodiments, adds a legality verification for network element type change operations. Specifically, it includes the following steps: Receive a service update request sent by the first network function entity. The service update request carries the target instance identifier and the type of network element to be changed. Query the registered network element type corresponding to the target instance identifier; When the type of network element to be changed is different from the type of network element already registered, the service update request is rejected and a change failure response is returned to the first network function entity.

[0063] After the first network function entity completes service registration with the network storage function entity, when the first network function entity needs to change its own network element type, it sends a service update request to the network storage function entity. The service update request carries the target instance identifier and the network element type to be changed. The target instance identifier is the network function instance identifier used by the first network function entity when it completed service registration, indicating which registered network function configuration file the first network function entity is requesting to change. The network element type to be changed is the new network element type that the first network function entity expects to change from its registered network element type to.

[0064] Upon receiving a service update request, the network storage function entity searches its local database for the registered network function configuration file corresponding to the target instance identifier carried in the service update request. The network storage function entity then extracts the registered network element type corresponding to the target instance identifier from the registered network function configuration file. The registered network element type is the network element type submitted to the network storage function entity by the first network function entity during service registration.

[0065] When the network storage function entity fails to find the registered network function configuration file corresponding to the target instance identifier in the local database, the network storage function entity determines that the target instance identifier is invalid, rejects the service update request, and returns the corresponding error response to the first network function entity.

[0066] The network storage function entity compares the network element type to be changed carried in the service update request with the registered network element types retrieved from the local database. When the network element type to be changed differs from the registered network element type, the network storage function entity determines that the first network function entity is requesting a network element type change operation on a registered network function instance identifier. The network storage function entity rejects the service update request, makes no modifications to the network function configuration file corresponding to the target instance identifier in the local database, and returns a change failure response to the first network function entity. The change failure response carries a status code indicating that the request is invalid and a description of the failure reason, specifying that directly changing the network element type on a registered network function instance identifier is not allowed.

[0067] When the network element type to be changed is the same as the registered network element type, the network storage function entity determines that the service update request does not involve a network element type change operation, and the network storage function entity processes other update content in the service update request according to the normal process.

[0068] When the first network function entity needs to change the network element type, it first sends a service deregistration request to the network storage function entity. Upon receiving the request, the network storage function entity deletes the network function configuration file corresponding to the target instance identifier and sends a deregistration notification to all network function entities that have subscribed to the network function configuration file change notification. Each network function entity, upon receiving the deregistration notification, clears the configuration information associated with the target instance identifier from its local cache. After the service deregistration is complete, the first network function entity resends a service registration request to the network storage function entity with the new network element type. The network storage function entity processes the new service registration request according to the verification process described in the previous embodiment. By deregistering first and then re-registering, each network function entity can clear old cached data during the deregistration phase and obtain the updated network function configuration file through service discovery after the new registration is completed, thereby ensuring that the configuration information cached on each network function entity is consistent with the configuration information actually stored on the network storage function entity.

[0069] According to the technical solution described in this application, after receiving a service update request from a first network function entity, the network storage function entity queries the registered network element type corresponding to the target instance identifier. If it determines that the network element type to be changed is different from the registered network element type, it rejects the service update request and requires the first network function entity to complete the network element type change by first deregistering and then re-registering. This solution, by prohibiting direct changes to the network element type of the registered network function instance identifier, ensures that the configuration information cached on each network function entity can be correctly updated through the normal deregistration and re-registration process during the network element type change process. This avoids the problem of inconsistent cached data among network function entities caused by direct changes to network element types, and guarantees the correctness and reliability of service interactions between network function entities in the 5G core network.

[0070] This application embodiment further provides a mechanism for conflict detection of registered configuration information after service registration verification has passed.

[0071] In large-scale 5G core network deployments, multiple instances of the same type of network function entity are typically deployed, each serving different user groups or geographical regions. The valid parameter information carried by each instance when registering with the network storage function entity should be mutually exclusive to ensure that each user is matched with only one unique network function entity during service discovery. However, in actual network operation and maintenance, due to manual configuration errors or insufficient coordination between different administrative regions, there is a possibility of overlapping or inclusion relationships between the valid parameter information registered by different instances. When there is overlap or inclusion relationships between the valid parameter information registered by two network function entities of the same type, service discovery will return multiple matching results, causing users to be redirected to non-assigned network function entities, resulting in service anomalies.

[0072] To address the aforementioned issues, this application embodiment adds a conflict detection function for registered configuration information after the registration verification mechanism described in the foregoing embodiments has been passed. Specifically, it includes the following steps: When it is determined that the configuration information contains valid parameter information corresponding to the target parameter category, the service registration request is accepted and the configuration information of the first network function entity is stored. Detect conflicts between the valid parameter information of the first network functional entity and the valid parameter information of the same type of network functional entities that have been stored. When it is determined that there is an overlap or inclusion relationship between the valid parameter information of the first network function entity and the valid parameter information of the stored network function entity of the same type, a conflict alarm message is generated.

[0073] In the verification process described in the foregoing embodiments, the network storage function entity determines the corresponding target parameter category based on the network element type of the first network function entity, and verifies whether the configuration information contains valid parameter information corresponding to the target parameter category. When the network storage function entity determines that the configuration information contains valid parameter information corresponding to the target parameter category, the network storage function entity accepts the service registration request from the first network function entity, stores the configuration information of the first network function entity in the form of a network function configuration file in the local database of the network storage function entity, and returns a registration success response to the first network function entity.

[0074] After storing the configuration information of the first network function entity, the network storage function entity searches the local database for the network function configuration files of all stored network function entities of the same network element type as the first network function entity. The network storage function entity then extracts valid parameter information from the network function configuration files of each of the same type of network function entities and performs conflict detection between the valid parameter information of the first network function entity and the valid parameter information of each of the other network function entities.

[0075] The conflict detection method varies depending on the category of the valid parameter information. When the valid parameter information is a number segment parameter category, the network storage function entity compares the subscribed permanent identifier range or general public subscribed identifier range of the first network function entity with the subscribed permanent identifier range or general public subscribed identifier range of each network function entity of the same type to determine whether there is any overlap or inclusion relationship in the numerical range between the two number segment ranges. When the valid parameter information is a location parameter category, the network storage function entity compares the tracking area identifier list of the first network function entity with the tracking area identifier lists of each network function entity of the same type to determine whether there are any identical tracking area identifier elements in the two tracking area identifier lists. When the valid parameter information is an address parameter category, the network storage function entity compares the user Internet Protocol address list of the first network function entity with the user Internet Protocol address lists of each network function entity of the same type to determine whether there are any identical address segments or overlapping address ranges in the two user Internet Protocol address lists.

[0076] In one implementation, the network storage function entity triggers a conflict detection process immediately after receiving a new service registration request and storing the configuration information. In another implementation, the network storage function entity periodically performs a full conflict detection on the valid parameter information of all network function entities of the same type in the local database at preset time intervals to detect configuration conflicts between network function entities registered at different times.

[0077] When a network storage function entity determines through conflict detection that the valid parameter information of a first network function entity overlaps or contains the valid parameter information of one or more stored network function entities of the same type, the network storage function entity generates a conflict alarm message. The conflict alarm message includes the network function instance identifier, network element type, parameter category of the conflict, and specific conflict content for each conflicting network function entity. The specific conflict content includes the range of parameter values ​​where the overlap or containment relationship occurs.

[0078] In one implementation, the network storage function entity sends conflict alarm information to the network management system, which then displays the conflict alarm information to the operations and maintenance personnel so that they can promptly correct any conflicting configurations. In another implementation, the network storage function entity records the conflict alarm information in a local log for periodic review by the operations and maintenance personnel. In yet another implementation, the network storage function entity simultaneously sends the conflict alarm information to the network management system and records it in its local log.

[0079] It should be noted that when the network storage function entity generates conflict alarm information, it does not delete or roll back the configuration information of the first network function entity that has already been accepted and stored. The network storage function entity retains the storage state of the first network function entity's configuration information in its local database and notifies the operations and maintenance personnel of the existence of configuration conflicts through conflict alarm information. The operations and maintenance personnel then determine and correct the conflicting configurations based on the actual business situation. This approach ensures the normal completion of service registration and allows operations and maintenance personnel to intervene before configuration conflicts cause business anomalies through timely alarms.

[0080] The technical solution described in this application embodiment, after receiving a service registration request from a first network function entity and storing configuration information, allows the network storage function entity to perform conflict detection between the valid parameter information of the first network function entity and the valid parameter information of other stored network function entities of the same type. When an overlap or inclusion relationship is determined, a conflict alarm is generated. This solution adds proactive detection capability for configuration conflicts after service registration verification, enabling the network storage function entity to promptly detect and alarm upon the occurrence of configuration conflicts. This provides maintenance personnel with a basis for timely correction of configuration conflicts and reduces the risk of abnormal service discovery results and business impairment due to overlap or inclusion of valid parameter information between different network function entities.

[0081] This application embodiment further provides a mechanism for periodically verifying the configuration information of each stored network functional entity.

[0082] The technical solution described in the foregoing embodiments verifies the validity of the configuration information submitted by the first network function entity during the service registration process, preventing network function entities without key parameters from completing registration at the registration entry point. However, in actual network operation, after initial registration, network function entities may still modify the registered configuration information through service update requests. When a network function entity clears or modifies the originally valid parameter information in the configuration information to invalid values ​​through a service update request, the configuration information stored on the network storage function entity will be in a state of missing key parameters. In addition, during operation and maintenance operations such as network storage function entity upgrades, data migrations, or primary / backup switching, the stored configuration information may also lose key parameters due to data anomalies. All of the above situations will cause the configuration information stored on the network storage function entity to fail to meet the validity requirements, thereby affecting the accuracy of subsequent service discovery results.

[0083] To address the aforementioned issues, this application embodiment, based on the registration-time verification mechanism described in the previous embodiments, adds a periodic verification function for stored configuration information, forming a dual-protection mechanism combining registration-time verification and continuous runtime monitoring. Specifically, it includes the following steps: According to the preset inspection cycle, the configuration information of each network functional entity that has been stored is periodically verified. The periodic verification includes: determining the corresponding target parameter category according to the network element type of each network functional entity, and judging whether the configuration information of each network functional entity contains valid parameter information that matches the corresponding target parameter category. An alarm message is generated when it is detected that the configuration information of a stored network function entity does not contain valid parameter information that matches the corresponding target parameter category.

[0084] The network storage function entity is pre-configured with a check cycle. This check cycle determines the time interval at which the network storage function entity performs periodic verifications of the configuration information of each stored network function entity. The value of the check cycle is set by the operations and maintenance personnel based on the actual network scale and business needs. In one implementation, the check cycle is a fixed time interval, such as performing periodic verification every preset number of minutes or hours. In another implementation, the check cycle is a specific time point, such as performing periodic verification at a fixed time during daily off-peak business hours.

[0085] When the verification time specified in the inspection cycle is reached, the network storage function entity initiates a periodic verification process. The network storage function entity reads the network function configuration files of all stored network function entities from the local database and performs verification operations on the network function configuration file of each stored network function entity separately.

[0086] The specific process of periodic verification is as follows: The network storage function entity extracts the network element type from the network function configuration file of each stored network function entity, and determines the corresponding target parameter category based on the extracted network element type. The correspondence between network element type and target parameter category is consistent with the preset correspondence described in the aforementioned embodiments. After determining the target parameter category, the network storage function entity determines whether the configuration information of each stored network function entity contains valid parameter information that matches the corresponding target parameter category.

[0087] Specifically, when the network element type of the stored network function entity is a number segment network function entity, the corresponding target parameter category is the number segment parameter category. The network storage function entity determines whether the configuration information of the stored network function entity contains non-empty and validly formatted subscription permanent identifier range information or general public subscription identifier range information. When the network element type of the stored network function entity is a location-based network function entity, the corresponding target parameter category is the location parameter category. The network storage function entity determines whether the configuration information of the stored network function entity contains non-empty and validly formatted tracking area identifier list information. When the network element type of the stored network function entity is a binding support function entity, the corresponding target parameter category is the address parameter category. The network storage function entity determines whether the configuration information of the stored network function entity contains non-empty and validly formatted user Internet Protocol address list information.

[0088] In one implementation, the network storage function entity performs a full verification of the configuration information of all stored network function entities in the local database during each inspection cycle; that is, it iterates through all network function configuration files in the local database and verifies them one by one. In another implementation, the network storage function entity performs verification in batches according to network element type during each inspection cycle; that is, in one inspection cycle, the configuration information of all number segment-type network function entities is verified first, and in the next inspection cycle, the configuration information of all location-type network function entities is verified, rotating in this manner to distribute the processing load of a single verification operation.

[0089] During periodic verification, when a network storage function entity detects that the configuration information of a stored network function entity does not contain valid parameter information that matches the corresponding target parameter category, the network storage function entity generates an alarm message. The alarm message includes the network function instance identifier, network element type, missing target parameter category, and the time when the verification failed for the network function entity that failed verification.

[0090] In one implementation, the network storage function entity sends alarm information to the network management system, which then displays the alarm information to the operations and maintenance personnel so that they can promptly correct the configuration information of network function entities with missing parameters or deregister the entities with missing parameters. In another implementation, the network storage function entity records the alarm information in a local log for periodic review by the operations and maintenance personnel. In yet another implementation, the network storage function entity simultaneously sends alarm information to the network management system and records it in its local log.

[0091] When a network storage function entity detects that the configuration information of multiple stored network function entities fails verification within a check cycle, the network storage function entity generates independent alarm information for each network function entity that fails verification, so that operation and maintenance personnel can locate and handle each network function entity with missing parameters one by one.

[0092] It should be noted that when the network storage function entity generates alarm information during periodic verification, it does not automatically delete or modify the configuration information of network function entities that fail verification. The network storage function entity retains the current storage state of the configuration information of network function entities that fail verification in the local database and notifies operations and maintenance personnel of the anomaly of missing parameters via alarm information. Operations and maintenance personnel then determine the subsequent handling measures based on the actual business situation. This approach avoids the risk of accidental deletion of network function entities or accidental modification of configuration information due to improper automated operations, while ensuring that operations and maintenance personnel can perform targeted troubleshooting and configuration correction based on alarm information.

[0093] The technical solution described in this application embodiment periodically verifies the configuration information of each stored network function entity according to a preset inspection cycle. When it is detected that the configuration information of a stored network function entity does not contain valid parameter information matching the corresponding target parameter category, an alarm message is generated. Based on the one-time verification during registration described in the previous embodiment, the above solution establishes the capability for continuous runtime monitoring, forming a dual guarantee mechanism combining verification during registration and periodic runtime verification. Even if key parameters in the stored configuration information are lost due to service updates, data migration, or system anomalies after the network function entity completes initial registration, the network storage function entity can still promptly detect and generate alarm messages through periodic verification. This provides maintenance personnel with a continuous means of monitoring the validity of configuration information, reducing the risk of abnormal service discovery results and business damage due to missing key parameters in the stored configuration information.

[0094] Based on the technical solutions described in the foregoing embodiments, this application further provides a mechanism for conflict detection and optimization of service discovery results.

[0095] The technical solution described in the foregoing embodiments prevents network function entities (NFEntities) without key parameters from registering with network storage function entities (FSEntities) at the source by validating configuration information during the service registration process. However, in large-scale cross-regional networking scenarios, NFEntities from different administrative regions register with their respective regional FEntities, and these FEntities interconnect to achieve cross-regional service discovery. In this scenario, even if each NFEntity carries valid parameter information and passes registration verification during registration, insufficient configuration coordination can still lead to overlapping valid parameter information between NFEntities from different regions. When a service discovery request is made for cross-regional matching, the discovery result returned by the FEntity will include multiple NFEntities from different regions, causing the service consumer NFEntity to select a non-local NFEntity, resulting in service anomalies.

[0096] To address the aforementioned issues, this application embodiment, based on service registration verification, adds conflict detection and local optimization functions to the service discovery stage, serving as a fault-tolerant defense on the service discovery side. The technical solution of this application embodiment is described in detail below with reference to specific application scenarios.

[0097] In this embodiment, the aforementioned cross-regional 5G core network application scenario will continue to be used for explanation. In this application scenario, Zhejiang Province deploys a first data center, which houses a first access and mobility management function entity, a first unified data management entity, and a second unified data management entity. Jiangsu Province deploys a second data center, which houses a third and fourth unified data management entity. The first and second unified data management entities belong to Zhejiang Province, while the third and fourth unified data management entities belong to Jiangsu Province. Due to insufficient configuration coordination, the third and fourth unified data management entities in Jiangsu Province are misconfigured with number ranges overlapping with those of the first and second unified data management entities in Zhejiang Province. When the first access and mobility management function entity in Zhejiang Province sends a service discovery request to the network storage function entity, using a certain subscription permanent identifier as a discovery condition to query the unified data management entities, the matching result returned by the network storage function entity simultaneously includes the first and second unified data management entities in Zhejiang Province, as well as the third and fourth unified data management entities in Jiangsu Province—a total of four unified data management entities. Without conflict correction, the first access and mobility management functional entity may select the unified data management entity of Jiangsu Province, causing the services of users in Zhejiang Province to be incorrectly diverted to the unified data management entity of Jiangsu Province, resulting in damage to services in Zhejiang Province.

[0098] In the 5G core network, the network function instance identifier of each network function entity is encoded according to a preset field structure. The network function instance identifier consists of multiple bytes, with different bytes carrying different identification information. The network function instance identifier includes a region identifier and a province identifier. The region identifier identifies the geographic region to which the network function entity belongs, and the province identifier identifies the specific province to which the network function entity belongs. By parsing the region identifier and province identifier in the network function instance identifier, the geographic region and province to which the network function entity belongs can be determined.

[0099] Based on the above application scenarios, referring to Figure 3 , Figure 3 This is the second flowchart illustrating the service management method provided by this invention. The service discovery result conflict detection and optimization mechanism described in this application includes the following steps: Step 210: Receive a service discovery request sent by the second network function entity, the service discovery request carrying discovery condition parameters.

[0100] In the service-oriented architecture of the 5G core network, when a network function entity (NFEntity) needs to interact with another NFEntity of a specific type, the NFEntity initiating the service request, acting as the second NFEntity, sends a service discovery request to the network storage entity. The service discovery request carries discovery condition parameters, which describe the conditions that the target NFEntity to be discovered by the second NFEntity must meet. The specific content of the discovery condition parameters varies depending on the service discovery requirements. When the second NFEntity needs to discover number segment-type NFEntities, the discovery condition parameters include a subscription permanent identifier or a general public subscription identifier. When the second NFEntity needs to discover location-type NFEntities, the discovery condition parameters include a tracking area identifier. When the second NFEntity needs to discover a binding support function entity, the discovery condition parameters include the user's Internet Protocol (IP) address. The discovery condition parameters also include the target network element type, which specifies the network element type of the NFEntity to be discovered by the second NFEntity.

[0101] In the above application scenario, the first access and mobility management functional entity in Zhejiang Province, acting as the second network functional entity, sends a service discovery request to the network storage functional entity. The discovery condition parameters carried in the service discovery request include the target network element type being unified data management type, and a specific subscription permanent identifier value.

[0102] Step 220: Based on the discovery condition parameters, multiple candidate network function entities are obtained by matching from the configuration information of each network function entity that has been stored.

[0103] Upon receiving a service discovery request, the network storage function entity extracts discovery condition parameters from the request and matches them against the configuration information of stored network function entities in its local database. The network storage function entity then selects network function entities from the stored configuration information that simultaneously meet the target network element type and other filtering conditions specified in the discovery condition parameters. These qualified network function entities are designated as candidate network function entities. When there are multiple candidate network function entities that meet the discovery condition parameters, the network storage function entity proceeds to the subsequent conflict detection process.

[0104] In the above application scenario, the network storage function entity matches data in its local database based on the discovery condition parameters sent by the first access and mobility management function entity. Since the number ranges of the first and second unified data management entities in Zhejiang Province, as well as the third and fourth unified data management entities in Jiangsu Province, all cover the subscription permanent identifier value specified in the discovery condition parameters, the network storage function entity obtains four candidate network function entities: the first unified data management entity, the second unified data management entity, the third unified data management entity, and the fourth unified data management entity.

[0105] Step 230: Extract the region identifier and province identifier from the instance identifier of each candidate network functional entity.

[0106] After obtaining multiple candidate network function entities, the network storage function entity reads the network function instance identifier of each candidate network function entity from its network function configuration file. The network storage function entity parses the network function instance identifier of each candidate network function entity according to a preset field structure, and extracts the region identifier and province identifier from the network function instance identifier of each candidate network function entity.

[0107] In the above application scenario, the network storage function entity parses the network function instance identifiers of the four candidate network function entities. The region identifier extracted from the network function instance identifier of the first unified data management entity points to the East China region, and the province identifier points to Zhejiang Province. The region identifier extracted from the network function instance identifier of the second unified data management entity points to the East China region, and the province identifier points to Zhejiang Province. The region identifier extracted from the network function instance identifier of the third unified data management entity points to the East China region, and the province identifier points to Jiangsu Province. The region identifier extracted from the network function instance identifier of the fourth unified data management entity points to the East China region, and the province identifier points to Jiangsu Province.

[0108] Step 240: When it is determined that there are differences in the regional identifiers or province identifiers among the candidate network functional entities, the regional identifiers and province identifiers of each candidate network functional entity are compared with the regional identifiers and province identifiers of the second network functional entity.

[0109] After extracting the region identifier and province identifier of each candidate network function entity, the network storage function entity compares the region identifiers and province identifiers of each candidate network function entity. When all candidate network function entities have the same region identifier and the same province identifier, the network storage function entity determines that all candidate network function entities belong to the same region and the same province, and there is no cross-region configuration conflict. The network storage function entity then returns all candidate network function entities as service discovery results.

[0110] When at least two candidate network function entities have different region identifiers or different province identifiers, the network storage function entity determines that the region identifiers or province identifiers of the candidate network function entities are different, and identifies a cross-regional configuration conflict in the discovery results. The network storage function entity further obtains the network function instance identifier of the second network function entity, and extracts the region identifier and province identifier of the second network function entity from the network function instance identifier of the second network function entity according to the same preset field structure. The network storage function entity then compares the region identifier and province identifier of each candidate network function entity with the region identifier and province identifier of the second network function entity, respectively.

[0111] In one implementation, the network storage function entity obtains the network function instance identifier of the second network function entity from the service discovery request. In another implementation, the network storage function entity searches its local database for the registered network function profile of the second network function entity based on the source information of the service discovery request, and reads the network function instance identifier of the second network function entity from the network function profile.

[0112] In the above application scenario, the network storage function entity compares the province identifiers of four candidate network function entities and finds that the province identifiers of the first and second unified data management entities point to Zhejiang Province, while the province identifiers of the third and fourth unified data management entities point to Jiangsu Province, indicating that the province identifiers of the candidate network function entities are different. The network storage function entity further obtains the network function instance identifier of the first access and mobility management function entity, and extracts the region identifier pointing to East China and the province identifier pointing to Zhejiang Province from the network function instance identifier of the first access and mobility management function entity. The network storage function entity then compares the region identifiers and province identifiers of the four candidate network function entities with those of the first access and mobility management function entity.

[0113] Step 250: Select candidate network function entities from multiple candidate network function entities whose region identifier and province identifier are the same as the second network function entity, and return them as service discovery results.

[0114] Based on the comparison results, the network storage function entity selects candidate network function entities from multiple candidate network function entities that have the same region identifier as the second network function entity and the same province identifier as the second network function entity. The network storage function entity returns the selected candidate network function entities as service discovery results to the second network function entity. Candidate network function entities with different region identifiers or province identifiers from the second network function entity are excluded from the service discovery results.

[0115] If, after filtering, no candidate network function entity has both the same region identifier and province identifier as the second network function entity, the network storage function entity processes the request according to a preset degradation strategy. In one implementation, the network storage function entity prioritizes candidate network function entities with the same region identifier as the second network function entity and returns them as service discovery results. In another implementation, the network storage function entity returns all candidate network function entities as service discovery results, while also including conflict identification information in the service discovery results to notify the second network function entity that there is a cross-regional configuration conflict in the discovery results, allowing the second network function entity to make its own selection.

[0116] In the above application scenario, based on the comparison results, the network storage function entity selects candidate network function entities from four candidate network function entities whose region identifier and province identifier are the same as those of the first access and mobility management function entity. The region identifier of the first unified data management entity points to East China and the province identifier points to Zhejiang Province, which are the same as those of the first access and mobility management function entity. The region identifier of the second unified data management entity points to East China and the province identifier points to Zhejiang Province, which are the same as those of the first access and mobility management function entity. The province identifier of the third unified data management entity points to Jiangsu Province, which is different from that of the first access and mobility management function entity. The province identifier of the fourth unified data management entity points to Jiangsu Province, which is different from that of the first access and mobility management function entity. The network storage function entity returns the first and second unified data management entities as service discovery results to the first access and mobility management function entity, and excludes the third and fourth unified data management entities from the service discovery results. Through the above conflict detection and optimization process, the first access and mobility management functional entity in Zhejiang Province only receives the unified data management entity of Zhejiang Province as the service discovery result, thus avoiding the incorrect diversion of user services to the unified data management entity of Jiangsu Province.

[0117] It should be noted that the conflict detection and optimization processing of the service discovery results described above is not only applicable to the network storage function entity side. In other embodiments, the second network function entity can also perform the same conflict detection and optimization logic locally after receiving the service discovery results returned by the network storage function entity. The second network function entity extracts the region identifier and province identifier from the network function instance identifiers of each candidate network function entity in the service discovery results, compares them with the region identifier and province identifier of the second network function entity itself, and selects candidate network function entities belonging to the same region and province as the second network function entity as the final service selection target from the service discovery results. The above processing method is applicable to various types of network function entities such as Access and Mobility Management Function (AMF) entities, Session Management Function (SMF) entities, and Charging Function (CHF) entities.

[0118] The technical solution described in this application embodiment, after receiving a service discovery request from a second network function entity and matching multiple candidate network function entities, the network storage function entity performs conflict detection by extracting the region identifier and province identifier from the network function instance identifier of each candidate network function entity. When a cross-regional or cross-provincial configuration conflict is determined, candidate network function entities belonging to the same region and province as the second network function entity are prioritized and returned as service discovery results. This solution establishes a fault-tolerant defense in the service discovery stage. Even if there are configuration conflicts between network function entities in different regions, the strategy of prioritizing network function entities from the home province can minimize the impact of errors, ensuring that home province services are not affected by misconfigurations from other provinces. This improves the reliability and accuracy of the service discovery mechanism in the 5G core network in cross-regional networking scenarios.

[0119] This application embodiment further illustrates the specific parsing method for extracting the region identifier and province identifier from the instance identifier of each candidate network functional entity.

[0120] In the 5G core network, the network function instance identifier of each network function entity is encoded according to a preset field structure. This preset field structure divides the network function instance identifier into multiple bytes, with different byte positions carrying different types of identifier information. By parsing the network function instance identifier according to the preset field structure, the network storage function entity can obtain information such as the network element type, geographical region, specific province, and instance sequence number from the network function instance identifier.

[0121] Specifically, the following steps are included: The instance identifiers of each candidate network functional entity are parsed according to a preset field structure. The first preset byte is extracted from the instance identifier as the region identifier, and the second preset byte is extracted as the province identifier.

[0122] After obtaining multiple candidate network function entities, the network storage function entity reads the network function instance identifier of each candidate network function entity and parses the network function instance identifier of each candidate network function entity byte by byte according to the preset field structure.

[0123] The predefined field structure defines the semantics of each byte in the network function instance identifier. The network function instance identifier consists of multiple bytes; in one implementation, it consists of 6 bytes. The first byte is the network element type byte, used to identify the network element type of the network function entity. The second byte is the region byte, used to identify the geographical region to which the network function entity belongs. The third byte is the province byte, used to identify the specific province to which the network function entity belongs. The fourth to sixth bytes are the instance sequence number bytes, used to distinguish multiple network function entity instances of the same network element type within the same region and province.

[0124] The network storage function entity extracts a first preset byte from the network function instance identifier of each candidate network function entity as a region identifier. The first preset byte is the byte in the network function instance identifier that carries region information according to a preset field structure. In the above implementation of a 6-byte network function instance identifier, the first preset byte is the second byte of the network function instance identifier. The network storage function entity reads the value of the second byte of the network function instance identifier and uses the read value as the region identifier. Different values ​​of the region identifier correspond to different geographic regions.

[0125] The network storage function entity extracts a second preset byte from the network function instance identifier of each candidate network function entity as the province identifier. The second preset byte is the byte carrying province information in the network function instance identifier, determined according to a preset field structure. In the above implementation of a 6-byte network function instance identifier, the second preset byte is the third byte of the network function instance identifier. The network storage function entity reads the value of the third byte of the network function instance identifier and uses this value as the province identifier. Different values ​​of the province identifier correspond to different specific provinces.

[0126] In another implementation, the total number of bytes and the semantic definition of each byte in the network function instance identifier differ from those in the above implementation. The positions of the first and second preset bytes in the network function instance identifier also differ accordingly. Regardless of the specific field structure definition used in the network function instance identifier, the network storage function entity parses the identifier according to the parsing rules consistent with the preset field structure used when encoding the network function instance identifier, accurately extracting the region identifier and province identifier from the network function instance identifier.

[0127] After parsing the network function instance identifiers of each candidate network function entity, the network storage function entity obtains the region identifier and province identifier corresponding to each candidate network function entity, and uses the obtained region identifier and province identifier for the subsequent conflict detection and province selection process described in the foregoing embodiments.

[0128] The technical solution described in this application involves a network storage function entity parsing the network function instance identifiers of each candidate network function entity byte-by-byte according to a preset field structure. This extracts the region and province identifiers from specific byte positions within the network function instance identifiers, providing accurate geographic attribution information for subsequent conflict detection and province-specific optimization. This solution utilizes the region and province information already encoded in the network function instance identifiers, eliminating the need for additional fields or external data source queries to obtain the geographic attribution information of each candidate network function entity. The implementation is simple and efficient, ensuring the accuracy and real-time performance of conflict detection and optimization processing in service discovery results.

[0129] This application further provides a mechanism for fine matching and selection based on the size of the number segment range after multiple candidate network functional entities are obtained.

[0130] The technical solution described in the foregoing embodiments performs conflict detection by extracting the region identifier and province identifier from the network function instance identifier of each candidate network function entity, and preferentially selects candidate network function entities that belong to the same region and province as the second network function entity. However, within the same region and province, there are still multiple network function entities of the same type that have configured overlapping number ranges when registering with the network storage function entity. In actual network operation and maintenance, some network function entities register excessively large number ranges due to configuration errors, or their number ranges cover the number ranges of other network function entities due to insufficient fine-tuning of number ranges. When the number range parameter in the service discovery request falls within the number ranges of multiple candidate network function entities, the network storage function entity needs to select the most precisely matching network function entity from among the multiple candidate network function entities. The smaller the number range of a network function entity, the more precise its corresponding user group, and the lower the probability of being misconfigured as an excessively large number range. Therefore, network function entities with smaller number ranges are more likely to be the network function entities to which the user truly belongs.

[0131] To address the aforementioned issues, this application embodiment, after obtaining multiple candidate network functional entities, adds a fine-grained matching and optimization function based on the number segment range. Specifically, it includes the following steps: Obtain the number range corresponding to each candidate network functional entity, and calculate the size of the number range for each candidate network functional entity. The size of the number range is the difference between the end value and the beginning value of the number range. The candidate network functional entities are sorted in ascending order of their number range size. The candidate network functional entity that ranks first after sorting is returned as the service discovery result.

[0132] After matching multiple candidate network function entities from the configuration information of stored network function entities based on discovery condition parameters, the network storage function entity reads the registered number range of each candidate network function entity from its network function configuration file. The number range is defined by two endpoint values: the starting value and the ending value. The starting value represents the lower limit of the number range, and the ending value represents the upper limit of the number range.

[0133] When a candidate network function entity's network function configuration file contains subscribed permanent identifier range information, the network storage function entity extracts the start and end values ​​of the number segment from the subscribed permanent identifier range information. When a candidate network function entity's network function configuration file contains general public subscribed identifier range information, the network storage function entity extracts the start and end values ​​of the number segment from the general public subscribed identifier range information. When a candidate network function entity's network function configuration file contains both subscribed permanent identifier range information and general public subscribed identifier range information, the network storage function entity determines whether to extract the start and end values ​​of the number segment from the subscribed permanent identifier range information or the general public subscribed identifier range information based on the type of the discovery condition parameter in the service discovery request. When the number segment parameter included in the discovery condition parameter is a subscribed permanent identifier, the network storage function entity extracts the start and end values ​​of the number segment from the subscribed permanent identifier range information. When the number segment parameter included in the discovery condition parameter is a general public subscribed identifier, the network storage function entity extracts the start and end values ​​of the number segment from the general public subscribed identifier range information.

[0134] When the network function configuration file of a candidate network function entity contains multiple number ranges, the network storage function entity determines the number range containing the number range parameter value specified in the discovery condition parameter from the multiple number ranges, and uses the determined number range as the number range corresponding to the candidate network function entity.

[0135] After obtaining the number range corresponding to each candidate network function entity, the network storage function entity calculates the number range size for each candidate network function entity. The number range size is calculated as the difference between the end value and the beginning value of the number range. The smaller the number range size, the more refined the number range registered by the candidate network function entity; the larger the number range size, the broader the number range registered by the candidate network function entity.

[0136] The above method for calculating the range size also applies to scenarios where the discovery condition parameters include tracking area identifiers. When the discovery condition parameters include tracking area identifiers, the network storage function entity reads the tracking area identifier list from the network function configuration files of each candidate network function entity. The number of tracking area identifiers contained in the tracking area identifier list is used as an indicator to measure the range size. The candidate network function entity with fewer tracking area identifiers is judged to have a more refined range.

[0137] After calculating the range of numbers for each candidate network function entity, the network storage function entity sorts all candidate network function entities in ascending order of range size, using the range size as the sorting criterion. After sorting, the candidate network function entity with the smallest range is placed at the top of the sorted results, and the candidate network function entity with the largest range is placed at the bottom.

[0138] When multiple candidate network function entities have the same range size, the network storage function entity further sorts these candidate network function entities according to a preset auxiliary sorting rule. In one embodiment, the auxiliary sorting rule is to sort the candidate network function entities in ascending order of their load values, with lower load values ​​appearing earlier. In another embodiment, the auxiliary sorting rule is to sort the candidate network function entities in descending order of their priority, with higher priority candidates appearing earlier.

[0139] The network storage function entity selects the top-ranked candidate network function entity from the sorting results and returns it as the service discovery result to the second network function entity. The top-ranked candidate network function entity after sorting is the network function entity with the smallest number range among all candidate network function entities, that is, the network function entity with the highest matching accuracy for the number range parameter value specified in the discovery condition parameter.

[0140] In one implementation, the network storage function entity returns only the single candidate network function entity that ranks first after sorting as the service discovery result. In another implementation, the network storage function entity returns the first candidate network function entity after sorting, along with other candidate network function entities with the same number range size as the first candidate network function entity, as the service discovery result, so that the second network function entity can perform load balancing selection among multiple candidate network function entities with the same number range size.

[0141] The technical solution described in this application involves a network storage function entity that, after matching multiple candidate network function entities, obtains the number range corresponding to each candidate network function entity and calculates the size of the number range. These ranges are then sorted in ascending order, and the candidate network function entity with the smallest number range is returned as the service discovery result. This solution performs fine-grained matching based on the number range size, adhering to the principle that smaller number ranges result in higher matching accuracy. When multiple candidate network function entities meet the discovery conditions, the candidate network function entity with the most accurate number range is prioritized. This effectively avoids the problem of wildcard network function entities being incorrectly selected due to misconfigured or unconfigured number ranges, thus improving the accuracy of service discovery results and the correctness of service routing.

[0142] This application embodiment further illustrates the matching method of Data Network Name (DNN) during the service discovery process.

[0143] In the service-oriented architecture of the 5G core network, the data network name is one of the important filtering conditions in the service discovery process. The data network name is used to identify the data network that a user wants to access. When the service consumer network function entity sends a service discovery request, it carries the target data network name. The network storage function entity matches the target data network name with the data network names registered in the configuration information of each network function entity to filter out candidate network function entities that can serve the target data network.

[0144] According to the 3rd Generation Partnership Project (NGPP) technical specifications, a data network name consists of two parts: a Network Identifier (NI) and an Operator Identifier (OI). The Network Identifier identifies the name of the data network, and the Operator Identifier identifies the operator to which the data network belongs. In a complete data network name format, the Network Identifier and Operator Identifier are connected by a specific separator. However, in actual network deployment, there are inconsistencies in the format between the data network name carried by the service consumer network function entity when sending a service discovery request and the data network name configured by the service producer network function entity during registration. Specifically, the data network name carried by the service consumer network function entity includes the complete format of both the Network Identifier and Operator Identifier, while the data network name registered by the service producer network function entity only includes the Network Identifier and not the Operator Identifier; or the data network name carried by the service consumer network function entity only includes the Network Identifier, while the data network name registered by the service producer network function entity includes the complete format.

[0145] In the existing 3GPP TS29.510 protocol, the network storage function entity performs an exact string match on the data network name. When the target data network name does not exactly match the registered data network name, the network storage function entity determines that the data network name match has failed. This causes the service consumer network function entity to be unable to discover a network function entity capable of providing services, resulting in service failure. The root cause of this problem lies in the inconsistency between the format used by the service consumer network function entity and the service producer network function entity when configuring the data network name, and the difference between the actual data network that the non-data network name points to.

[0146] To address the aforementioned issues, this application optimizes the data network name matching method by employing a compatibility matching strategy when data network name formats are inconsistent. Specifically, this includes the following steps: Extract the target data network name from the discovery condition parameters; For each stored network function entity, obtain the registered data network name from its configuration information; When it is determined that one of the target data network name and the registered data network name carries an operator identifier while the other does not, the network identifier portion of the target data network name and the registered data network name are extracted respectively. When the network identifiers are identical and the public land mobile network identifiers match, the data network name is considered to be a successful match.

[0147] After receiving a service discovery request from the second network function entity, the network storage function entity extracts the target data network name from the discovery condition parameters carried in the service discovery request. The target data network name is the data network name corresponding to the network function entity that the second network function entity expects to discover, which can serve the specified data network. The target data network name can be a short format containing only the network identifier portion, or a complete format containing both the network identifier portion and the carrier identifier portion.

[0148] After retrieving the target data network name, the network storage entity iterates through the network function configuration files of each network function entity stored in the local database. The network storage entity reads the registered data network name from the network function configuration file of each stored network function entity. The registered data network name is the data network name attribute value included in the configuration information submitted by the network function entity when registering its service with the network storage entity. The format of the registered data network name is either a short format containing only the network identifier portion, or a complete format containing both the network identifier portion and the carrier identifier portion.

[0149] The network storage function entity compares the target data network name with the registered data network names of each stored network function entity. The network storage function entity first determines if the target data network name and the registered data network name are completely identical strings. If the target data network name and the registered data network name are completely identical strings, the network storage function entity directly determines that the data network name match is successful, without needing to perform subsequent compatibility matching processing.

[0150] When the target data network name does not exactly match the registered data network name, the network storage function entity further analyzes the formats of both names. The network storage function entity determines whether the target and registered data network names contain a carrier identifier portion. In one implementation, the network storage function entity determines whether the data network name carries a carrier identifier by detecting whether it contains a domain name suffix specific to the carrier identifier portion. In another implementation, the network storage function entity determines whether the data network name carries a carrier identifier by detecting whether it contains a field in the Public Land Mobile Network (PLMN) encoding format.

[0151] When the network storage entity determines that the target data network name carries an operator identifier while the registered data network name does not, or when the network storage entity determines that the target data network name does not carry an operator identifier while the registered data network name does, the network storage entity determines that there is a format inconsistency between the target data network name and the registered data network name. The network storage entity extracts the network identifier portion from both the target and registered data network names. The network identifier portion is the core field that identifies the data network name after removing the operator identifier portion. For data network names carrying an operator identifier, the network storage entity removes the operator identifier portion and the preceding separator to obtain the network identifier portion. For data network names not carrying an operator identifier, the data network name itself is the network identifier portion.

[0152] When both the target data network name and the registered data network name carry operator identifiers, or neither carries operator identifiers but the strings are not completely identical, the network storage function entity determines that the data network name matching fails.

[0153] After extracting the network identifier portion of the target data network name and the network identifier portion of the registered data network name, the network storage function entity performs a string comparison between the two network identifier portions. Simultaneously, the network storage function entity obtains the public land mobile network identifier of the second network function entity and the public land mobile network identifier of the stored network function entity, and performs a matching judgment between the two public land mobile network identifiers.

[0154] In one implementation, the network storage function entity parses the Public Land Mobile Network (PLN) coding information contained in the operator identifier portion from the data network name carrying the operator identifier. It then compares the parsed PLAN coding information with the PLAN list registered in the network function configuration file of the network function entity that does not carry the operator identifier to determine if they match. In another implementation, the network storage function entity retrieves its respective PLAN identifier lists from the configuration information of the second network function entity corresponding to the target data network name and the configuration information of the stored network function entity corresponding to the registered data network name, respectively, and determines whether at least one identical PLAN identifier exists in either list.

[0155] When the network identifier portion of the target data network name is identical to the network identifier portion of the registered data network name, and the public land mobile network identifier matches successfully, the network storage function entity determines that the data network name matches successfully and includes the corresponding stored network function entity in the scope of candidate network function entities. When the network identifier portions are different, or the public land mobile network identifier fails to match, the network storage function entity determines that the data network name does not match, and the corresponding stored network function entity is not included in the scope of candidate network function entities.

[0156] The network storage function entity is pre-configured with a compatibility matching control switch, which controls whether to enable the compatibility matching strategy when the data network name format is inconsistent. When the compatibility matching control switch is on, the network storage function entity executes the compatibility matching logic that ignores the operator identifier and only compares the network identifier portion and verifies the Public Land Mobile Network identifier when the data network name format is inconsistent. When the compatibility matching control switch is off, the network storage function entity performs data network name matching according to the string exact matching method in the prior art. By configuring the compatibility matching control switch, the network storage function entity can flexibly choose whether to enable the compatibility matching strategy according to the actual network deployment requirements.

[0157] The technical solution described in this application, when a network storage function entity matches data network names during service discovery, if it determines that one of the target data network name and the registered data network name carries an operator identifier while the other does not, it extracts the network identifier portions of both for comparison and verifies whether the public land mobile network identifier matches. If the network identifier portions are identical and the public land mobile network identifiers match, the data network name is considered successfully matched. This solution employs a compatibility matching strategy in scenarios with inconsistent data network name formats. By ignoring format differences in operator identifiers and focusing on the substantive content comparison of the network identifier portion, it avoids service discovery matching failures caused by inconsistent data network name formats between service consumer network function entities and service producer network function entities. This improves the compatibility and flexibility of data network name matching and reduces the complexity of data network name configuration in network deployment.

[0158] This application embodiment further provides a mechanism for pre-filtering service discovery requests before performing service discovery matching.

[0159] In the service-oriented architecture of the 5G core network, when a service consumer network function entity sends a service discovery request to a network storage function entity, the discovery condition parameters carried in the service discovery request typically include the target network element type and other filtering conditions. The target network element type (target-nf-type) specifies the network element type of the network function entity that the second network function entity needs to discover. Other filtering conditions include, but are not limited to, parameters such as subscription permanent identifier, general public subscription identifier, tracking area identifier, data network name, and user Internet Protocol address. The network storage function entity, based on the target network element type and other filtering conditions, filters the configuration information of each stored network function entity to obtain candidate network function entities that meet all discovery conditions.

[0160] In the existing 3GPP TS29.510 protocol, the Network Storage Function Entity allows service consumer network function entities to perform service discovery solely based on the target network element type; that is, the discovery condition parameters only include the target network element type without any other filtering conditions. In this case, the Network Storage Function Entity returns the network function profiles of all network function entities belonging to the target network element type from its local database as the service discovery result. In large-scale network deployment scenarios, some network element types correspond to a large number of network function entities, and the data volume of the network function profiles for each network function entity is large. When the service consumer network function entity discovers the aforementioned network element types solely based on the target network element type, the service discovery result returned by the Network Storage Function Entity will contain a large number of network function profiles. This causes the message length of the service discovery result to exceed the network transmission capacity or the receiver's processing capacity, resulting in the service discovery result being unable to be forwarded or parsed correctly, ultimately leading to service discovery failure.

[0161] To address the aforementioned issues, this application embodiment adds a pre-filtering function for service discovery requests before performing service discovery matching. This is achieved by configuring a whitelist of network element types that allow discovery solely based on the target network element type, and intercepting service discovery requests initiated based solely on the target network element type that are not on the whitelist. Specifically, this includes the following steps: Extract the target network element type from the discovery condition parameters; If the target network element type is determined not to belong to the pre-configured set of network element types that are allowed to be discovered solely by the target network element type, and the discovery condition parameters do not contain any other filtering conditions besides the target network element type, the service discovery request is rejected.

[0162] After receiving a service discovery request from the second network function entity, the network storage function entity extracts the target network element type from the discovery condition parameters carried in the service discovery request. The target network element type identifies the network element type of the network function entity that the second network function entity needs to discover, and the value of the target network element type is one of the various network element types in the 5G core network.

[0163] The network storage function entity pre-configures a set of network element types that allow discovery solely based on the target network element type. This set records the various network element types that allow service consumer network function entities to perform service discovery based only on the target network element type. The network element types included in this set are typically those with small network function configuration file data volumes or a small number of deployed network function entities. For these network element types, even when discovery is performed solely based on the target network element type, the length of the returned service discovery message remains within the acceptable range of network transmission and receiver processing capabilities. The specific content of the network element type set is configured by operations and maintenance personnel after evaluation based on the number of network function entities corresponding to each network element type and the data volume of the network function configuration file in the actual network.

[0164] After extracting the target network element type, the network storage function entity compares the target network element type with a pre-configured set of network element types to determine whether the target network element type belongs to a member of the set. Simultaneously, the network storage function entity checks whether the condition parameters contain any other filtering conditions besides the target network element type.

[0165] When the target network element type belongs to a member of the pre-configured network element type set, the network storage function entity accepts the service discovery request and enters the subsequent service discovery matching process, regardless of whether the discovery condition parameters contain other filtering conditions.

[0166] When the target network element type is not a member of the pre-configured set of network element types, and the discovery condition parameters include at least one other filtering condition besides the target network element type, the network storage function entity accepts the service discovery request and enters the subsequent service discovery matching process based on the target network element type and other filtering conditions. Because the discovery condition parameters include other filtering conditions, the range of service discovery matching results will be effectively narrowed, preventing the problem of excessively large service discovery result packets.

[0167] When the target network element type is not a member of the pre-configured set of network element types, and the discovery condition parameters do not contain any other filtering conditions besides the target network element type, the network storage function entity determines that the service discovery request has a risk of missing key filtering conditions and rejects the service discovery request. The network storage function entity does not proceed to the subsequent service discovery matching process and returns a service discovery failure response to the second network function entity. In one implementation, the service discovery failure response carries a status code indicating insufficient request parameters and a description of the failure reason. The description of the failure reason indicates that the service discovery request lacks necessary filtering conditions, and discovery of the specified network element type is not allowed based solely on the target network element type. In another implementation, the service discovery failure response carries a status code indicating that the request has been rejected, to notify the second network function entity to supplement other filtering conditions and re-initiate the service discovery request.

[0168] In one implementation, the network storage function entity loads a pre-configured set of network element types via a configuration file. Operations personnel can add or delete network element types from this set by modifying the configuration file. In another implementation, the network storage function entity receives configuration commands from operations personnel through a management interface and dynamically updates the network element types in the set. Both implementations enable the network storage function entity to flexibly update the content of the network element type set based on changes in network scale and adjustments to the deployment of each network element type.

[0169] The technical solution described in this application allows the network storage function entity to extract the target network element type from the discovery condition parameters before performing service discovery matching. If the target network element type does not belong to the pre-configured set of network element types allowed for discovery solely based on the target network element type, and the discovery condition parameters do not contain other filtering conditions, the service discovery request is rejected. This solution, by setting a pre-filtering stage before the service discovery matching process, intercepts service discovery requests lacking key filtering conditions. This avoids generating excessively large service discovery result packets when discovering network element types with large network function configuration file data volumes or numerous deployments based solely on the target network element type without filtering conditions. This prevents the burden of excessively large packets on network transmission links and receiver processing capabilities, ensuring the stability and availability of the service discovery mechanism in large-scale network deployment scenarios.

[0170] Reference Figure 4 , Figure 4 This is a schematic diagram of the service management system provided by the present invention. The system includes: The first processing module is used to receive a service registration request sent by the first network function entity. The service registration request carries the configuration information of the first network function entity, including the network element type of the first network function entity. The second processing module is used to determine the target parameter category that the first network function entity needs to carry during registration based on the network element type, wherein there is a preset correspondence between the target parameter category and the network element type; The third processing module is used to verify the configuration information, and when it is determined that the configuration information does not contain valid parameter information corresponding to the target parameter category, it rejects the service registration request and returns a registration failure response to the first network function entity.

[0171] In one possible implementation, the system further includes: The first processing module is also used to receive a service discovery request sent by the second network function entity, the service discovery request carrying discovery condition parameters. The fourth processing module is used to match multiple candidate network functional entities from the stored configuration information of each network functional entity based on the discovery condition parameters. The fifth processing module is used to extract the region identifier and province identifier from the instance identifiers of each candidate network functional entity. The sixth processing module is used to compare the regional and provincial identifiers of each candidate network functional entity with the regional and provincial identifiers of the second network functional entity when it is determined that there are differences between the regional identifiers or province identifiers of each candidate network functional entity. The seventh processing module is used to filter out candidate network function entities from multiple candidate network function entities whose region identifier and province identifier are the same as those of the second network function entity, and return them as service discovery results.

[0172] It should be noted that the service management system provided by the present invention can execute the service management method of any of the above embodiments during specific operation, which will not be elaborated in this embodiment.

[0173] Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 5 As shown, the electronic device may include a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communications interface 520, and the memory 530 communicate with each other via the communication bus 540. The processor 510 can call logical instructions in the memory 530 to execute the service management methods provided in the above embodiments.

[0174] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. 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.

[0175] On the other hand, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer is able to execute the service management methods provided in the above embodiments.

[0176] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the service management methods provided in the above embodiments.

[0177] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0178] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A service management method, characterized in that, Entities applied to network storage functions include: Receive a service registration request sent by a first network function entity, wherein the service registration request carries configuration information of the first network function entity, and the configuration information includes the network element type of the first network function entity; Based on the network element type, the target parameter category that the first network function entity needs to carry during registration is determined, wherein there is a preset correspondence between the target parameter category and the network element type; The configuration information is verified, and if it is determined that the configuration information does not contain valid parameter information corresponding to the target parameter category, the service registration request is rejected, and a registration failure response is returned to the first network function entity.

2. The service management method according to claim 1, characterized in that, Also includes: Receive the service update request sent by the first network function entity; When it is determined that the service update request is an indexed update operation for array type parameters, the service update request is rejected and an update failure response is returned to the first network function entity.

3. The service management method according to claim 1, characterized in that, Also includes: Receive a service update request sent by the first network function entity, wherein the service update request carries a target instance identifier and the network element type to be changed; Query the registered network element type corresponding to the target instance identifier; When the network element type to be changed is different from the registered network element type, the service update request is rejected and a change failure response is returned to the first network function entity.

4. The service management method according to claim 1, characterized in that, After verifying the configuration information, the following is also included: When it is determined that the configuration information contains valid parameter information corresponding to the target parameter category, the service registration request is accepted, and the configuration information of the first network function entity is stored. Detect conflicts between the valid parameter information of the first network functional entity and the valid parameter information of the same type of network functional entity that have been stored. When it is determined that there is an overlap or inclusion relationship between the valid parameter information of the first network function entity and the valid parameter information of the stored network function entity of the same type, a conflict alarm message is generated.

5. The service management method according to claim 1, characterized in that, Also includes: Receive a service discovery request sent by a second network function entity, wherein the service discovery request carries discovery condition parameters; Based on the discovery condition parameters, multiple candidate network function entities are obtained by matching from the configuration information of each stored network function entity. Extract the region identifier and province identifier from the instance identifier of each candidate network functional entity; When it is determined that there are differences in the region identifier or province identifier between the candidate network functional entities, the region identifier and province identifier of each candidate network functional entity are compared with the region identifier and province identifier of the second network functional entity; From the plurality of candidate network function entities, candidate network function entities whose region identifier and province identifier are the same as those of the second network function entity are selected and returned as service discovery results.

6. The service management method according to claim 5, characterized in that, The step of extracting the region identifier and province identifier from the instance identifiers of each of the candidate network functional entities includes: The instance identifiers of each candidate network functional entity are parsed according to a preset field structure. The first preset byte is extracted from the instance identifier as a region identifier, and the second preset byte is extracted as a province identifier.

7. The service management method according to claim 5, characterized in that, After matching multiple candidate network function entities from the stored configuration information of network function entities according to the discovery condition parameters, the process further includes: Obtain the number range corresponding to each candidate network functional entity, and calculate the size of the number range for each candidate network functional entity. The size of the number range is the difference between the end value and the beginning value of the number range. The candidate network functional entities are sorted in ascending order of the number range; The candidate network functional entity that ranks first after sorting is returned as the service discovery result.

8. The service management method according to claim 5, characterized in that, The step of matching multiple candidate network function entities from the stored configuration information of network function entities based on the discovery condition parameters includes: Extract the target data network name from the discovery condition parameters; For each stored network function entity, obtain the registered data network name from its configuration information; When it is determined that one of the target data network name and the registered data network name carries an operator identifier while the other does not, the network identifier portion of the target data network name and the registered data network name are extracted respectively. When the network identifiers are found to be identical and the public land mobile network identifiers are matched, the data network name is determined to be a successful match.

9. The service management method according to claim 5, characterized in that, Before matching multiple candidate network function entities from the stored configuration information of each network function entity according to the discovery condition parameters, the process further includes: Extract the target network element type from the discovery condition parameters; If it is determined that the target network element type does not belong to the pre-configured set of network element types that are allowed to be discovered solely by the target network element type, and the discovery condition parameters do not contain any other filtering conditions besides the target network element type, the service discovery request is rejected.

10. The service management method according to claim 1, characterized in that, Also includes: According to the preset inspection cycle, the configuration information of each network functional entity that has been stored is periodically verified. The periodic verification includes: determining the corresponding target parameter category according to the network element type of each network functional entity, and judging whether the configuration information of each network functional entity contains valid parameter information that matches the corresponding target parameter category. An alarm message is generated when it is detected that the configuration information of a stored network function entity does not contain valid parameter information that matches the corresponding target parameter category.

11. A service management system, characterized in that, include: The first processing module is configured to receive a service registration request sent by a first network function entity, wherein the service registration request carries configuration information of the first network function entity, and the configuration information includes the network element type of the first network function entity. The second processing module is used to determine the target parameter category that the first network function entity needs to carry during registration based on the network element type, wherein the target parameter category and the network element type have a preset correspondence. The third processing module is used to verify the configuration information, and when it is determined that the configuration information does not contain valid parameter information corresponding to the target parameter category, it rejects the service registration request and returns a registration failure response to the first network function entity.

12. The service management system according to claim 11, characterized in that, Also includes: The first processing module is further configured to receive a service discovery request sent by the second network function entity, wherein the service discovery request carries discovery condition parameters; The fourth processing module is used to match multiple candidate network functional entities from the configuration information of each network functional entity stored in the database according to the discovery condition parameters. The fifth processing module is used to extract the region identifier and province identifier from the instance identifiers of each of the candidate network functional entities; The sixth processing module is used to compare the region identifier and province identifier of each candidate network functional entity with the region identifier and province identifier of the second network functional entity when it is determined that there are differences between the region identifiers or province identifiers of the candidate network functional entities. The seventh processing module is used to filter out candidate network function entities from the plurality of candidate network function entities whose region identifier and province identifier are the same as those of the second network function entity, and return them as service discovery results.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the service management method as described in any one of claims 1 to 10.

14. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the service management method as described in any one of claims 1 to 10.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the service management method as described in any one of claims 1 to 10.

Images