Service enabling method and apparatus, service processing method and apparatus, and communication device

Abstract

The present application relates to a service enabling method and apparatus, a service processing method and apparatus, and a communication device, a computer-readable storage medium and a computer program product. The service enabling method is applied to an integrated user service unit (IUSU). The method comprises: receiving a service software download notification sent by a network and service capability depository function (NSCDF); downloading, from the NSCDF, software data of a service corresponding to the service download notification; and loading software corresponding to the software data, and enabling the service corresponding to the software. By using the method, service enabling in a 6G network architecture can be realized.

Description

Service enabling methods, service processing methods, devices and communication equipment

[0001] This application claims priority to Chinese Patent Application No. 2024106824121, filed on May 29, 2024, entitled "Business Enablement Method, Business Processing Method, Apparatus and Communication Equipment", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to a service enabling method, service processing method, apparatus, communication equipment, computer-readable storage medium, and computer program product. Background Technology

[0003] Research on 6G (6th Generation Mobile Networks) is actively underway, and there are many speculations about the 6G network architecture. For example, a related project has proposed a 6G network architecture based on an integrated user service unit, which can provide terminals with network functions and service support defined by users according to their own needs.

[0004] However, how to enable services based on this network architecture remains unresolved.

[0005] Summary of the Invention

[0006] This application provides a service enabling method, apparatus, communication device, computer-readable storage medium, and computer program product that can enable services in a 6G network architecture.

[0007] In a first aspect, this application provides a method for integrating a User Service Unit (IUSU), the method comprising:

[0008] Receive service software download notifications sent by the Network and Service Capability Storage Function (NSCDF);

[0009] Download the software data of the service corresponding to the service download notification from the NSCDF;

[0010] Load the software corresponding to the software data and enable the corresponding services.

[0011] In one embodiment, downloading the software data of the service corresponding to the service download notification from the NSCDF includes:

[0012] Determine whether the IUSU meets the service resource requirements included in the service download notification;

[0013] If the IUSU meets the service resource requirements and is configured to support service self-enablement, the service resources corresponding to the service resource requirements are reserved.

[0014] Download the software data from the NSCDF.

[0015] In one embodiment, downloading the software data from the NSCDF includes:

[0016] Send a first service software data download request to the NSCDF, wherein the first service software data download request includes the service identifier;

[0017] Receive the software data sent by the NSCDF in response to the first service software data download request.

[0018] In one embodiment, the method further includes:

[0019] In the list of services supported by the IUSU, the service identifier corresponding to the service software data is recorded to indicate that the IUSU supports the service corresponding to the service identifier.

[0020] In one embodiment, the method further includes:

[0021] A service launch success notification is sent to the NSCDF. The service launch success notification includes the service identifier. The service launch success notification is used to notify the NSCDF to record that the IUSU supports the service corresponding to the service identifier.

[0022] In one embodiment, for NSCDF, the method includes:

[0023] Send a service software download notification to the IUSU, the service software download notification being used to instruct the IUSU to download the software data of the service corresponding to the service download notification from the NSCDF.

[0024] In one embodiment, before sending the service download notification to the IUSU, the method further includes:

[0025] Receive service release notifications sent by the Service Management Gateway (SMG);

[0026] According to the business release notification, the software data is downloaded from the SMG.

[0027] In one embodiment, downloading the software data from the SMG according to the service release notification includes:

[0028] Determine whether the NSCDF meets the storage space requirements of the software data included in the service release notification;

[0029] When the NSCDF meets the storage space requirement, it sends a second service software data download request to the SMG; the second service software data download request includes a service identifier.

[0030] Receive the software data sent by the SMG according to the second service software data download request, and store the software data.

[0031] In one embodiment, the method further includes:

[0032] Receive the first service software data download request sent by the IUSU;

[0033] The software data is sent to the IUSU based on the service identifier included in the first service software data download request.

[0034] In one embodiment, the method further includes:

[0035] Receive the service startup success notification sent by the IUSU;

[0036] Record the service corresponding to the service identifier included in the successful service launch notification of the IUSU.

[0037] In one embodiment, for SMG, the method includes:

[0038] A service release notification is sent to the NSCDF, which is used to instruct the NSCDF to download the software data of the service corresponding to the service release notification from the SMG.

[0039] In one embodiment, the method further includes:

[0040] Receive the second service software data download request sent by the NSCDF;

[0041] The software data is sent to the NSCDF based on the service identifier carried in the second service software data download request.

[0042] Secondly, this application also provides a service processing method for a first IUSU, wherein the first IUSU enables services using the service enabling method described in any one of the first aspects above, the method comprising:

[0043] Receive service requests sent by the terminal;

[0044] If the service corresponding to the service request is not supported, a failure response is returned to the terminal. The failure response is used to instruct the terminal to register with a second IUSU that supports the service.

[0045] In one embodiment, the method further includes:

[0046] Based on the service identifier included in the service request and the list of services supported by the first IUSU, determine whether the service is supported;

[0047] If the service identifier is not in the service list, it is determined that the service is not supported.

[0048] In one embodiment, returning a failure response to the terminal includes:

[0049] Based on the service capability query response sent by NSCDF, the failure response is generated, and the failure response includes a list of service support IUSUs;

[0050] Send the failure response to the terminal.

[0051] In one embodiment, the method further includes:

[0052] Send a service capability query request to the NSCDF; the service capability query request includes the public IUSU list configured by the first IUSU;

[0053] Receive the service capability query response sent by the NSCDF in response to the service capability query request; the service capability query response includes the service support IUSU list.

[0054] In one embodiment, the service-supporting IUSU list includes the identifiers of one or more second IUSUs that support the service in the public IUSU list.

[0055] In one embodiment, for NSCDF, the method includes:

[0056] Receive the service capability query request sent by the first IUSU;

[0057] A service capability query response is returned to the first IUSU, and the service capability query response contains the identifiers of one or more second IUSUs that support the service corresponding to the service capability query request.

[0058] In one embodiment, a service processing method for a terminal includes:

[0059] Send a service request to the first IUSU;

[0060] When a failure response is received from the first IUSU, a second IUSU is selected based on the failure response, and a user registration request is initiated to the second IUSU.

[0061] Thirdly, this application also provides an apparatus for an IUSU, the apparatus comprising:

[0062] The first receiving module is used to receive service software download notifications sent by the Network and Service Capability Storage Function (NSCDF).

[0063] The download module is used to download the software data of the service corresponding to the service download notification from the NSCDF according to the service download notification;

[0064] The startup module is used to load and start the software corresponding to the software data.

[0065] Fourthly, this application also provides an apparatus for NSCDF, the apparatus comprising:

[0066] The second sending module is used to send a service software download notification to the IUSU. The service software download notification is used to instruct the IUSU to download the software data of the service corresponding to the service download notification from the NSCDF.

[0067] Fifthly, this application also provides an apparatus for SMG, the apparatus comprising:

[0068] The fourth sending module is used to send a service release notification to the NSCDF. The service release notification is used to instruct the NSCDF to download the software data of the service corresponding to the service release notification from the SMG.

[0069] Sixthly, this application also provides a service processing apparatus for a first IUSU, the apparatus comprising:

[0070] The fourth receiving module is used to receive service requests sent by the terminal;

[0071] The sixth sending module is used to return a failure response to the terminal if the service corresponding to the service request is not supported. The failure response is used to instruct the terminal to register with the second IUSU that supports the service.

[0072] Seventhly, this application also provides a service processing apparatus for NSCDF, the apparatus comprising:

[0073] The sixth receiving module is used to receive a service capability query request sent by the first IUSU, wherein the service capability query request is sent by the first IUSU when it does not support the service corresponding to the service request sent by the terminal;

[0074] The eighth sending module is used to return a service capability query response to the first IUSU, the service capability query response being used to indicate at least one second IUSU that supports the service.

[0075] Eighthly, this application also provides a service processing apparatus for a terminal, the apparatus comprising:

[0076] The ninth sending module is used to send service requests to the first IUSU;

[0077] The tenth sending module is used to, when receiving a failure response returned by the first IUSU, initiate a user registration request to at least one second IUSU that supports the service corresponding to the service request, as included in the failure response.

[0078] Ninthly, this application also provides a communication device. The communication device includes: a receiver and a processor;

[0079] The receiver is used to receive service download notifications sent by the Network and Service Capability Storage Function (NSCDF).

[0080] The receiver is also configured to download the software data of the service corresponding to the service download notification from the NSCDF according to the service download notification;

[0081] The processor is used to load and start the software corresponding to the software data.

[0082] Tenthly, this application also provides a communication device. The communication device includes: a transmitter;

[0083] The transmitter is used to send a service software download notification to the IUSU, which is used to instruct the IUSU to download the software data of the service corresponding to the service download notification from the NSCDF.

[0084] Eleventhly, this application also provides a communication device. The communication device includes: a transmitter;

[0085] The transmitter is used to send a service release notification to the NSCDF, and the service release notification is used to instruct the NSCDF to download the software data of the service corresponding to the service release notification from the SMG according to the service release notification.

[0086] In a twelfth aspect, this application also provides a communication device. The communication device includes: a receiver and a transmitter;

[0087] The receiver is used to receive service requests sent by the terminal;

[0088] The transmitter is used to return a failure response to the terminal if it does not support the service corresponding to the service request. The failure response is used to instruct the terminal to register with a second IUSU that supports the service.

[0089] In a thirteenth aspect, this application also provides a communication device. The communication device includes: a receiver and a transmitter;

[0090] The receiver is used to receive a service capability query request sent by the first IUSU, which is sent by the first IUSU when it does not support the service corresponding to the service request sent by the terminal.

[0091] The transmitter is used to return a service capability query response to the first IUSU, and the service capability query response is used to indicate at least one second IUSU that supports the service.

[0092] In a fourteenth aspect, this application also provides a communication device. The communication device includes: a transmitter;

[0093] The transmitter is used to send a service request to the first IUSU;

[0094] The transmitter is further configured to, upon receiving a failure response returned by the first IUSU, initiate a user registration request to at least one second IUSU included in the failure response that supports the service corresponding to the service request.

[0095] In a fifteenth aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the service enabling method described in any of the first aspects and the service processing method described in any of the second aspects.

[0096] In a sixteenth aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the business enabling method described in any of the first aspects and the business processing method described in any of the second aspects.

[0097] The aforementioned service enabling method, service processing method, apparatus, communication equipment, computer-readable storage medium, and computer program product enable the IUSU by receiving a service software download notification sent by the NSCDF, downloading the software data corresponding to the service download notification from the NSCDF, and then loading the software corresponding to the software data. Because the IUSU can pre-download the software data corresponding to the received service software download notification, and thus load the corresponding software, it can provide services to users through the pre-loaded software when receiving a user's service request. This avoids the problem of being unable to provide services to users due to the absence of the software corresponding to the service download notification in the IUSU, thereby enabling the software-corresponding service and realizing service enabling in the 6G network architecture. Attached Figure Description

[0098] Figure 1 is an application environment diagram of a service enablement method in one embodiment;

[0099] Figure 2 is a flowchart illustrating a service enablement method in one embodiment;

[0100] Figure 3 is a flowchart of step 202 in one embodiment;

[0101] Figure 4 is a flowchart of step 303 in one embodiment;

[0102] Figure 5 is a flowchart illustrating the service enablement method in another embodiment;

[0103] Figure 6 is a flowchart of step 502 in one embodiment;

[0104] Figure 7 is a flowchart illustrating the service enablement method in another embodiment;

[0105] Figure 8 is a flowchart illustrating the service enablement method in another embodiment;

[0106] Figure 9 is a flowchart illustrating the service enablement method in another embodiment;

[0107] Figure 10 is a schematic diagram of signaling interaction for a service enablement method in one embodiment;

[0108] Figure 11 is an application environment diagram of a business processing method in one embodiment;

[0109] Figure 12 is a flowchart illustrating a business processing method in one embodiment;

[0110] Figure 13 is a flowchart illustrating the business processing method in another embodiment;

[0111] Figure 14 is a flowchart of step 1002 in one embodiment;

[0112] Figure 15 is a flowchart illustrating the business processing method in another embodiment;

[0113] Figure 16 is a flowchart illustrating the business processing method in another embodiment;

[0114] Figure 17 is a flowchart illustrating the business processing method in another embodiment;

[0115] Figure 18 is a schematic diagram of signaling interaction of a service processing method in one embodiment;

[0116] Figure 19 is a structural block diagram of a service enabling device in one embodiment;

[0117] Figure 20 is a structural block diagram of a service enabling device in another embodiment;

[0118] Figure 21 is a structural block diagram of a service enabling device in another embodiment;

[0119] Figure 22 is a structural block diagram of a service processing device in one embodiment;

[0120] Figure 23 is a structural block diagram of the service processing device in another embodiment;

[0121] Figure 24 is a structural block diagram of the service processing device in another embodiment;

[0122] Figure 25 is an internal structure diagram of a communication device in one embodiment;

[0123] Figure 26 is an internal structure diagram of the communication device in another embodiment;

[0124] Figure 27 is an internal structural diagram of the communication device in another embodiment;

[0125] Figure 28 is an internal structure diagram of a communication device in another embodiment;

[0126] Figure 29 is an internal structural diagram of the communication device in another embodiment;

[0127] Figure 30 is an internal structural diagram of a communication device in another embodiment. Detailed Implementation

[0128] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0129] Figure 1 is a schematic diagram of an application scenario for a service enabling method provided in an embodiment of this application. As shown in Figure 1, this scenario includes an Integrated User-Centric Service Unit (IUSU) 100, Network and Service Capabilities Depository Functions (NSCDF) 200, and a Session Management Function (SMG) 300. Data transmission between IUSU 100 and NSCDF 200 is conducted via a network, and data transmission between NSCDF 200 and SMG 300 is also conducted via a network. Specifically, the SMG300 sends a service release notification to the NSCDF200. Upon receiving the service release notification, the NSCDF200 downloads the corresponding software data from the SMG300 and then sends a service software download notification to the IUSU100. Upon receiving the service software download notification, the IUSU, provided that the service resource requirements are met and it is configured to support autonomous service enablement, reserves the service resources corresponding to the service resource requirements, downloads the software data from the NSCDF, loads the software corresponding to the software data, and enables the service corresponding to the software, thereby realizing service enablement in the 6G network architecture.

[0130] In related technologies, after receiving a service request from a service terminal, the operator's service platform needs to determine whether it can support the service request. If it can, it downloads the corresponding software and responds to the request, providing the user with the relevant service. If it cannot support the service, it returns a response failure message to the service terminal. With the development of wireless communication technology, a user-centric integrated service unit (ISP) model has been proposed in 6G network architecture to provide services to users. However, traditional technologies do not specify or explain how to use the user-centric ISP to achieve service enablement in 6G network architecture. Therefore, traditional technologies have the problem of being unable to achieve service enablement in 6G network architecture. Based on the aforementioned traditional technologies, this application provides a service enabling method. The IUSU receives a service software download notification sent by the NSCDF, downloads the software data corresponding to the service from the NSCDF, and then enables the corresponding service by loading the software corresponding to the software data. Because the IUSU can pre-download the corresponding service software data according to the received service software download notification, and thus load the corresponding software, the IUSU can provide services to the user through the pre-loaded software when it receives a user's service request. This avoids the problem of being unable to provide the corresponding service to the user due to the absence of the software corresponding to the service download notification in the IUSU, thereby enabling the service corresponding to the software and realizing service enabling in the 6G network architecture. By receiving service software download notifications from the NSCDF, the IUSU downloads the software data corresponding to the service from the NSCDF. Then, by loading the software corresponding to the software data, the corresponding service can be enabled. In this service enabling method, the IUSU can pre-download the software data of the corresponding service based on the received service software download notification, and thus load the corresponding software. This allows the IUSU to provide services to users when it receives service requests from users through the pre-loaded software. This avoids the problem of not being able to provide services to users because the software corresponding to the service download notification is not in the IUSU, thereby enabling the corresponding service in the 6G network architecture.

[0131] It should be noted that the beneficial effects or technical problems solved by the embodiments of this application are not limited to this one, but may also be other implicit or related problems. For details, please refer to the description of the embodiments below.

[0132] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0133] In one embodiment, as shown in Figure 2, a service enabling method is provided. Taking the application of this method to IUSU100 in Figure 1 as an example, the method includes the following steps:

[0134] Step 201: Receive the service software download notification sent by the Network and Service Capability Storage Function (NSCDF).

[0135] It should be noted that the embodiments of this application describe the interaction process between different network elements in the access network within a network architecture. Here, an IUSU is a user-centric integrated service unit network element that can provide selected network functions and service capabilities to specific users of fixed, mobile, and satellite convergence within the network. In some embodiments, the IUSU can be a private IUSU created and managed by a user, capable of providing network and services to the user who created it; alternatively, the IUSU can be a public IUSU created and managed by an operator, capable of providing network and services to all users. It is understood that the access network can include one or more IUSUs. In this embodiment, a public IUSU can be used as an example to describe the interaction process of the service enabling method.

[0136] NSCDF is a network element that supports the storage and download functions of the network and services required by IUSU. The service software download notification is a signaling message sent by NSCDF to IUSU, instructing IUSU to download software data related to a specific user service. This notification may include the service name, service description, service type, service identifier, and service resource requirements. The resource requirements may include information such as bandwidth, storage resources, and computing resources corresponding to the service. Optionally, the notification may include information related to one or multiple services.

[0137] In this embodiment, the IUSU can receive service software download notifications sent by the NSCDF through the access network. As one possible implementation, the IUSU's identifier can be pre-stored in the NSCDF for use when the NSCDF sends service software download notifications to designated IUSUs.

[0138] Step 202: Download the software data corresponding to the service download notification from NSCDF.

[0139] The "service download notification" refers to the service whose identifier and description are included in the download notification. Different services provide different services to users. Each service corresponds to a set of software data, which may include the software package corresponding to that service, installation instructions, and other information. In some embodiments, the software data may include the software data for one service, or it may include the software data for multiple services, with different service identifiers for different software data sets.

[0140] In this embodiment, after receiving the service software download notification, the IUSU can determine the service corresponding to the service software download notification based on the service identifier and service description in the service software download notification, and then download the software data of the service from the NSCDF.

[0141] Step 203: Load the software corresponding to the software data and enable the corresponding services.

[0142] Understandably, once the software corresponding to the software data is loaded into IUSU, it can receive users' software usage requests and provide corresponding services to users through the software, thus enabling the business corresponding to the software.

[0143] In this embodiment, after downloading software data, the IUSU can load the software corresponding to the software data into the IUSU. After the software is successfully loaded, when the user initiates a usage request, it can provide the service corresponding to the software, thereby enabling the business corresponding to the software.

[0144] Understandably, if the IUSU does not pre-download the software data corresponding to a service, it cannot load the corresponding software. When the IUSU receives a service request from a user, it cannot provide the service corresponding to that service. Alternatively, when the IUSU receives a service request from a user, it needs to obtain and load the corresponding service software before it can provide the service to the user. Therefore, pre-downloading the software data corresponding to a service and loading the corresponding software in the IUSU enables the service to be enabled and provides services to users, while also achieving autonomous enabling of the corresponding service.

[0145] In the aforementioned service enabling method, the IUSU receives a service software download notification sent by the NSCDF, downloads the software data corresponding to the service from the NSCDF, and then enables the corresponding service by loading the software corresponding to the software data. Because the IUSU can pre-download the software data of the corresponding service based on the received service software download notification, and thus load the corresponding software, the IUSU can provide services to the user through the pre-loaded software when it receives a user's service request. This avoids the problem of being unable to provide the corresponding service to the user due to the absence of the software corresponding to the service download notification in the IUSU, thereby enabling the corresponding service in the 6G network architecture.

[0146] In the scenario described above, where the software data corresponding to the service download notification is downloaded from the NSCDF, the IUSU can download the software data from the NSCDF if it determines that it meets the software data download requirements. In one embodiment, as shown in Figure 3, step 202 may include:

[0147] Step 301: Determine whether the IUSU meets the business resource requirements included in the business download notification.

[0148] The business resource requirements refer to the bandwidth needed for downloading the software corresponding to the service within the IUSU, as well as the storage and computing resources required for loading the software. It's understandable that if the IUSU needs to download software data corresponding to a service, its own business resources must be able to meet the software data's resource requests. Therefore, before downloading software data, the IUSU needs to determine whether it meets the business resource requirements.

[0149] In this embodiment, IUSU can obtain the service resource requirements from the received service download notification, and then determine whether its own bandwidth meets the bandwidth requirement, its own storage resources meet the storage requirement, and its own computing resources meet the computing requirement, thereby determining whether it meets the service resource requirements included in the service download notification.

[0150] Step 302: If the IUSU meets the business resource requirements and is configured to support business self-enabling, reserve the business resources corresponding to the business resource requirements.

[0151] It should be noted that before providing services to users through IUSU, IUSU needs to be configured to support business autonomy so that when a business request is received from a user, the installed software can provide the corresponding service to the user.

[0152] Among them, business resources refer to the bandwidth, computing resources and storage resources corresponding to IUSU. IUSU needs to ensure that its own bandwidth can meet the bandwidth requirements of business resources, its own computing resources can meet the computing resources requirements of business resources, and its own storage resources can meet the storage resources requirements of business resources.

[0153] In this embodiment, if IUSU determines that it meets the business resource requirements and supports business self-enabling, it can reserve the business resources that meet the business resource requirements to avoid the problem of the business resources being occupied, which would lead to the failure of downloading software data.

[0154] Step 303: Download software data from NSCDF.

[0155] In some embodiments, the IUSU may also send an instruction message to the NSCD to instruct the NCDF to send software data to the IUSU, thereby downloading the software data from the NCDF; or, after a preset time period following receiving the business software download notification, the IUSU may receive a business resource query message sent by the NCDF and send a message to the NCDF containing the business resource information corresponding to the reserved business resource requirements, so that the NCDF can send software data to the IUSU after receiving the message, thereby downloading the software data from the NCDF.

[0156] In this embodiment, IUSU determines whether it meets the service resource requirements included in the service download notification. If it meets the service resource requirements and is configured to support autonomous service enabling, it reserves the corresponding service resources before downloading software data from NSCDF. Because IUSU ensures it meets the service resource requirements and reserves the corresponding resources before downloading software data, it avoids situations where it cannot meet the service resource requirements and downloads software data from NSCDF but cannot install it, thus avoiding wasted computing resources and improving the reliability of successful software data download. Furthermore, since IUSU reserves service resources and downloads software data while configured to support autonomous service enabling, it ensures that after the software data is downloaded, when a service request is received from a user, the corresponding service can be enabled.

[0157] In the scenario described above where software data is downloaded from NSCDF, IUSU can also send a software data download request to NSCD to download the software data. In one embodiment, as shown in Figure 4, step 303 may include:

[0158] Step 401: Send a first service software data download request to NSCDF. The first service software data download request includes a service identifier.

[0159] The first service software download request refers to the signaling from an IUSU requesting to download the software data corresponding to a service software notification from the NSCDF. It is understandable that, since the access network includes multiple IUSUs, when the NSCDF receives a software download request, it cannot determine which software data the request corresponds to. Therefore, the first service software download request may include a service identifier to represent the service corresponding to the first service software download request, allowing the NSCDF to determine the corresponding software data based on the represented service.

[0160] In this embodiment, the IUSU can generate a first service software data download request carrying a service identifier based on the received service software download notification.

[0161] Step 402: Receive software data sent by NSCDF in response to the first service software data download request.

[0162] In this embodiment, after sending the first service software data download request, the IUSU can wait for the NSCDF to respond to the first service software data download request and send a response message, thereby obtaining the software data corresponding to the first service software data download request from the received response message.

[0163] In this embodiment, the IUSU sends a first service software data download request including a service identifier to the NSCDF, enabling the NSCDF to determine the service corresponding to the download request based on the service identifier, determine the corresponding software data based on the service, and send it to the IUSU. Thus, the IUSU can receive the software data sent by the NSCDF in response to the first service software data download request. By sending the first service software data download request including the service identifier, the IUSU can avoid the problem of the NSCDF sending incorrect software data, thereby improving the accuracy of the software data received by the IUSU.

[0164] It should be noted that an IUSU can support multiple services. After the IUSU loads the software corresponding to a service, it can record the service identifier of the supported service. This allows for quick determination of whether a service request is supported when a user's service request is received. In one embodiment, the method further includes recording the service identifier corresponding to the service software data in the list of services supported by the IUSU, indicating that the IUSU supports the service corresponding to the service identifier.

[0165] The service list may include service identifiers corresponding to the software installed in IUSU, which represent the services that IUSU can provide to users. Optionally, the service identifier may include one service identifier, or it may include multiple service identifiers.

[0166] In this embodiment, if the software corresponding to the software data is loaded into the IUSU and the software can run successfully, the service identifier corresponding to the software can be added to the service list.

[0167] In this embodiment, IUSU records the service identifiers corresponding to the service software data in the service list supported by IUSU. Since the service list can indicate whether IUSU supports the service corresponding to the service identifier, IUSU can quickly determine whether to support the service request when it receives a user's service request by judging whether the service identifier corresponding to the service request exists in the service list, thereby improving the response efficiency to service requests.

[0168] It is understood that the NSCDF can provide storage functionality for the required network and services for the IUSU. In one embodiment, the above method further includes: sending a service launch success notification to the NSCDF, the service launch success notification including a service identifier, the service launch success notification being used to notify the NSCDF to record the service corresponding to the service identifier supported by the IUSU.

[0169] Among them, the successful service launch notification refers to the notification information generated by IUSU when IUSU has loaded the software corresponding to the software data and the software can run successfully. It is used to indicate that IUSU supports the software and can provide the software service to the user, and instructs NSCDF to record the service corresponding to the software.

[0170] In this embodiment, IUSU can generate a successful service launch notification, including a service identifier, and send the successful service launch notification to NSCDF when the software corresponding to the software data is loaded and the software can run successfully.

[0171] In this embodiment, by sending a service launch success notification including a service identifier to the NSCDF, the IUSU can instruct the NSCDF to record the services supported by the service identifier, thereby improving the effectiveness of storing the services supported by the service identifier of the IUSU. Then, when a user's service request is received, the IUSU can obtain the services supported by the IUSU from the NSCDF and quickly determine whether the IUSU supports the service request.

[0172] The following describes the interaction process of the service enablement method, using NSCDF as the execution entity. In one embodiment, taking the application of this method to NSCDF200 in Figure 1 as an example, the method includes: sending a service software download notification to the IUSU, which instructs the IUSU to download the software data of the corresponding service from NSCDF.

[0173] The service software download notification is a signaling method used by the NSCDF to notify the IUSU to download the corresponding software data. In this embodiment, the NSCDF can send the service software download notification to the IUSU through the access network, enabling the IUSU to send a software download request to the NSCDF based on the service software download notification, thereby downloading the software data of the service corresponding to the service download notification from the NSCDF.

[0174] As one possible implementation, the NSCDF can store a list of multiple IUSUs. In some embodiments, the NSCDF can send different service software download notifications to different IUSUs, or the NSCDF can send the same service software download notification to multiple IUSUs simultaneously.

[0175] In this embodiment, NSCDF sends a service software download notification to IUSU, which instructs IUSU to download the software data corresponding to the service download notification from NSCDF. This enables IUSU to download the corresponding software data according to the service software download notification, and then provide the service corresponding to the software to the user by loading the software data, thereby enabling the service.

[0176] It is understandable that before NSCDF sends the service software download notification to IUSU, it needs to receive the service release notification from SMG, and then generate the service software download notification based on the service release notification. In one embodiment, as shown in Figure 5, the above method further includes:

[0177] Step 501: Receive the service release notification sent by the Service Management Gateway (SMG).

[0178] The SMG is responsible for approving the software data submitted by the business software service provider. Upon approval, it assigns a business identifier and notifies the NSCDF via a message publishing mechanism. The business publishing notification may include the business name, description, type, identifier, and resource requirements. Resource requirements may include information such as bandwidth, storage, and computing resources. Optionally, the notification may include information for one or more businesses.

[0179] As one possible implementation, a mapping relationship between NSCDF and SMG can be established in advance. After SMG approves the software data, a notification message including the business identifier of the corresponding business of the software data can be sent to the NSCDF that has established the mapping relationship.

[0180] In this embodiment, the NSCDF can receive service publication notifications sent by the SMG through the access network. It is understood that the NSCDF can parse the service publication notifications to obtain relevant information about the corresponding service, such as service identifiers and service resource requirements.

[0181] Step 502: Download software data from SMG according to the business release notification.

[0182] The software data includes the software package corresponding to the service release notification, installation instructions for the software package, and other data. In this embodiment, NSCDF can parse the received service release notification, obtain the identifier of the software data from the parsing result, and then download the corresponding software data from the SMG based on the identifier.

[0183] In this embodiment, the NSCDF can download software data from the SMG based on the service release notification sent by the SMG. Since the service release notification is used to release approved software data, the NSCDF can determine the existence of approved software data after receiving the service release notification, and thus download the software data from the SMG. This allows the NSCDF to quickly download software data from the SMG based on the received service release notification, thereby improving the efficiency of the NSCDF in downloading software data from the SMG.

[0184] In the scenario described above, where software data is downloaded from the SMG based on a business release notification, the NSCDF can download the software data from the SMG if it determines that its own storage space meets the storage space requirements of the software data. In one embodiment, as shown in Figure 6, step 502 may include:

[0185] Step 601: Determine whether NSCDF meets the storage space requirements for the software data included in the business release notification.

[0186] Storage space requirements refer to the amount of memory that the software data needs to occupy. The larger the memory required, the larger the storage space requirement, and the smaller the memory required, the smaller the storage space requirement.

[0187] It should be noted that NSCDF only needs to download software data and does not need to load the corresponding software. In other words, NSCDF only needs to meet the storage space requirements of the software data to download software data from SMG. Therefore, when NSCDF downloads software data from SMG, it can first determine whether its own storage space meets the storage space requirements of the software data.

[0188] In this embodiment, NSCDF can parse the received service release notification, determine the storage space requirement of the software data included in the service release notification based on the parsing result, compare its own storage space size with the storage space requirement, and determine whether the storage space requirement of the software data included in the service release notification is met based on the comparison result.

[0189] Step 602: When the NSCDF meets the storage space requirements, it sends a second service software data download request to the SMG; the second service software data download request includes the service identifier.

[0190] The second software data download request refers to the signaling from which the NSCDF requests the download of software data included in the service release notification from the SMG. It is understood that the service release notification issued by the SMG may contain software data corresponding to multiple services. When the SMG receives a software download request, it cannot determine which software corresponds to that download request. Therefore, the second service software data download request may include a service identifier to characterize the service corresponding to the second service software download request, allowing the SMG to determine the software data corresponding to that service based on the characterized service.

[0191] In this embodiment, if the NSCDF meets the storage space requirements, it can generate a second service software data download request including the service identifier corresponding to the storage space requirements, and send the second service software data download request to the SMG.

[0192] Step 603: Receive the software data sent by SMG according to the second service software data download request, and store the software data.

[0193] In this embodiment, since NSCDF has sent a second service software data download request to SMG, after SMG responds to the second service software data download request, it will send the software data corresponding to the service identifier included in the second service software data download request to NSCDF. Thus, NSCDF can receive the software data sent by SMG according to the second service software data download request, store the software data, send a service download notification to IUSU, and send the software data to IUSU.

[0194] In this embodiment, the NSCDF determines whether it meets the storage space requirements of the software data included in the service release notification. If the NSCDF meets the storage space requirements, it sends a second service software data download request, including the service identifier, to the SMG. Then, it receives the software data sent by the SMG according to the second service software data download request and stores the software data. This avoids the problem of downloading software data from the SMG when the NSCDF's storage space is insufficient, which would lead to download failure and waste of computing resources. This improves the reliability of the NSCDF downloading software data from the SMG.

[0195] The following describes the process of NSCDF sending software data to IUSU, using NSCDF as the executing entity. In one embodiment, the above method is used for NSCDF, as shown in Figure 7. The method further includes:

[0196] Step 701: Receive the first service software data download request sent by IUSU.

[0197] Understandably, when IUSU receives a business software download notification, if its own business origin meets the business resource requirements, it can generate a first business software data download request carrying a business identifier.

[0198] In this embodiment, the NSCDF can receive the first service software data download request sent by the IUSU through the access network.

[0199] Step 702: Send software data to IUSU according to the service identifier included in the first service software data download request.

[0200] It is understandable that NSCDF can identify a service using a service identifier, thereby determining the corresponding software data. In this embodiment, NSCDF can identify the service corresponding to the first service software data download request using the service identifier included in the first service software data download request, thereby enabling it to determine the corresponding software data based on the service and send it to IUSU.

[0201] In this embodiment, the NSCDF receives a first service software data download request sent by the IUSU. Since the first service software data download request includes a service identifier, the NSCDF can determine the service corresponding to the first service software data download request based on the service identifier. This allows the NSCDF to accurately determine the software data corresponding to the service and send the software data to the IUSU, thus improving the accuracy of the sent software data.

[0202] It is understandable that NSCDF can provide IUSU with the necessary storage functionality for networking and services. In one embodiment, as shown in Figure 8, the above method further includes:

[0203] Step 801: Receive the service startup success notification sent by IUSU.

[0204] In this embodiment, if the IUSU has loaded the software corresponding to the software data and the software can run successfully, the NSCDF can generate a successful startup notification including the service identifier and send the successful startup notification to the NSCDF, and then receive the successful startup notification sent by the IUSU.

[0205] Step 802: Record the service corresponding to the service identifier included in the IUSU support service startup success notification.

[0206] In this embodiment, after receiving a successful service launch notification, NSCDF can parse the notification, determine the service identifier included in the notification based on the parsing result, and then record the service corresponding to the service identifier.

[0207] In this embodiment, by receiving a successful service launch notification sent by IUSU, NSCDF can record the service corresponding to the service identifier included in the successful service launch notification supported by IUSU, thereby improving the effectiveness of storing the services supported by IUSU. Then, when a user's service request is received, the service supported by IUSU can be obtained from NSCDF and the service supported by IUSU can be quickly determined whether IUSU supports the service request.

[0208] The following describes the interaction process of the service enablement method, using SMG as the execution entity. In one embodiment, the above method is used by SMG, and the method further includes: sending a service release notification to NSCDF, wherein the service release notification is used to instruct NSCDF to download the software data of the service corresponding to the service release notification from SMG.

[0209] Understandably, to ensure that IUSU can successfully load the software corresponding to the downloaded software data, SMG needs to approve the software data submitted by the software provider. If the software data matches IUSU, the approval is granted; if the software data does not match IUSU, the approval is denied. This approval process may include reviewing the code and data format of the software packages within the software data.

[0210] In this embodiment, the SMG can generate a service release notification and send it to the NSCDF after approving the software data submitted by the software provider. This allows the NSCDF to download the software data of the service corresponding to the service release notification from the SMG.

[0211] In this embodiment, the SMG sends a service release notification to the NSCDF. Since the service release notification is used to instruct the NSCDF to download the software data of the service corresponding to the service release notification from the SMG, the NSCDF can quickly determine that the SMG contains approved software data through the service release notification, and thus download the approved software data from the SMG, thereby improving the efficiency of the NSCDF in downloading software data from the SMG.

[0212] In the scenario described above where the SMG sends a service release notification to the NSCDF, the SMG can send the requested software data to the NSCDF upon receiving a second service software data download request from the NSCDF. In one embodiment, as shown in Figure 9, the method further includes:

[0213] Step 901: Receive the second service software data download request sent by NSCDF.

[0214] In this embodiment, after the SMG sends a service release notification to the NSCDF, the NSCDF can determine whether its own storage space meets the storage space requirements of the software data based on the service release notification. If it does, the NSCDF generates a second service software data download request and sends it to the SMG, so that the SMG can receive the second software data download request sent by the NSCDF.

[0215] Step 902: Send software data to NSCDF according to the service identifier carried in the second service software data download request.

[0216] Understandably, since SMG may contain multiple approved software data, when SMG receives a software data download request, it cannot determine the corresponding software data. Therefore, it can determine the business based on the business identifier, and then determine the corresponding software data based on the business.

[0217] In this embodiment, the SMG can parse the second service software data download request, determine the service identifier based on the parsing result, then determine the corresponding service based on the service identifier, and then determine the software data corresponding to the service as the software data corresponding to the second service software data download request and send it to the NSCDF.

[0218] In this embodiment, the SMG receives a second service software data download request sent by the NSCDF and can send software data to the NSCDF according to the service identifier carried in the second service software data download request. Since the SMG can quickly and accurately determine the service corresponding to the service identifier, it can determine the software data corresponding to the service as the software data corresponding to the second service software data download request, and then send the determined software data to the NSCDF, thereby improving the efficiency and accuracy of the software data sent to the NSCDF.

[0219] In one embodiment, Figure 10 provides a signaling interaction flowchart for a service enablement method. As shown in Figure 10, the method includes the following steps:

[0220] S1, upon receiving and approving the software data, SMG generates and sends a notification to NSCDF for service publication.

[0221] S2, NSCDF determines whether it meets the storage space requirements of the software data included in the business release notification, and if the storage space requirements are met, NSCDF sends a second business software data download request to SMG.

[0222] S3, SMG sends software data to NSCDF based on the service identifier carried in the second service software data download request.

[0223] S4, NSCDF sends a business software download notification to IUSU.

[0224] S5, IUSU determines whether it meets the business resource requirements included in the business download notification, and if it meets the business resource requirements and is configured to support business self-enablement, it reserves the business resources corresponding to the business resource requirements and sends the first business software data download request to NSCDF.

[0225] S6, NSCDF sends software data to IUSU based on the service identifier included in the first service software data download request.

[0226] S7, IUSU loads the software corresponding to the software data and enables the corresponding services.

[0227] S8, IUSU records the service identifier corresponding to the service software data in the list of services supported by IUSU.

[0228] S9 sends a service startup success notification to NSCDF.

[0229] S10, NSCDF records IUSU support services corresponding to service identifiers.

[0230] Figure 11 is a schematic diagram of an application scenario of a service processing method provided in an embodiment of this application. As shown in Figure 11, the scenario includes NSCDF200, a first IUSU400, a second IUSU500, and a terminal 600. The first IUSU400 transmits data with NSCDF200, the second IUSU500, and the terminal 600 via the network. The terminal 600 also transmits data with the second IUSU500 via the network. The terminal 600 can send a service request to the first IUSU400. The first IUSU can send a service capability query request to NSCDF200, generate a failure response based on the service capability query response returned by NSCDF200, and send the failure response to the terminal 600. Upon receiving the failure response, the terminal 600 can select a second IUSU500 based on the failure response and initiate a user registration request to the second IUSU500.

[0231] In one embodiment, as shown in FIG12, a service processing method is provided. Taking the application of this method to the first IUSU400 in FIG12 as an example, the first IUSU can perform service processing when the service is enabled using the above-described service enabling method. The service processing method includes the following steps:

[0232] Step 1201: Receive the service request sent by the terminal.

[0233] Here, the first IUSU refers to a private IUSU, which is a network element created and managed by the user. The first IUSU can only provide services to registered users and provided that the software corresponding to the service request exists. The service request is a request generated by the terminal based on the user's software usage request, used to apply to the first IUSU for the corresponding service.

[0234] In this embodiment, the first IUSU can receive service requests sent by the terminal. Optionally, there can be one service request, or there can be multiple service requests. Optionally, the service request received by the first IUSU may be responsive, or the service request received by the first IUSU may be unresponsive.

[0235] Step 1202: If the service corresponding to the service request is not supported, a failure response is returned to the terminal. The failure response is used to instruct the terminal to register with the second IUSU that supports the service.

[0236] The second IUSU refers to the public IUSU, which is a network element created and managed by the operator. The second IUSU can provide services to all users. It should be noted that different service requests may correspond to different software. If the first IUSU includes the software corresponding to the service request, then the service request will be responded to; if the first IUSU does not include the software corresponding to the service request, then the service request will not be responded to.

[0237] In this embodiment, if the software corresponding to the service request does not exist in the first IUSU, it can be determined that the first IUSU does not support the service corresponding to the service request. In this case, the first IUSU can return a failure response to the terminal, and the failure response may include a second IUSU that supports the service corresponding to the service request, thereby instructing the terminal to register with the second IUSU. After registering with the second IUSU, the terminal can initiate a service request to the second IUSU to realize the response to the terminal's service request.

[0238] Understandably, since the first IUSU cannot respond to the service request, it means that the first IUSU does not support the user. Therefore, the terminal corresponding to the user can register with a public IUSU to apply for services, for example, by initiating service registration with the second IUSU that supports the service corresponding to the service request.

[0239] In the above-mentioned business processing method, the first IUSU, by receiving the business request sent by the terminal, can return a failure response to the terminal if it does not support the business corresponding to the business request. Since the failure response can instruct the terminal to register with the second IUSU that supports the business, the terminal can be instructed to register with the second IUSU if the first IUSU cannot respond to the business request, thus avoiding the problem of the business request initiated by the terminal being unresponsive, thereby improving the reliability of providing services to users.

[0240] In the scenario described above where the first IUSU receives a service request sent by the terminal, the first IUSU can determine whether to support the service request based on the service identifier of the service request itself. In one embodiment, as shown in Figure 13, the method further includes:

[0241] Step 1301: Determine whether the service is supported based on the service identifier included in the service request and the list of services supported by the first IUSU.

[0242] Among them, the business identifier is used to represent the business information corresponding to the business request. Different business identifiers correspond to different business requests. The first IUSU is based on

[0243] In this embodiment, the first IUSU can parse the service request, determine the service identifier corresponding to the service request based on the parsing result, and then query whether the first IUSU exists in the service list supported by the first IUSU. Based on the query result, it can determine whether the first IUSU supports the service corresponding to the service request.

[0244] Step 1302: If the service identifier is not in the service list, determine that the service is not supported.

[0245] Understandably, if a service identifier exists in the service list, it means that the first IUSU includes the software for the service corresponding to that service identifier, and the first IUSU can provide the service for that service; if a service identifier does not exist in the service list, it means that the first IUSU does not include the software for the service corresponding to that service identifier, and the first IUSU cannot provide the service for that service.

[0246] In this embodiment, if the first IUSU determines that the service identifier is not in the service list, it means that the first IUSU does not include the software of the service corresponding to the service identifier. That is, the first IUSU cannot provide the service corresponding to the service to the terminal, and it can be determined that the first IUSU does not support the service.

[0247] In this embodiment, the first IUSU can quickly determine whether a service identifier exists in the service list based on the service identifier included in the service request and the service list supported by the first IUSU. This allows it to quickly determine whether the first IUSU supports the service. Furthermore, if the service identifier is not in the service list, it can quickly determine that the first IUSU does not support the service, thus improving the response speed of the first IUSU to service requests.

[0248] In the scenario described above where a failure response is returned to the terminal, the first IUSU can generate a failure response through the service capability query response sent by NSCDF. In one embodiment, as shown in Figure 14, step 1202 above may include:

[0249] Step 1401: Generate a failure response based on the service capability query response sent by NSCDF. The failure response includes a list of service support IUSUs.

[0250] The service capability query response refers to the response message that NSCDF sends after receiving a service capability query from the first IUSU. It can be understood that NSCDF can record the services corresponding to the software that is installed and successfully running in the first IUSU. Therefore, after receiving the service capability query from the first IUSU, it can combine the recorded information to determine which services the public IUSUs included in the service capability query support, thereby generating a list of service-supported IUSUs. This list includes the identifiers of the public IUSUs that support the requested service.

[0251] In this embodiment, when the first IUSU cannot support the service corresponding to the service request, it can send query information including its own pre-configured list of public IUSUs to the NSCDF, thereby receiving the service capability query response generated by the NSCDF based on the query information and pre-stored records. Then, by parsing the service capability query response, it can obtain the list of service-supporting IUSUs and generate a failure response based on the IUSUs that support the service corresponding to the service request.

[0252] In some embodiments, the service-supported IUSU list includes the identifiers of one or more second IUSUs that support the service in the public IUSU list.

[0253] The second IUSU is a pre-configured public IUSU within the first IUSU that can provide services to all users. The public IUSU list may include identifiers of one or more second IUSUs. It should be noted that for different service requests, some second IUSUs support the corresponding service, while others do not. Therefore, for a given service request, it is necessary to determine the second IUSU supporting the service from the public IUSU list and generate a service-supported IUSU list based on all supporting second IUSUs. Optionally, the service-supported IUSU list may include the identifier of one second IUSU supporting the service request, or it may include the identifiers of multiple second IUSUs supporting the service request.

[0254] Step 1402: Send a failure response to the terminal.

[0255] In this embodiment, the first IUSU can send the generated failure response to the terminal via the network.

[0256] In this embodiment, the first IUSU generates a failure response based on the list of service-supporting IUSUs in the service capability query response sent by NSCDF. This failure response includes the identifier of the public IUSU that supports the service request. The terminal then sends the failure response to the terminal, enabling the terminal to determine the public IUSU that can support the service request based on the failure response. The terminal can then re-register with the public IUSU and send the service request, thereby obtaining the service provided by the public IUSU.

[0257] In the scenario described above, where a failure response is generated based on the service capability query response sent by NSCDF, the first IUSU can send a service capability query request to NSCDF and receive the service capability query response returned by NSCDF. In one embodiment, as shown in Figure 15, the method further includes:

[0258] Step 1501: Send a service capability query request to NSCDF; the service capability query request includes a list of public IUSUs configured in the first IUSU.

[0259] The service capability query request is a request used by the first IUSU to obtain information from the NSCDF about the public IUSUs configured to provide services to all users. It should be noted that different public IUSUs can be configured for different first IUSUs. When the first IUSU cannot support the service corresponding to the service request, it can instruct the terminal to register with its own configured public IUSUs and resend the service request. The public IUSU list is a list of pre-configured public IUSUs in the first IUSU.

[0260] In this embodiment, the first IUSU can generate a service capability management query request based on its own pre-configured list of public IUSUs and send the service capability query request to NSCDF.

[0261] Step 1502: Receive the business capability query response sent by NSCDF in response to the business capability query request; the business capability query response includes a list of business support IUSUs.

[0262] In this embodiment, the first IUSU can receive a service capability query response generated by NSCDF based on the service capability query request via the network, and then determine the public IUSU that supports a certain service request through the service support IUSU list in the service capability query response.

[0263] In this embodiment, the first IUSU sends a service capability query request, which includes a list of public IUSUs configured by the first IUSU, to the NSCDF. This allows the first IUSU to receive a service capability query response from the NSCDF in response to the service capability query request. Based on the list of service-supporting IUSUs included in the service capability query response, the first IUSU can determine the public IUSUs that support the service corresponding to the service request. Furthermore, if the service request cannot be supported, the first IUSU can return a failure response, which includes a list of service-supporting IUSUs, to the terminal. This instructs the terminal to re-register with the IUSUs in the list of service-supporting IUSUs and resend the service request, thereby improving the reliability of providing services to users.

[0264] The following describes the interaction process of the business processing method using NSCDF as the execution entity. In one embodiment, the above method is used in NSCDF, as shown in Figure 16. The method further includes:

[0265] Step 1601: Receive the service capability query request sent by the first IUSU.

[0266] The service capability query request is generated and sent by the first IUSU when it is unable to support the service corresponding to the service request sent by the terminal. The service capability query request may include a list of public IUSUs pre-configured in the first IUSU.

[0267] In this embodiment, NSCDF can receive a service capability query request sent by the first IUSU via the network.

[0268] Step 1602: Return a business capability query response to the first IUSU. The business capability query response contains the identifiers of one or more second IUSUs that support the business corresponding to the business capability query request.

[0269] The business capability query response is generated by NSCDF based on the business capability query request and after checking whether the public IUSUs in the public IUSU list in the business capability query request support the business request corresponding to the business request. If the public IUSU in the public IUSU list supports the business request corresponding to the business request, then the public IUSU is determined as the second IUSU, and a business capability query response is generated based on all the second IUSUs and returned to the first IUSU.

[0270] In this embodiment, NSCDF receives a service capability query request sent by a first IUSU. It can determine a second IUSU that supports the service request corresponding to the service capability query request based on the list of common IUSUs in the service capability query request. It can then generate a service capability query response based on the second IUSU and return the service capability query response to the first IUSU. This enables the first IUSU to generate a failure response based on the service capability query response, ensuring that the terminal can re-determine a second IUSU that can support the service request based on the failure response, thereby improving the reliability of providing services for the service requests sent by the terminal.

[0271] The following describes the interaction process of the business processing method, using the terminal as the execution subject. In one embodiment, the above method is used on a terminal, as shown in Figure 17. The method further includes:

[0272] Step 1701: Send a service request to the first IUSU.

[0273] Here, a service request refers to a user's request to use a specific software. In this embodiment, when the terminal receives a user's request to use the software, it can generate a service request based on the software usage request and send the generated service request to the first IUSU via the network.

[0274] It is understandable that the first IUSU can be an IUSU that the user corresponding to the business request has pre-registered.

[0275] Step 1702: When a failure response is received from the first IUSU, a second IUSU is selected based on the failure response, and a user registration request is sent to the second IUSU.

[0276] It should be noted that if the software corresponding to the business request does not exist in the first IUSU, the service corresponding to the software cannot be provided to the user, and a failure response will be generated. The failure response may include a public IUSU that can provide the service corresponding to the software to the user, namely the second IUSU.

[0277] In this embodiment, if the first IUSU cannot support the service corresponding to the service request sent by the terminal, the terminal will receive a failure response returned by the first IUSU. By parsing the failure response, a second IUSU that supports the service corresponding to the service request can be obtained. Thus, a second IUSU can be determined from the parsing result, and a user registration request can be initiated to the second IUSU.

[0278] Understandably, the failure response may include multiple second IUSUs, from which the terminal can select any one of the second IUSUs and initiate a user registration request to the selected second IUSU.

[0279] In this embodiment, by sending a service request to the first IUSU, the terminal can, upon receiving a failure response from the first IUSU, select one of the multiple second IUSUs included in the failure response and initiate a user registration request to the second IUSU. This allows the terminal to send a service request to the second IUSU if the registration request is successful. Since the second IUSU supports the service corresponding to the service request, after the terminal sends the service request to the second IUSU, the second IUSU can support the service corresponding to the service request and thus respond to the service request, improving the reliability of providing services to the user.

[0280] In one embodiment, Figure 18 provides a signaling interaction flowchart of a service processing method. As shown in Figure 18, the method includes the following steps.

[0281] S1, the first IUSU receives the service request sent by the terminal.

[0282] S2, if the service corresponding to the service request is not supported, determine whether the service is supported based on the service identifier included in the service request of the first IUSU and the list of services supported by the first IUSU. If the service identifier is not in the list of services, the first IUSU determines that the service is not supported.

[0283] S3, the first IUSU sends a service capability query request to NSCDF.

[0284] S4, NSCDF returns a business capability query response to the first IUSU.

[0285] S5, the first IUSU generates a failure response based on the service capability query response sent by NSCDF and sends the failure response to the terminal.

[0286] S6. Based on the failure response, the terminal selects a second IUSU and initiates a user registration request to the second IUSU.

[0287] It should be understood that although the steps in the flowchart above are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0288] In one embodiment, as shown in FIG19, a service enabling device is provided, including: a first receiving module 1901, a downloading module 1902, and a startup module 1903, wherein:

[0289] The first receiving module 1901 is used to receive service software download notifications sent by the Network and Service Capability Storage Function (NSCDF).

[0290] The download module 1902 is used to download the software data of the corresponding business from the NSCDF according to the business download notification.

[0291] The startup module 1903 is used to load and start the software corresponding to the software data.

[0292] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0293] In one embodiment, the download module 1901 includes: a determining unit, a processing unit, and a first download unit, wherein:

[0294] The determination unit is used to determine whether the IUSU meets the business resource requirements included in the business download notification.

[0295] The processing unit is used to reserve the business resources corresponding to the business resource requirements when the IUSU meets the business resource requirements and is configured to support business self-enablement.

[0296] The first download unit is used to download software data from NSCDF.

[0297] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0298] In one embodiment, the download unit is specifically configured to: send a first service software data download request to the NSCDF, the first service software data download request including a service identifier; and receive software data sent by the NSCDF in response to the first service software data download request.

[0299] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0300] In one embodiment, the above-described apparatus further includes a first recording module, wherein:

[0301] The first recording module is used to record the service identifier corresponding to the service software data in the list of services supported by IUSU, which indicates the service corresponding to the service identifier supported by IUSU.

[0302] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0303] In one embodiment, the above-described apparatus further includes a first transmitting module, wherein:

[0304] The first sending module is used to send a service launch success notification to NSCDF. The service launch success notification includes a service identifier and is used to notify NSCDF to record the IUSU that supports the service corresponding to the service identifier.

[0305] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0306] In one embodiment, as shown in FIG20, a service enabling device is provided, comprising: a second transmitting module 2001, wherein:

[0307] The second sending module 2001 is used to send a service software download notification to the IUSU. The service software download notification is used to instruct the IUSU to download the software data of the corresponding service from the NSCDF.

[0308] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0309] In one embodiment, the second sending module 2001 includes: a receiving unit and a second downloading unit, wherein:

[0310] The receiving unit is used to receive service release notifications sent by the Service Management Gateway (SMG).

[0311] The second download unit is used to download software data from SMG based on business release notifications.

[0312] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0313] In one embodiment, the second download unit is specifically used to: determine whether the NSCDF meets the storage space requirements of the software data included in the service release notification; if the NSCDF meets the storage space requirements, send a second service software data download request to the SMG; the second service software data download request includes a service identifier; receive the software data sent by the SMG according to the second service software data download request, and store the software data.

[0314] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0315] In one embodiment, the above-described apparatus further includes a first receiving module and a third transmitting module, wherein:

[0316] The first receiving module is used to receive the first service software data download request sent by IUSU.

[0317] The third sending module is used to send software data to IUSU based on the service identifier included in the first service software data download request.

[0318] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0319] In one embodiment, the above-described apparatus further includes: a second receiving module and a second recording module, wherein:

[0320] The second receiving module is used to receive the service startup success notification sent by IUSU.

[0321] The second recording module is used to record the service corresponding to the service identifier included in the IUSU support service startup success notification.

[0322] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0323] In one embodiment, as shown in FIG21, a service enabling device is provided, including: a fourth transmitting module 2101, wherein:

[0324] The fourth sending module 2101 is used to send a service release notification to the NSCDF. The service release notification is used to instruct the NSCDF to download the software data of the service corresponding to the service release notification from the SMG.

[0325] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0326] In one embodiment, the above-described apparatus further includes: a third receiving module and a fifth transmitting module, wherein:

[0327] The third receiving module is used to receive the second service software data download request sent by NSCDF.

[0328] The fifth sending module is used to send software data to NSCDF based on the service identifier carried in the second service software data download request.

[0329] The service enabling device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0330] Specific limitations regarding the service enabling device can be found in the limitations on the service enabling method described above, and will not be repeated here. Each module in the aforementioned service enabling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0331] In one embodiment, as shown in FIG22, a service processing apparatus is provided, including: a fourth receiving module 2201 and a sixth transmitting module 2202, wherein:

[0332] The fourth receiving module 2201 is used to receive service requests sent by the terminal;

[0333] The sixth sending module 2202 is used to return a failure response to the terminal when the service corresponding to the service request is not supported. The failure response is used to instruct the terminal to register with the second IUSU that supports the service.

[0334] The business processing device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0335] In one embodiment, the above-mentioned apparatus includes: a first determining module and a second determining module, wherein:

[0336] The first determination module is used to determine whether a service is supported based on the service identifier included in the service request and the list of services supported by the first IUSU;

[0337] The second determination module is used to determine that the service is not supported if the service identifier is not in the service list.

[0338] The business processing device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0339] In one embodiment, the sixth transmitting module 2202 includes: a generating unit and a transmitting unit, wherein:

[0340] The generation unit is used to generate a failure response based on the service capability query response sent by NSCDF. The failure response includes a list of service-supporting IUSUs. Optionally, the list of service-supporting IUSUs includes the identifiers of one or more second IUSUs that support the service in the public IUSU list.

[0341] The sending unit is used to send a failure response to the terminal.

[0342] The business processing device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0343] In one embodiment, the above-described apparatus further includes: a seventh transmitting module and a fifth receiving module, wherein:

[0344] The seventh sending module is used to send a service capability query request to the NSCDF; the service capability query request includes a list of public IUSUs configured in the first IUSU.

[0345] The fifth receiving module is used to receive the service capability query response sent by NSCDF in response to the service capability query request; the service capability query response includes a list of service support IUSUs.

[0346] The business processing device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0347] In one embodiment, as shown in FIG23, a service processing apparatus is provided, including: a sixth receiving module 2301 and an eighth transmitting module 2302, wherein:

[0348] The sixth receiving module 2301 is used to receive the service capability query request sent by the first IUSU. The service capability query request is sent by the first IUSU when it does not support the service corresponding to the service request sent by the terminal.

[0349] The eighth sending module 2302 is used to return a service capability query response to the first IUSU, and the service capability query response is used to indicate at least one second IUSU that supports the service.

[0350] The business processing device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0351] In one embodiment, as shown in FIG24, a service processing apparatus is provided, including: a ninth sending module 2401 and a tenth sending module 2402, wherein:

[0352] The ninth sending module 2401 is used to send a service request to the first IUSU.

[0353] The tenth sending module 2402 is used to, if it receives a failure response returned by the first IUSU, initiate a user registration request to the second IUSU, which includes at least one service supporting the service request, based on the failure response.

[0354] The business processing device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0355] Specific limitations regarding the business processing device can be found in the limitations regarding the business processing method described above, and will not be repeated here. Each module in the aforementioned business processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0356] In one embodiment, as shown in FIG25, a communication device is provided. FIG25 is a schematic diagram of the structure of the access network device provided in this embodiment. The access network device may include a receiver 251, a memory 252, a processor 253, at least one communication bus 254, and a transmitter 255. The communication bus 254 is used to realize communication connections between components. The memory 252 may include a high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage. The memory 252 can store various programs for performing various processing functions and implementing the method steps of this embodiment. In this embodiment, the transmitter 255 may be a radio frequency processing module or a baseband processing module in the access network device, and the receiver 251 may also be a radio frequency processing module or a baseband processing module in the access network device. The transmitter 255 and the receiver 251 may be integrated together to form a transceiver. Both the transmitter 255 and the receiver 251 may be coupled to the processor 253, and can perform receiving or transmitting actions under the instruction or control of the processor 253.

[0357] In this embodiment, the receiver is used to receive the service software download notification sent by the Network and Service Capability Storage Function (NSCDF); the processor is used to download the software data of the service corresponding to the service download notification from the NSCDF; the processor is also used as a transmitter to load the software corresponding to the software data and enable the service corresponding to the software.

[0358] In one embodiment, the processor is used to determine whether the IUSU meets the service resource requirements included in the service download notification; if the IUSU meets the service resource requirements and is configured to support service self-enablement, it reserves the service resources corresponding to the service resource requirements; and downloads software data from the NSCDF.

[0359] In one embodiment, the transmitter is used to send a first service software data download request to the NSCDF, the first service software data download request including a service identifier; the receiver is used to receive software data sent by the NSCDF in response to the first service software data download request.

[0360] In one embodiment, the processor is used to record the service identifier corresponding to the service software data in the list of services supported by IUSU, so as to indicate the service corresponding to the service identifier supported by IUSU.

[0361] In one embodiment, the transmitter is used to send a service launch success notification to the NSCDF. The service launch success notification includes a service identifier and is used to notify the NSCDF to record the IUSU that it supports the service corresponding to the service identifier.

[0362] In one embodiment, as shown in FIG26, a communication device is provided. FIG26 is a schematic diagram of the structure of the access network device provided in this embodiment. The access network device may include a receiver 261, a memory 262, a processor 263, at least one communication bus 264, and a transmitter 265. The communication bus 264 is used to realize communication connections between components. The memory 262 may include a high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage. The memory 262 can store various programs for performing various processing functions and implementing the method steps of this embodiment. In this embodiment, the transmitter 265 can be a radio frequency processing module or a baseband processing module in the access network device, and the receiver 261 can also be a radio frequency processing module or a baseband processing module in the access network device. The transmitter 265 and the receiver 261 can be integrated together to form a transceiver. Both the transmitter 265 and the receiver 261 can be coupled to the processor 263, and can perform receiving or transmitting actions under the instruction or control of the processor 263.

[0363] In this embodiment, the transmitter is used to send a service software download notification to the IUSU. The service software download notification is used to instruct the IUSU to download the software data of the service corresponding to the service download notification from the NSCDF.

[0364] In one embodiment, the receiver is used to receive a service release notification sent by the Service Management Gateway (SMG); the processor is used to download software data from the SMG based on the service release notification.

[0365] In one embodiment, the processor determines whether the NSCDF meets the storage space requirements of the software data included in the service release notification; if the NSCDF meets the storage space requirements, it sends a second service software data download request to the SMG; the second service software data download request includes a service identifier; it receives the software data sent by the SMG according to the second service software data download request and stores the software data.

[0366] In one embodiment, the receiver is configured to receive a first service software data download request sent by the IUSU; the transmitter is configured to send software data to the IUSU according to the service identifier included in the first service software data download request.

[0367] In one embodiment, the receiver is used to receive a service launch success notification sent by the IUSU; the processor is used to record the service corresponding to the service identifier included in the IUSU support service launch success notification.

[0368] In one embodiment, as shown in FIG27, a communication device is provided. FIG27 is a schematic diagram of the structure of the access network device provided in this embodiment. The access network device may include a receiver 2671, a memory 272, a processor 273, at least one communication bus 274, and a transmitter 275. The communication bus 274 is used to realize communication connections between components. The memory 272 may include a high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage. The memory 272 can store various programs for performing various processing functions and implementing the method steps of this embodiment. In this embodiment, the transmitter 275 may be a radio frequency processing module or a baseband processing module in the access network device, and the receiver 271 may also be a radio frequency processing module or a baseband processing module in the access network device. The transmitter 275 and the receiver 271 may be integrated together to form a transceiver. Both the transmitter 275 and the receiver 271 may be coupled to the processor 273, and can perform receiving or transmitting actions under the instruction or control of the processor 273.

[0369] In this embodiment, the transmitter is used to send a service publication notification to the NSCDF, which instructs the NSCDF to download the software data of the service corresponding to the service publication notification from the SMG.

[0370] In one embodiment, the receiver is used to receive a second service software data download request sent by the NSCDF; the transmitter is used to send software data to the NSCDF according to the service identifier carried in the second service software data download request.

[0371] In one embodiment, as shown in FIG28, a communication device is provided. FIG28 is a schematic diagram of the structure of the access network device provided in this embodiment. The access network device may include a receiver 281, a memory 282, a processor 283, at least one communication bus 284, and a transmitter 285. The communication bus 284 is used to realize communication connections between components. The memory 282 may include a high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage. The memory 282 can store various programs for performing various processing functions and implementing the method steps of this embodiment. In this embodiment, the transmitter 285 may be a radio frequency processing module or a baseband processing module in the access network device, and the receiver 281 may also be a radio frequency processing module or a baseband processing module in the access network device. The transmitter 285 and the receiver 281 may be integrated together to form a transceiver. Both the transmitter 285 and the receiver 281 may be coupled to the processor 283, and can perform receiving or transmitting actions under the instruction or control of the processor 283.

[0372] In this embodiment, the receiver is used to receive service requests sent by the terminal; the transmitter is used to return a failure response to the terminal if the service corresponding to the service request is not supported, and the failure response is used to instruct the terminal to register with the second IUSU that supports the service.

[0373] In one embodiment, the processor is configured to determine whether a service is supported based on the service identifier included in the service request and the list of services supported by the first IUSU; if the service identifier is not in the service list, it is determined that the service is not supported.

[0374] In one embodiment, the processor is used to generate a failure response based on the service capability query response sent by NSCDF, the failure response including a list of service-supported IUSUs; the transmitter is used to send the failure response to the terminal.

[0375] In one embodiment, the transmitter is used to send a service capability query request to the NSCDF; the service capability query request includes a list of public IUSUs configured for the first IUSU; the receiver is used to receive a service capability query response sent by the NSCDF in response to the service capability query request; the service capability query response includes a list of service-supporting IUSUs.

[0376] In one embodiment, as shown in FIG29, a communication device is provided. FIG29 is a schematic diagram of the structure of the access network device provided in this embodiment. The access network device may include a receiver 291, a memory 292, a processor 293, at least one communication bus 294, and a transmitter 295. The communication bus 294 is used to realize communication connections between components. The memory 292 may include a high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage. The memory 292 can store various programs for performing various processing functions and implementing the method steps of this embodiment. In this embodiment, the transmitter 295 may be a radio frequency processing module or a baseband processing module in the access network device, and the receiver 291 may also be a radio frequency processing module or a baseband processing module in the access network device. The transmitter 295 and the receiver 291 may be integrated together to form a transceiver. Both the transmitter 295 and the receiver 291 may be coupled to the processor 293, and can perform receiving or transmitting actions under the instruction or control of the processor 293.

[0377] In this embodiment, the receiver is used to receive a service capability query request sent by the first IUSU; the transmitter is used to return a service capability query response to the first IUSU, and the service capability query response contains the identifiers of one or more second IUSUs that support the service corresponding to the service capability query request.

[0378] In one embodiment, as shown in FIG30, a communication device is provided. FIG30 is a schematic diagram of the structure of a terminal device provided in an embodiment of the present invention. The terminal device 3000 shown in FIG30 includes: at least one processor 3001, a memory 3002, at least one network interface 3004, and a user interface 3003. The various components in the terminal device 3000 are coupled together through a bus system 3005. It is understood that the bus system 3005 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 3005 also includes a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus system 3005 in FIG1. ​​In addition, the embodiment of the present invention also includes a transceiver 3006, which may be multiple elements, including a transmitter and a receiver, providing a unit for communicating with various other devices over a transmission medium.

[0379] The user interface 3003 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0380] It is understood that the memory 3002 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 3002 of the systems and methods described in the embodiments of the present invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0381] In some implementations, memory 3002 stores elements, executable modules or data structures, or subsets thereof, or extended sets thereof: operating system 30021 and application programs 30022.

[0382] The operating system 30021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 30022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in application program 30022.

[0383] In this embodiment of the invention, by calling the program or instructions stored in memory 3002, specifically the program or instructions stored in application program 30022, the transmitter is used to send a service request to the first IUSU; the processor is used to... If a failure response is received from the first IUSU, a second IUSU is selected based on the failure response, and a user registration request is initiated to the second IUSU. It is understood that the embodiments described in this invention can be implemented using hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of this application, or combinations thereof.

[0384] For software implementation, the techniques of the embodiments of the present invention can be implemented through modules (e.g., procedures, functions, etc.) that perform the functions of the embodiments of the present invention. The software code can be stored in memory and executed by processor 3001. The memory can be implemented in processor 3001 or external to processor 3001.

[0385] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0386] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0387] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0388] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0389] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

A service enabling method for an integrated user service unit (IUSU), the method comprising: receiving a service software download notification sent by a network and service capability storage function (NSCDF); downloading software data of a service corresponding to the service software download notification from the NSCDF; loading software corresponding to the software data and enabling the service corresponding to the software. The method of claim 1, wherein, The downloading of the software data of the service corresponding to the service software download notification from the NSCDF comprises: determining whether the IUSU meets service resource requirements included in the service software download notification; in a case where the IUSU meets the service resource requirements and is configured to support service autonomous enabling, reserving service resources corresponding to the service resource requirements; downloading the software data from the NSCDF. The method of claim 2, wherein, The downloading of the software data from the NSCDF comprises: sending a first service software data download request to the NSCDF, the first service software data download request including the service identifier; receiving the software data sent by the NSCDF in response to the first service software data download request. The method according to claim 3, further comprising: recording the service identifier corresponding to the service software data in a service list supported by the IUSU, to indicate that the IUSU supports the service corresponding to the service identifier. The method according to claim 4, further comprising: sending a service start success notification to the NSCDF, the service start success notification including the service identifier, the service start success notification being used to notify the NSCDF to record that the IUSU supports the service corresponding to the service identifier. The method of claim 1, wherein, The loading of the software corresponding to the software data and the enabling of the service corresponding to the software comprises: receiving a service use request of a user; running the software to provide corresponding services to the user, to enable the service corresponding to the software. A service enabling method for a NSCDF, the method comprising: sending a service software download notification to an IUSU, the service software download notification being used to notify the IUSU to download software data of a service corresponding to the service software download notification from the NSCDF. The method of claim 7, further comprising: Before the sending of the service software download notification to the IUSU, receiving a service publishing notification sent by a service management gateway (SMG); downloading the software data from the SMG according to the service publishing notification. The method of claim 8, wherein, The downloading of the software data from the SMG according to the service publishing notification comprises: determining whether the NSCDF meets storage space requirements of the software data included in the service publishing notification; when the NSCDF meets the storage space requirements, sending a second service software data download request to the SMG, the second service software data download request including a service identifier; receiving the software data sent by the SMG according to the second service software data download request and storing the software data. The method according to any one of claims 7-9, further comprising: receiving a first service software data download request sent by the IUSU; sending the software data to the IUSU according to a service identity included in the first service software data download request. The method of claim 10, further comprising: receiving a service start success notification sent by the IUSU; recording a service corresponding to the service identity included in the service start success notification supported by the IUSU. A service enabling method for an SMG, the method comprising: sending a service release notification to an NSCDF, the service release notification being used to notify the NSCDF to download software data of a service corresponding to the service release notification from the SMG. The method of claim 12, further comprising: receiving a second service software data download request sent by the NSCDF; sending the software data to the NSCDF according to a service identity carried by the second service software data download request. A service processing method for a first IUSU, the first IUSU being enabled for a service by the service enabling method of any one of claims 1-6, the method comprising: receiving a service request sent by a terminal; in a case where the service corresponding to the service request is not supported, returning a failure response to the terminal, the failure response being used to instruct the terminal to register to a second IUSU supporting the service. The method of claim 14, further comprising: determining whether the service is supported according to a service identity included in the service request and a service list supported by the first IUSU; determining that the service is not supported when the service identity is not in the service list. The method of claim 14, wherein, The returning of the failure response to the terminal comprises: generating the failure response according to a service capability query response sent by an NSCDF, the failure response including a service supporting IUSU list; sending the failure response to the terminal. The method of claim 16, further comprising: sending a service capability query request to the NSCDF; the service capability query request including a public IUSU list configured by the first IUSU; receiving the service capability query response sent by the NSCDF for the service capability query request; the service capability query response including the service supporting IUSU list. The method of claim 17, wherein, the service supporting IUSU list including identities of one or more second IUSUs supporting the service in the public IUSU list. A service processing method for an NSCDF, the method comprising: receiving a service capability query request sent by a first IUSU; returning a service capability query response to the first IUSU, the service capability query response including identities of one or more second IUSUs supporting a service corresponding to the service capability query request. A service processing method for a terminal, the method comprising: sending a service request to a first IUSU; when receiving a failure response returned by the first IUSU, selecting a second IUSU according to the failure response, and initiating a user registration request to the second IUSU. A service enabling apparatus for an IUSU, the apparatus comprising: The first receiving module is configured to receive a service software download notification sent by a network and service capability storage function (NSCDF); The downloading module is configured to download software data of a service corresponding to the service download notification from the NSCDF according to the service download notification; The starting module is configured to load and start software corresponding to the software data. A service enabling apparatus for an NSCDF, the apparatus comprising: The second sending module is configured to send a service software download notification to an IUSU, the service software download notification being used to notify the IUSU to download software data of a service corresponding to the service download notification from the NSCDF. A service enabling apparatus for an SMG, the apparatus comprising: The fourth sending module is configured to send a service release notification to an NSCDF, the service release notification being used to notify the NSCDF to download software data of a service corresponding to the service release notification from the SMG according to the service release notification. A service processing apparatus for a first IUSU, the apparatus comprising: The fourth receiving module is configured to receive a service request sent by a terminal; The sixth sending module is configured to return a failure response to the terminal in a case where the service corresponding to the service request is not supported, the failure response being used to instruct the terminal to register to a second IUSU supporting the service. A service processing apparatus for an NSCDF, the apparatus comprising: The sixth receiving module is configured to receive a service capability query request sent by a first IUSU, the service capability query request being sent by the first IUSU in a case where a service corresponding to a service request sent by a terminal is not supported; The eighth sending module is configured to return a service capability query response to the first IUSU, the service capability query response being used to indicate at least one second IUSU supporting the service. A service processing apparatus for a terminal, the apparatus comprising: The ninth sending module is configured to send a service request to a first IUSU; The tenth sending module is configured to initiate a user registration request to at least one second IUSU supporting a service corresponding to the service request and included in a failure response according to the failure response when the failure response returned by the first IUSU is received. A communication device comprising: A receiver and a processor; The receiver is configured to receive a service download notification sent by an NSCDF; The receiver is further configured to download software data of a service corresponding to the service download notification from the NSCDF according to the service download notification; The processor is configured to load and start software corresponding to the software data. A communication device comprising: A transmitter; The transmitter is configured to send a service software download notification to an IUSU, the service software download notification being used to notify the IUSU to download software data of a service corresponding to the service download notification from the NSCDF. A communication device comprising: A transmitter; The transmitter is configured to send a service release notification to an NSCDF, the service release notification being used to notify the NSCDF to download software data of a service corresponding to the service release notification from the SMG according to the service release notification. A communication device comprising: A receiver and a transmitter; The receiver is configured to receive a service request sent by a terminal. The transmitter is configured to return a failure response to the terminal in a case where the service corresponding to the service request is not supported, the failure response being used to instruct the terminal to register to a second IUSU supporting the service. A communication device comprising: The receiver and the transmitter; The receiver is configured to receive a service capability query request sent by a first IUSU, the service capability query request being sent by the first IUSU in a case where a service corresponding to a service request sent by a terminal is not supported; The transmitter is configured to return a service capability query response to the first IUSU, the service capability query response being used to indicate at least one second IUSU supporting the service. A communication device comprising: The transmitter; The transmitter is configured to send a service request to a first IUSU; The transmitter is further configured to initiate a user registration request to at least one second IUSU supporting a service corresponding to the service request and included in a failure response returned by the first IUSU, when the failure response is received. A computer readable storage medium having stored thereon a computer program, the computer program being executable by a processor to implement the steps of the method of any one of claims 1 to 20. A computer program product comprising a computer program, the computer program being executable by a processor to implement the steps of the method of any one of claims 1 to 20.

Images