Communication method, apparatus and system, and computer-readable storage medium and program product

Abstract

Provided in the embodiments of the present disclosure are a communication method, apparatus and system, and a computer readable storage medium and a computer program product. In the method, a first network element receives a first message, the first message comprising a first user context identifier; and the first network element further sends a first request to a second network element, the first request being used for acquiring a first user context, and the first request comprising the first user context identifier, a first credential, and the type of the first user context. The present application can reduce message interaction between the network elements and coupling between the network elements, and can realize a stateless design of the network elements, so that new services and new services can be quickly deployed and launched, thereby improving the flexibility and reliability of a network.

Description

Communication method, apparatus, system, computer-readable storage medium and program product

[0001] The present application claims priority from the Chinese Patent Application No. 202510256703.9 filed on February 28, 2025, and entitled "Communication method, apparatus, system, computer-readable storage medium and program product", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of communications, and more specifically to a communication method, apparatus, system, computer-readable storage medium and computer program product. BACKGROUND

[0003] In order to meet diversified network service requirements and improve network flexibility, the 5th-Generation Mobile Communication Technology (5G) adopts a service-based architecture (SBA), introduces a service-based architecture in the core network control plane, and abstracts multiple network services from the control plane through a unified service-based interface and control plane and user plane (CU) separation. For example, network functions of the service-based control plane are abstracted into independent network functions (NFs) (such as an access and mobility management function (AMF), a session management function (SMF), and the like), and the network functions can directly communicate based on a service-based interface. In order to improve the reliability of the network, the current 5G also defines an NF set mechanism, that is, there are multiple same-type NF instances in the NF set, an unstructured data storage function (UDSF) supports synchronization of context data between the multiple NF instances in the NF set, and a service communication proxy (SCP) can reselect an NF instance in the NF set when the current NF instance serving a user equipment (UE) is unavailable, and provide services for the UE by the NF instance. However, some structures currently exist, which cause large east-west traffic of signaling interaction between NFs, serious coupling between NFs, long signaling processes, and binding relationships between NFs (or NF instances), resulting in deficiencies in network flexibility and reliability. SUMMARY

[0004] The embodiments of this disclosure provide a communication method, apparatus, system, computer-readable storage medium, and computer program product that can reduce message interaction and coupling between network elements, realize stateless design of network elements, enable new services to be deployed and launched quickly, and improve the flexibility and reliability of the network.

[0005] Firstly, a communication method is provided. The execution subject of the method provided in the first aspect can be a first network element. Unless otherwise specified, the execution subject in this embodiment can refer to the first network element itself, a component within the first network element (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the first network element. The following example uses the first network element itself as the execution subject. In this method, the first network element receives a first message, which includes a first user context identifier. The first network element also sends a first request to a second network element. The first request is used to obtain the first user context and includes the first user context identifier, a first credential, and the type of the first user context. In this way, different first network element instances can process the first message by obtaining the first user context, realizing the stateless design of the first network element and thus improving network reliability; avoiding the binding relationship between users and first network element instances, and between first network element instances and other network element instances different from the first network element, thus improving network flexibility; based on the first user context identifier, it can be guaranteed that a unique first user context can be obtained, and based on the first credential, it can guarantee the data security and trusted exchange of the first user context.

[0006] In some implementations, the type of the first user context includes a data type, a network element type, a service type, or a combination thereof. The data type indicates at least one piece of data for the corresponding network element. The network element type indicates the data set for the corresponding network element. The service type indicates the data set for the corresponding service of the corresponding network element. In this way, the range of data to be acquired can be controlled based on the type of the user context to be obtained. The first network element can obtain the data or data set of the corresponding network element without interacting with it, eliminating east-west traffic in the network, reducing the coupling between the first network element and the corresponding network element, and thus improving network flexibility.

[0007] In some implementations, the first request comprises a data type, and the first user context comprises data corresponding to the data type. Alternatively or additionally, the first request comprises a network element type or a service type, and the first user context comprises a data set corresponding to the network element type or the service type. In this way, the range of data that can be acquired can be controlled according to the type of user context to be acquired, and the problem of excessive first user context data acquired from the second network element and excessive signaling consumption caused by acquiring all of the user's contexts each time can be avoided.

[0008] In some implementations, the first request further comprises first identification information, which is used to indicate whether the data of the corresponding network element supports being acquired by other network elements different from the corresponding network element. In this way, the first network element can control the range of data that can be acquired, and when the corresponding network element can flexibly modify the storage structure of the data that does not support being acquired by other network elements different from the corresponding network element through upgrading or the like, the first network element does not need to be upgraded synchronously to adapt to the acquisition of the part of data, the coupling degree of the first network element and the corresponding network element is reduced, and the first network element and the corresponding network element can evolve and upgrade independently, thereby improving the flexibility of the network.

[0009] In some implementations, in the process of acquiring the first user context, based on the data type indicating the data of the first network element and the first identification information indicating that the data does not support being acquired by network elements other than the first network element, the first network element acquires internal data of the first network element. Alternatively or additionally, based on the data type indicating the data of the first network element and the first identification information indicating that the data supports being acquired by network elements other than the first network element, the first network element acquires public data of the first network element. Alternatively or additionally, based on the data type indicating the data of a third network element different from the first network element and the first identification information indicating that the data supports being acquired by network elements other than the third network element, the first network element acquires public data of the third network element. In this way, the range of data that can be acquired can be controlled, and the problem of excessive signaling consumption can be avoided; the first network element supports acquiring internal data and public data of itself, and also supports acquiring public data of the third network element, which can eliminate east-west traffic in the network and reduce the coupling degree of the first network element and the third network element, thereby improving the flexibility of the network.

[0010] In some implementations, the first network element sends a second request to the second network element, the second request being used to store the second user context to the second network element, the second request including the second user context identifier, the second credential, and the second user context. In this way, the range of data that can be stored can be controlled, and data security can be ensured. Different instances of the first network element can subsequently obtain and process the second user context stored by the instance of the first network element, and the stateless design of the first network element can be implemented, thereby improving the reliability of the network. In addition, based on the second user context identifier, indexing to a unique second user context can be ensured, and based on the second credential, the security and trustworthiness of the data storage of the second user context can be ensured.

[0011] In some implementations, the second user context includes a type of the second user context, and data or a data set corresponding to the type of the second user context, where the type of the second user context includes a network element type, a service type, a data type, or a combination thereof. Alternatively, the second user context includes the type of the second user context, the data or the data set corresponding to the type of the second user context, and second identification information, where the second identification information indicates whether data of the first network element supports being obtained by a network element different from the first network element (hereinafter referred to as a third network element). In this way, the range of data that can be written can be controlled, and the problem of excessive second user context data carried in the second request and excessive signaling consumption caused by storing all contexts of a user each time can be avoided. For data that supports being obtained by the third network element, the openness of the data can be ensured, and for data that does not support being obtained by the third network element, the security of the data can be ensured, and the third network element can also be prevented from obtaining the internal implementation of the first network element by obtaining the data that does not support being obtained by the third network element, thereby ensuring the security of the first network element. The first network element can flexibly modify the storage structure of the data that does not support being obtained by the third network element through upgrading, and the third network element does not need to be upgraded synchronously to adapt to the obtaining of the data, thereby reducing the coupling degree of the first network element and the third network element, ensuring that the first network element and the third network element can evolve and upgrade independently, and thereby improving the flexibility of the network.

[0012] In some implementations, the first network element further receives a second response corresponding to the second request, the second response including a processing result of the second request. In this way, when the first network element receives a processing result of the second request that fails, the second request can be resent, or the failure information can be reported and other processing can be performed, thereby avoiding the loss of the second user context, and thereby improving the reliability of the network.

[0013] In some implementations, the first network element also receives a first response corresponding to the first request, the first response comprising the first user context. In this way, different instances of the first network element can process the first message with the first user context, achieving a stateless design of the first network element, thereby improving the reliability of the network. The first network element can obtain data of the third network element from the second network element, eliminating east-west traffic in the network, reducing the coupling degree between the first network element and the third network element, thereby improving the flexibility of the network.

[0014] In some implementations, the first network element is a service orchestrator, and the first network element further determines a process to be orchestrated based on at least one of the first user context or the first message, the process comprising interaction with one or more network elements different from the service orchestrator. In this way, the process can be flexibly orchestrated according to service requirements, and different network elements can be selected for interaction in the process, thereby improving the flexibility of the network.

[0015] In some implementations, during the interaction, the first network element sends a third request, the third request comprising information of the first network element, information of the process, and a first user context identifier. During the interaction, the first network element also receives a third response corresponding to the third request, the third response comprising information of the first network element, information of the process, and a processing result of the third request. In this way, the first network element can interact with one or more network elements different from the first network element through the same message structure of the third request and the third response based on the orchestrated process, reducing the coupling degree between the first network element and the one or more network elements different from the first network element; avoiding interaction between multiple network elements different from the first network element, reducing the coupling degree between the multiple network elements different from the first network element, and improving the flexibility of the network.

[0016] In some implementations, the first network element is a network function, and the first message is a fourth request, the fourth request comprising information of a service orchestrator, information of a process, and a first user context identifier, the first network element can process the fourth request, and send a fourth response corresponding to the fourth request, the fourth response comprising information of the service orchestrator, information of the process, and a processing result of the fourth request. In this way, different instances of the first network element can receive the fourth request, and can obtain the first user context by sending the first request to the second network element, and can process the fourth request based on the obtained first user context, thereby achieving a stateless design of the first network element, avoiding a binding relationship between the user and the first network element instance, between the service orchestrator and the first network element instance, improving the flexibility and reliability of the network.

[0017] In some implementations, the first network element is a service orchestrator or a network function, and the second network element is a data management function. In this way, the service orchestrator or the network function can obtain or store data from the data management function, solve the problem of large east-west traffic between the service orchestrator and the network function or between different network functions, and reduce the coupling degree between the service orchestrator and the network function or between different network functions.

[0018] In a second aspect, a communication method is provided. The execution subject of the method provided in the second aspect can be the second network element. In the absence of special description, the execution subject in the embodiments of the present disclosure can refer to the second network element itself, a component (for example, a processor, a chip, or a chip system, etc.) in the second network element, or a logic module or software that can realize all or part of the function of the second network element. Hereinafter, the case where the execution subject is the second network element itself is taken as an example. In the method, the second network element receives a first request from a first network element, the first request being used to obtain a first user context, and the first request including a first user context identifier, a first credential, and a type of the first user context. In this way, the first user context can be provided to different instances of the first network element, which helps to realize the stateless design of the first network element, thereby improving the reliability of the network; the binding relationship between the user and the instance of the first network element and between the instance of the first network element and other network element instances different from the first network element is avoided, thereby improving the flexibility of the network; and the unique first user context can be guaranteed to be obtained based on the first user context identifier, and the data security and trusted exchange of the first user context can be guaranteed based on the first credential.

[0019] In some implementations, the type of the first user context includes a data type, a network element type, a service type, or a combination thereof. The data type indicates at least one piece of data of the corresponding network element. The network element type indicates a data set of the corresponding network element. The service type indicates a data set of a corresponding service of the corresponding network element. In this way, the second network element can control the data range obtained by the first network element according to the type of the user context to be obtained by the first network element, which helps the first network element to obtain the data or the data set of the corresponding network element without interacting with the corresponding network element, eliminates the east-west traffic in the network, and helps to reduce the coupling degree of the first network element and the corresponding network element, thereby improving the flexibility of the network.

[0020] In some implementations, the first request includes the data type, and the first user context includes the data corresponding to the data type; alternatively or additionally, the first request includes the network element type or the service type, and the first user context includes the data set corresponding to the network element type or the service type. In this way, the data range that can be obtained can be controlled according to the type of the user context to be obtained, which can avoid the problem of returning too much first user context data by the second network element and consuming too much signaling caused by obtaining all contexts of the user each time.

[0021] In some implementations, the first request further includes first identification information, the first identification information being used to indicate whether the data of the corresponding network element is supported to be acquired by other network elements different from the corresponding network element. In this way, the second network element can control the range of the data acquired by the first network element, and ensure the security of the internal data of the corresponding network element.

[0022] In some implementations, the data type indicates the data of the first network element, and the first identification information indicates that the data is not supported to be acquired by the network elements other than the first network element, the first user context includes the internal data of the first network element; alternatively or additionally, the data type indicates the data of the first network element, and the first identification information indicates that the data is supported to be acquired by the network elements other than the first network element, the first user context includes the public data of the first network element; alternatively or additionally, the data type indicates the data of a third network element different from the first network element, and the first identification information indicates that the data is supported to be acquired by the network elements other than the third network element, the first user context includes the public data of the third network element. In this way, the range of the data that can be acquired can be controlled, and the problem of excessive signaling consumption can be avoided; the second network element can support the first network element to acquire the internal data and the public data of the first network element, and also support the first network element to acquire the public data of the third network element, so that the east-west traffic in the network is eliminated, the coupling degree of the first network element and the third network element is reduced, and the flexibility of the network is improved.

[0023] In some implementations, the second network element further determines that the first request is legal based on the first credential of the first network element. In this way, the network element that is not authorized or authenticated can be prevented from acquiring the first user context, and the data security and trusted exchange of the first user context can be ensured.

[0024] In some implementations, in the process of determining that the first request is legal, the second network element can determine the acquisition authority of the first network element based on the first credential, and determine that the acquisition authority supports the first user context indicated by the type indication of the first user context. Alternatively or additionally, the second network element can determine the acquisition authority of the first network element based on the first credentials, and determine that the acquisition authority supports the first user context indicated by the type and the first identification information of the first user context. In this way, the network element that does not conform to the acquisition authority can be prevented from acquiring the data, the data security and trusted exchange of the first user context can be ensured, and the network element that does not conform to the acquisition authority can also be prevented from acquiring the internal implementation of the first network element by acquiring the internal data of the first network element.

[0025] In some implementations, the second network element also receives a second request. This second request stores the second user context within the second network element and includes a second user context identifier, a second credential, and the second user context itself. This method controls the scope of storable data and ensures data security. Subsequently, the second network element can provide the second user context stored in the first network element instance to different first network element instances, achieving a stateless design for the first network element and thus improving network reliability. Furthermore, the second user context identifier ensures that indexing leads to a unique second user context, and the second credential ensures the security and trustworthiness of the second user context data storage.

[0026] In some implementations, the second user context includes a type of the second user context and data or a data set corresponding to that type. The type of the second user context includes a network element type, service type, data type, or a combination thereof. Alternatively, the second user context includes a type of the second user context, data or a data set corresponding to that type, and second identification information. This second identification information indicates whether the data of the first network element supports being accessed by a third network element different from the first network element. In this way, the second network element can determine the range of data to be written, avoiding excessive storage performance consumption caused by storing all user contexts each time. It also supports controlling the range of data accessed by the first network element based on the second identification, ensuring the security of the first network element's internal data and preventing third network elements from accessing the first network element's internal implementation by obtaining its internal data, thus ensuring the security of the first network element.

[0027] In some implementations, the second network element also verifies the legitimacy of the second request based on the second credential. This prevents unauthorized or unauthenticated network elements from storing the second user context, thereby avoiding tampering with user data and ensuring the security and trustworthiness of the second user context data storage.

[0028] In some implementations, when determining the legitimacy of a second request, the second network element can determine the storage permissions of the first network element based on the second credential, and determine whether the storage permissions support storing data indicating the type of the second user context. Alternatively or additionally, when determining the legitimacy of a second request, the second network element can determine the storage permissions of the first network element based on the second credential, and determine whether the storage permissions support storing data indicating the type of the second user context and the second identification information. This approach avoids network elements that do not meet the storage permissions from storing the second user context, ensuring the security and reliability of the data storage of the second user context.

[0029] In some implementations, the second network element also sends a second response corresponding to the second request, the second response including a processing result of the second request. In this way, the first network element can be timely informed of the failure of the second network element in processing the second request, facilitating the first network element to process in a timely manner and avoiding loss of the second user context, thereby improving reliability of the network.

[0030] In some implementations, the second network element also sends a first response corresponding to the first request, the first response including the first user context. In this way, the second network element can provide the first user context to different instances of the first network element, realizing stateless design of the first network element; and the second network element can provide data of the third network element to the first network element, eliminating east-west traffic in the network and reducing coupling between the first network element and the third network element, thereby improving flexibility of the network.

[0031] It should be noted that some implementations of the second aspect method regarding the type of the first user context, the first request, or the second user context have been described in the first aspect method, and will not be repeated here.

[0032] In a third aspect, a communication apparatus is provided, which has functions to implement behaviors in the method implementations of the first aspect or the second aspect. The functions can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The above description of the first network element of the first aspect or the second network element of the second aspect also applies to the communication apparatus of the fourth aspect, i.e., the communication apparatus of the fourth aspect can refer to the communication apparatus itself, or a component (e.g., a processor, a chip, or a chip system, etc.) in the communication apparatus, or a logic module or software capable of implementing all or part of the functions of the communication apparatus. In one possible design, the communication apparatus includes units for executing the method of the first aspect or the second aspect or their implementation manners. The communication apparatus provided by the third aspect has the advantages of the first aspect or the second aspect, which will not be repeated here.

[0033] In a fourth aspect, a device is provided. The device includes a processor and a memory storing computer programs or instructions. The computer programs or instructions, when executed by the processor, cause the device to perform any method according to the first aspect or the second aspect and their implementation manners.

[0034] In a fifth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer programs or instructions, which, when executed by an electronic device, cause the electronic device to perform the method performed by the device in the above aspects.

[0035] In a sixth aspect, a computer program or a computer program product is provided. The computer program or computer program product includes computer instructions that, when executed by an electronic device, cause the electronic device to perform the method performed by the apparatus in the above aspects.

[0036] In a seventh aspect, embodiments of the present disclosure provide a chip system including a processor for implementing the functions of the apparatus in the method of the above aspects. In a possible design, the chip system further includes a memory for storing computer programs or instructions and / or data. The chip system can be composed of a chip, or include a chip and other discrete devices.

[0037] In an eighth aspect, embodiments of the present disclosure further provide a communication system. The communication system includes a first network element for performing the first aspect, or a second network element for performing the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0038] FIG. 1A shows a schematic diagram of a communication system according to some embodiments of the present disclosure.

[0039] FIG. 1B shows a schematic diagram of a system architecture according to some embodiments of the present disclosure.

[0040] FIG. 1C shows a schematic diagram of a network architecture according to some embodiments of the present disclosure.

[0041] FIG. 2A shows a schematic diagram of a communication process according to some embodiments of the present disclosure.

[0042] FIG. 2B shows a schematic diagram of a communication process according to some other embodiments of the present disclosure.

[0043] FIG. 2C shows a schematic diagram of a communication process according to some other embodiments of the present disclosure.

[0044] FIG. 3 and FIG. 4 show schematic diagrams of a communication process according to some embodiments of the present disclosure.

[0045] FIG. 5 to FIG. 7 show example communication processes according to some embodiments of the present disclosure.

[0046] FIG. 8 shows a schematic process block diagram implemented at a first network element according to some embodiments of the present disclosure.

[0047] FIG. 9 shows a schematic process block diagram implemented at a second network element according to some embodiments of the present disclosure.

[0048] FIG. 10 is a block diagram of an apparatus that can be used to implement some embodiments according to the present disclosure.

[0049] FIG. 11 is a schematic diagram of a structure of an apparatus according to some embodiments of the present disclosure.

[0050] FIG. 12 is a schematic diagram of a structure of an apparatus according to some other embodiments of the present disclosure. Detailed Implementation

[0051] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that embodiments of this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0052] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0053] The embodiments disclosed herein can be implemented according to any suitable communication protocol, including but not limited to third-generation (3G), fourth-generation (4G), fifth-generation (5G), and future communication protocols (e.g., future cellular communication protocols, wireless LAN communication protocols such as IEEE 802.11, and / or any other protocols currently known or to be developed in the future). The technical solutions provided in this application can also be applied to device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine (M2M) communication, machine-type communication (MTC), and Internet of Things (IoT) communication systems or other communication systems.

[0054] The current system architecture of some communication system solutions has led to several problems. For example, some solutions result in large east-west traffic between network elements. Specifically, when different network elements exchange information via messages, if a new function is added within the process that requires new information elements or information element values, all related messages of the network element providing the information element and all network elements receiving and using the information element need to be modified (e.g., adding a Data Network Access Identifier (DNAI) information element involves network elements and corresponding messages for access and mobility management functions (AMF), session management functions (SMF), user plane functions (UPF), intermediate session management functions (I-SMF), and policy control functions (PCF), resulting in a large workload for message adaptation). Furthermore, with the increase in new functions, single messages also face the problem of having too many information elements, making maintenance difficult (e.g., the Nsmf_PDUSession_CreateSmContext message contains more than 110 information elements), as well as the issue of large east-west traffic. Furthermore, some solutions result in long signaling processes in certain 5G procedures, leading to high coupling between network elements. For example, the registration process involves the cooperation of multiple network elements such as the UE, radio access network (RAN), AMF, PCF, Unified data management (UDM), Authentication Server function (AUSF), and SMF. In the same registration process, AMF, SMF, and AAUSF are both recipients of certain request messages and initiators of other service request messages, requiring other network elements to complete a function. Therefore, these network elements need to maintain user state between the recipient and the initiator. Such long signaling and serial process design leads to severe coupling between network elements. Adding new functions / interactions within the process often requires multi-network element coordinated upgrades, which has a wide impact on the network, is time-consuming, and makes the deployment of new services difficult.Furthermore, some solutions lead to binding relationships between network elements, resulting in poor network flexibility and reliability. Specifically, for example, after a UE accesses the network, fixed AMF / SMF and other network elements store the UE's status, policies, and other information. Therefore, each request requires finding the AMF / SMF or other network element serving the UE to complete the process. In other words, the network elements serving the UE (such as AMF and SMF) mutually store information about other network elements serving the UE, or it can be understood that there are binding relationships between the network elements serving the UE. In operational scenarios such as mobility procedures, network element upgrades and decommissioning, or capacity scaling, if the network element serving the UE is changed, the binding relationships of other network elements serving the UE need to be modified synchronously, leading to increased interactions, a wider impact, poor network flexibility, and significant reliability challenges.

[0055] Based on the foregoing analysis, some embodiments of this disclosure provide a communication method, apparatus, computer-readable storage medium, and computer program product. In this communication method, a first network element receives a first message, which includes a first user context identifier. Additionally, the first network element sends a first request to a second network element to obtain the first user context. The first request includes the first user context identifier, a first credential, and the type of the first user context. Correspondingly, the second network element receives the first request from the first network element. In this manner, embodiments of this disclosure can solve the problems of coupling between atomic services, process serialization, binding between atomic services, and east-west traffic between atomic services present in the above-mentioned solutions, thereby supporting the rapid deployment and launch of new services and improving network flexibility and reliability.

[0056] Figure 1A illustrates a schematic diagram of a communication system according to some embodiments of the present disclosure. As shown in Figure 1A, in the communication system 100 of the embodiments of the present disclosure, a first network element 110, a second network element 120, a network device 140, and a terminal device 150 are shown. The first network element 110 and the second network element 120 may be located in the core network 130. The network device 140 can provide a geographical coverage area 160. The terminal device 150 is located within the geographical coverage area 160 of the network device 140 and can communicate with the network device 140. In some examples, the terminal device 150 may be a user equipment (UE). In some examples, the second network element 120 may store data from the first network element 110 or other network elements, and the first network element 110 may retrieve stored data from the second network element 120 or store data in the second network element 120. In some examples, the first network element 110 may interact indirectly with the terminal device 150 via other network elements. In some embodiments, the communication system 100 may be a communication system based on a distributed network scenario, such as a communication system for a future distributed network scenario. In some examples, the communication system 100 may also include other network elements, network devices, and / or terminal devices not shown. In other words, the network elements, network devices, and terminal devices in FIG1A are only examples for illustration, and the communication system 100 may include any number of network elements, terminal devices, or network devices.

[0057] The communication system 100 in this disclosure includes, but is not limited to: narrowband Internet of Things (NB-IoT), global system for mobile communications (GSM), enhanced data rate for GSM evolution (EDGE), wideband code division multiple access (WCDMA), code division multiple access 2000 (CDMA2000), time division-synchronization code division multiple access (TD-SCDMA), long term evolution (LTE), long term evolution advanced (LTE-A), 5th generation (5G) mobile communication system, and the three major application scenarios in 5G mobile communication system (enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and enhanced machine-type communication). Communication (eMTC), and future mobile communication systems, etc.

[0058] The solutions disclosed in this embodiment are applicable to LTE systems, Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication systems, fifth-generation communication systems, and future communication systems. Of course, the solutions disclosed in this embodiment can also be applied to other possible communication systems, such as Internet of Things (IoT) networks, wireless local area network systems supporting the 802.11 series protocols, wireless personal area network systems based on Ultra-Wideband (UWB), sensing systems, vehicle-to-X (V2X), machine-type communication (MTC), long-term evolution-machine (LTE-M), machine-to-machine (M2M), vehicle-to-vehicle (V2V), long-term evolution-vehicle (LTE-V), and satellite communication systems. The communication systems applicable to the embodiments of this disclosure described above are merely illustrative examples; the communication systems applicable to the embodiments of this disclosure are not limited to these examples. They are uniformly described here and will not be repeated below.

[0059] A terminal device is a device with wireless transceiver capabilities. It can communicate with one or more core network (CN) devices (or core equipment) via access network devices (or access equipment) in a radio access network (RAN). Terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water (such as on ships); and they can be deployed in the air (e.g., on airplanes, balloons, and satellites). In this disclosure, the terminal device may also be referred to as user equipment (UE), which may be a mobile phone, mobile station (MS), tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal device in industrial control, wireless terminal device in self-driving, wireless terminal device in remote medical, wireless terminal device in smart grid, wireless terminal device in transportation safety, wireless terminal device in smart city, wireless terminal device in smart home, subscriber unit, cellular phone, wireless data card, personal digital assistant (PDA) computer, tablet computer, laptop computer, machine type communication (MTC) terminal device, drone, etc. Terminal devices may include various handheld devices, in-vehicle devices, wearable devices, computing devices, or other processing devices connected to a wireless modem with wireless communication capabilities. Optionally, terminal devices may be handheld devices with wireless communication capabilities, terminal devices in the Internet of Things or the Internet of Vehicles, or any form of terminal device in 5G and subsequent communication systems; this disclosure does not limit this. In this disclosure, the means for implementing the functions of the terminal device may be the terminal device itself, or it may be a means that enables the terminal device to implement the functions, such as a chip system or a chip, which may be installed in the terminal device. In this application, the chip system may consist of chips or may include chips and other discrete components.

[0060] Access network equipment can be any device with wireless transceiver capabilities that can communicate with terminal devices, such as a radio access network (RAN) node that connects terminal devices to a wireless network. Examples of RAN nodes currently include: macro base stations, micro base stations (also known as small cells), relay stations, access points, gNBs, transmission reception points (TRPs), evolved Node Bs (eNBs), radio network controllers (RNCs), home base stations (e.g., home evolved Node Bs, or home Node Bs, HNBs), baseband units (BBUs), WiFi access points (APs), integrated access and backhaul (IABs), satellites, and drones.

[0061] Furthermore, network devices such as access network equipment can connect to core network (CN) equipment, which can be used to provide core network services to access network equipment and terminal equipment. Core network equipment can correspond to different devices in different systems. For example, in 3G, core network equipment can correspond to the Serving GPRS Support Node (SGSN) and / or the Gateway GPRS Support Node (GGSN) of the General Packet Radio System (GPRS). In 4G, core network equipment can correspond to the Mobility Management Entity (MME) and / or the Serving Gateway (S-GW) and / or the Public Data Network Gateway (P-GW). In 5G, core network equipment can correspond to the Access and Mobility Management Function (AMF), the Session Management Function (SMF), and / or the User Plane Function (UPF), etc.

[0062] In this embodiment of the disclosure, the means for implementing the functions of the network device can be the network device itself, or it can be a means that enables the network device to implement the functions, such as a chip system or a chip, which can be installed in the network device. In this embodiment of the application, the chip system can be composed of chips, or it can include chips and other discrete devices.

[0063] Figure 1B illustrates a schematic diagram of the system architecture of an embodiment of this disclosure. The system architecture of this embodiment can be applied to future distributed network scenarios, where multiple service orchestrators with identical (or similar) capabilities and multiple atomic services (such as network functions (NFs) exist across the entire network / domain. This enables stateless design of service orchestrators (e.g., task control functions (TCFs)) and atomic services, allowing different processes / tasks of the same user to select different instances of the same type of service orchestrator and atomic service for service provision. Specifically, as shown in Figure 1B, system architecture 102 includes a data plane 112, TCF 111, atomic functions 113, signaling distribution function (SDF) 114, UPF 117, DN 118, and RAN 116. UE 115 accesses the network via RAN 116. In some example implementations, TCF 111 can serve as an example of the first network element 110. In other example implementations, atomic functions (such as NFs) 113 can serve as another example of the first network element 110.

[0064] The data plane 112 can support context data for managing network services, including data storage functions, which can be understood as a data management function (DMF), a database (DB) for storing user context, or an unstructured data storage function (UDSF). In some cases, the data plane also supports storing user subscription and policy data, thus the data plane can also be understood as a unified data repository (UDR). The following embodiments use "data plane UDR" to refer to this situation to distinguish it from DB, DMF, or UDSF. DB, DMF, UDSF, or UDR can be used as examples of the second network element 120. Devices in RAN 116 include, for example, the network device 140 shown in Figure 1A, specifically a base station, etc.

[0065] In some examples, a network function (NF) can also be understood as a network element, network service, atomic service, microservice, etc., or simply a network element. Depending on the service type, an NF can be a mobility management function (MM), access management function (AM), session management function (SM), unified data management (UDM), policy control function (PCF), or authentication server function (AUSF), etc. Logical functions in 4G, 5G, and future network systems can all be understood as NFs without limitation.

[0066] In some examples, TCF 111 can be understood as a service orchestrator, or a network element with service orchestration capabilities, supporting dynamic orchestration and scheduling of atomic services based on service requests to complete tasks. In some examples, a task can include a process, a call, an interaction, etc. For example, the registration process defined by 3GPP can be understood as a task (such as a main task), and the AMF or TCF 111 in this embodiment of the disclosure calling the AUSF to perform UE 115 authentication (or, the AMF or TCF requesting UE authentication from the AUSF) in the registration process can also be understood as a task (such as a subtask).

[0067] SDF 114 stands for Signaling Distribution Function Network Element. SDF can be understood as SCP (Service Communication Proxy) or a network element containing SCP functionality, or as LLOF (Link Layer Orchestration Function) or a network element containing LLOF functionality. Specifically, the functions or operations it performs may include: based on the notification information from TCF 111, storing the correspondence between user temporary identifiers (e.g., globally unique temporary identifiers (GUTI)) and context identifiers (e.g., subscription permanent identifiers (SUPI), International Mobile Subscriber Identity (IMSI), subscription concealed identifiers (SUCI)); upon receiving a service request from UE 115 / RAN 116 carrying the user temporary identifier, adding the corresponding context identifier to the message and forwarding it to TCF 111; based on the domain information in the service request from UE 115 / RAN 116, selecting a TCF instance that supports the domain and forwarding the request. Examples of domain information may include Public Land Mobility Network (PLMN), network identity (NID), or domain ID, data network name (DNN), and single network slice selection assistance. Information, S-NSSAI, etc.; based on atomic service information (such as NF group information, NF set information) in the task request of TCF 111, select NF instances within the group and forward the request; etc.

[0068] Figure 1C illustrates a network architecture diagram according to an embodiment of the present disclosure. As shown in Figure 1C, the data plane of the data-driven network architecture 104 stores data corresponding to each service (e.g., services 1, 2, and 3 as shown in boxes 127, 128, and 129, respectively). The stored data may include open data (or public data) and internal data of the corresponding service. For example, the data for service 1 includes the open data and internal data of service 1 shown in boxes 121 and 124; the data for service 2 includes the open data and internal data of service 2 shown in boxes 122 and 125; and the data for service 3 includes the open data and internal data of service 3 shown in boxes 123 and 126. Atomic services (e.g., services 1, 2, and 3) can exchange information (e.g., data, information cells, etc.) through the data plane, thereby eliminating the problem of large east-west traffic between atomic services. The business orchestrator and atomic services can also exchange data through the data plane, which can reduce the need for data to be exchanged through messages. That is, when adding new features, if the data to be exchanged is to be added, it can be done without adding information elements to the message. This ensures that the message definition for the interaction between the business orchestrator and atomic services is simple and stable.

[0069] In some examples, the data stored in the data plane can be referred to as user context data. User context data is associated with user context identifiers to ensure uniqueness. User context data includes user context data submitted by each NF / TCF (example of the first network element 110) serving the user, including internal data and open / public data, as shown in boxes 121 to 126. Internal data for a service includes data that can only be read and written by services of that type. Open / public data includes open data that can be read and written by services of that type, but is only readable by other types of services. The read / write scope of user context data can be defined by the type and identifier information of the user context to be acquired or stored, where the identifier information indicates, for example, whether the data of the first network element supports acquisition by a third network element different from the first network element. In some examples, the type of the user context to be acquired is, for example, the type of a first user context, and the aforementioned identifier information can be first identifier information. The type of the user context to be stored is, for example, the type of a second user context, and the aforementioned identifier information can be second identifier information. In some examples, the type of the user context to be acquired or stored is, for example, data type, network element type, or service type, as described in the embodiments below. In some examples, a network element can have multiple services, meaning there is a one-to-many relationship between network element type and service type. When retrieving data, by including the network element type in the request, a collection of data from multiple services within the network element corresponding to that network element type can be obtained. Similarly, a network element can have multiple data items, and there can also be a one-to-many relationship between network element type and data type. When retrieving data, by including the network element type in the request, a collection of multiple data items from the network element corresponding to that network element type can be obtained. Likewise, a service can have multiple data items, and there can also be a one-to-many relationship between service type and data type. When retrieving data, by including the service type in the request, a collection of multiple data items from the service corresponding to that service type can be obtained. The legality / permission for reading and writing user context data can be controlled by credentials for this type of service. Credentials should be configured on the corresponding service when it is deployed / launched. Alternatively, the corresponding service can obtain credentials from a network element or network device with authentication or authorization functions through authentication or authorization methods. This invention does not limit the way a service obtains credentials. Based on the network architecture of this disclosure embodiment, addressing to the user context based on the user context identifier (i.e., containing / corresponding to the user's permanent identifier and domain information) can be supported. For example, in some implementations, when a user has multiple tasks running, the user context data can be identified by incrementing the task ID. Exemplarily, user context data can be understood as UE Context Data, and an example of its structure is shown below.

[0070] Figure 2A illustrates a communication process diagram of some embodiments of the present disclosure. As shown in Figure 2A, the communication process 200 involves a first network element 110 and a second network element 120. In some examples, the first network element 110 involved in the communication process 200 can be replaced by a chip, module, or assembly within the first network element 110. The second network element 120 can be replaced by a chip, module, or assembly within the second network element 120. In some examples, the first network element 110 can be an instance of a service orchestrator, such as a task control function (TCF). In other examples, the first network element 110 can be an instance of a network function (NF) or other network elements such as a session management function (SM) or mobility management function (MM). The embodiments of the present disclosure are mainly described using NF as an example. The second network element can be a data management function, such as a database (DB), a UDSF, and a UDR. The following description mainly uses a database (DB) as an example.

[0071] In communication process 200, the first network element 110 receives (202) a first message, which includes a first user context identifier. The first message may be sent by a fourth network element. In some examples, the fourth network element may be a Signaling Distribution Function (SDF). For example, in some examples, after receiving the first message from the UE / RAN, the SDF forwards the first message to the corresponding TCF instance, which is an example of the first message, as shown in step 303 of communication process 300 below. In some examples, after receiving a request or response message from another TCF instance, the SDF forwards the message to the corresponding TCF instance. In some examples, the SDF sends a task request to an NF instance, which is another example of the first message, as shown in step 409 of communication process 400 below. In some examples, the first message may also be sent by the UE, RAN, another TCF instance, or an NF instance.

[0072] First network element 110 sends (204) first request 205 to second network element 120. First request 205 is used to obtain a first user context, including a first user context identifier, a first credential, and the type of the first user context. Correspondingly, second network element 120 receives first request 205 from first network element 110. In some examples, obtaining the first user context can also be specifically implemented as reading, fetching, retrieving, or getting the first user context. In other words, in some examples, "get" can be used interchangeably with "fetch," "retrieve," and "get." In some examples below, the first request 205 can be a data read request.

[0073] In an example where the first network element 110 is a TCF instance and the second network element 120 is a DB, the first request 205 could be a data read request sent from the TCF instance to the DB, as detailed in step 305 of communication process 300. In an example where the first network element 110 is an NF instance and the second network element 120 is a DB, the first request 205 could be a data read request sent from the NF instance to the DB, as detailed in step 411 of communication process 400. In some examples, the first credential could be a service credential of the first network element 110. In some examples, the user context identifier carried in the data read request could be called the first user context identifier. The data type, service type, or network element type to be read carried in the data read request could be called the type of the first user context.

[0074] In some examples, after receiving the first request 205, the second network element 120 can determine the legitimacy of the first request 205 based on the first credential of the first network element 110. Specifically, in determining the legitimacy of the first request 205, for example, the second network element 120 can determine the access permission of the first network element 110 based on the first credential, and determine that the access permission supports the first user context indicated by the type of access permission.

[0075] In some examples, the type of the first user context includes one or more of the following: data type, network element type, or service type. A data type may indicate at least one piece of data for the corresponding network element. A network element type may indicate the data set for the corresponding network element. A service type may indicate the data set for the corresponding service of the corresponding network element.

[0076] In some examples, during the acquisition of the first user context, based on the first request including a data type, the first network element 110 acquires data corresponding to the data type. In other examples, based on the first request including a network element type or service type, the first network element 110 acquires a data set corresponding to the network element type or service type. In other words, when the first request includes a data type, the first user context includes data corresponding to the data type. When the first request includes a network element type or service type, the first user context includes a data set corresponding to the network element type or service type.

[0077] In some examples, the first request 205 also includes first identification information, which indicates whether the data of the corresponding network element supports being obtained by other network elements different from the corresponding network element. In such an example, in the process of determining the legitimacy of the first request 205, specifically, for example, the second network element 120 can determine the access permission of the first network element 110 based on the first credential, and determine that the access permission supports the type of access to the first user context and the first user context indicated by the first identification information.

[0078] In some examples, when the first network element 110 acquires the first user context, if the data type indicates that the data of the first network element 110 is not supported for acquisition by network elements other than the first network element 110, then the first network element 110 acquires its internal data. In such examples, the first user context includes the internal data of the first network element 110. In some examples, when the first network element 110 acquires the first user context, if the data type indicates that the data of the first network element 110 is supported for acquisition by network elements other than the first network element 110, then the first network element 110 acquires its public data. In such examples, the first user context includes the public data of the first network element 110. In some examples, when the first network element 110 acquires the first user context, if the data type indicates that the data of a third network element is different from the first network element 110, and the first identification information indicates that the data is supported for acquisition by network elements other than the third network element (i.e., network elements different from the first network element 110), then the first network element 110 acquires the public data of the third network element. In such examples, the first user context includes the public data of the third network element.

[0079] Based on the first request 205 for obtaining the first user context, the second network element 120 sends a first response to the first network element 110, the first response including the first user context. Accordingly, the first network element 110 receives the first response corresponding to the first request 205, thereby receiving the first user context.

[0080] In some examples, the first network element 110 can also send a second request to the second network element 120. This second request stores the second user context in the second network element 120. The second request includes a second user context identifier, a second credential, and the second user context. Accordingly, the second network element 120 receives the second request. In some examples, storing the second user context in the second network element 120 can be specifically implemented as writing, storing, submitting, or updating the second user context to the second network element 120. In other words, in some examples, "store" can be used interchangeably with "write," "submit," and "update." In some examples below, the second request can be a data submission request.

[0081] In an example where the first network element 110 is a TCF instance and the second network element 120 is a DB, the second request could be a data submission request sent by the TCF instance to the DB, as detailed in step 313 of communication process 300. In an example where the first network element 110 is an NF instance and the second network element 120 is a DB, the second request could be a data submission request sent by the NF instance (e.g., NF-A in the example below) to the DB, as detailed in step 415 of communication process 400. In some examples, the second user context may include a type of second user context, which may include one or more types of network element type, service type, and data type. The second user context may also include data or a data set corresponding to the type of the second user context. In some examples, the user context identifier, service credential, and user context carried in the data submission request are respectively referred to as the second user context identifier, the second credential, and the second user context.

[0082] In some examples, after receiving the second request, the second network element 120 can determine the legitimacy of the second request based on the second credential. Specifically, in determining the legitimacy of the second request, the second network element 120 can determine the storage permissions of the first network element based on the second credential, and determine that the storage permissions support storing data indicating the type of the second user context.

[0083] In some examples, the second user context may also include second identification information. The second identification information indicates whether the data of the first network element 110 is accessible to a third network element different from the first network element 110. In such an example, during the process of determining the legitimacy of the second request, specifically, the second network element 120 may determine the storage permissions of the first network element based on the second credential, and determine that the storage permissions support storing the type of the second user context and the data indicated by the second identification information.

[0084] In some examples, the second network element 120 can send a second response corresponding to the second request to the first network element 110. The second response includes the processing result of the second request; for example, the second response may include an identifier indicating whether the second request was successful. Accordingly, the first network element 110 can receive the second response corresponding to the second request, thereby allowing the first network element 110 to determine whether the first request was successful, for example, whether the second user context was successfully stored in the second network element 120.

[0085] In some examples, the first network element 110 is a service orchestrator, such as a TCF, and correspondingly, the first network element 110 is an instance of a TCF. In such examples, the first network element 110 can determine the process to be orchestrated based on a first user context or a first message, or both. This process includes interactions between the first network element 110 and one or more network elements other than the service orchestrator. In some examples, orchestration may include: determining the network elements involved in the process, determining the functions of the network elements called in the process (e.g., atomic functions), and determining the order in which atomic functions are called in the process. In some examples, the process may be called a task, such as the main task in the examples shown in Figures 3 and 4, and the interaction may be a subtask in the examples shown in Figures 3 and 4. Determining the process to be orchestrated may include creating a main task. In some examples, this interaction may specifically include the first network element 110 sending a third request and receiving a third response corresponding to the third request. The third request includes information about the first network element, information about the process, and a first user context identifier. The third response includes information about the first network element, information about the process, and the processing result of the third request. In some examples below, the third request can be a task request, such as the task request sent by TCF 310 to SDF 320 at step 405 of communication process 400. Accordingly, the third response can be a response to the task request, such as the task information and task result sent by SDF 320 to TCF 310 at step 419 of communication process 400, which can be examples of a third response.

[0086] In some examples, the first network element 110 is of type Network Function, such as NF, and correspondingly, the first network element 110 is an instance of NF. In such an example, the aforementioned first message can be a fourth request, which includes information about the service orchestrator, process information, and a first user context identifier. The first network element 110 processes the fourth request and sends a fourth response corresponding to the fourth request. The fourth response may include information about the service orchestrator, process information, and the processing result of the fourth request. The fourth request may be sent from a fourth network element (e.g., SDF) to the first network element 110.

[0087] Referring to Figures 1B and 2, in the example above, TCF or NF can be used as an example of the first network element 110. TCF, or Task Control Function Network Element, performs functions or operations such as: obtaining historical user context data from DB (refer to the introduction of data plane 112 above) based on the context identifier in the service request forwarded by SDF; creating a main task and decomposing subtasks based on the historical user context data and the service request message; carrying TCF information, task information, user context identifier, and atomic function information for each subtask's task request; after receiving the task response, optionally obtaining the subtask processing result based on the user context identifier and refreshing the locally stored user context data; confirming that the main task is completed, submitting the user context data stored by TCF 111 to DB with the user context identifier; and so on. Network Function (NF) elements (refer to atomic function 113 above) perform functions or operations such as: receiving a task request; determining the data type to be acquired based on the task type; optionally, determining the data type to be acquired based on the data type specified by the TCF in the task content; acquiring context data from the data plane based on the user context identifier; completing subtask processing based on the subtask information in the task request; submitting context data to the data plane based on the user context identifier in the task request; sending a task response carrying TCF information, subtask information, and task processing results (such as success / failure indicators); and so on. Further examples below illustrate the functions and execution steps of TCFs and NFs.

[0088] This embodiment of the disclosure establishes an independent data plane (i.e., a second network element), replacing the information exchanged between NFs with read / write access via the data plane. This eliminates east-west traffic / message interaction between NFs and reduces coupling between network elements. An NF can determine the data type to be acquired based on process information (e.g., task type). One task type can correspond to multiple data types, and conversion between task types and data types is possible. By adding TCF / NF service credentials and the service type, network element type, or data type to be read / written to the data submission / read request, TCF / NF controls the range of readable and writable data, ensuring secure data exchange between TCFs and NFs, and between NFs. In each task, the SDF can randomly select or select a TCF / NF instance to execute the task based on load balancing (LB). The TCF / NF instance can recover the context previously submitted by other TCF / NF instances from the data plane and process it, achieving a stateless design for TCFs and NFs and improving network flexibility and reliability.

[0089] Figure 2B illustrates a communication process diagram of some other embodiments of this disclosure. As shown in Figure 2B, communication process 201 involves a first network element 110 and a second network element 120. In some examples, the first network element 110 involved in communication process 201 can be replaced by a chip, module, or assembly within the first network element 110. The second network element 120 can be replaced by a chip, module, or assembly within the second network element 120. This example illustrates an instance where the first network element 110 is a service orchestrator. The service orchestrator can be, for example, a TCF. The second network element can be a DB (database). For a description of the first network element 110 and the second network element 120, please refer to the description of the embodiments above.

[0090] In the communication process 201, the first network element 110 receives (210) a first message, which includes a first user context identifier. The first message can be found in the description of the first message above. For example, the first message may be a request sent by SDF or other messages.

[0091] The first network element 110 sends a data read request 215 (212) to the second network element 120. The data read request 215 is used to obtain the user context 225 to be read. The data read request 215 includes the identifier of the user context 225 to be read, the requester's credentials, and the type of the user context 225 to be read. Correspondingly, the second network element 120 receives (214) the data read request 215 from the first network element 110. The data read request 215 may be an example of the first request 205. The user context 225 to be read is an example of the first user context in the above embodiment, which may be referred to as the first user context 225 below. The identifier of the user context 225 to be read is an example of the first user context identifier. The requester's credentials are an example of the first credentials, where the requester is the party requesting to read data, which in this example refers to the first network element 110. The type of the user context 225 to be read is an example of the type of the first user context in the above embodiment. In some examples, the data read request 215 may also include identification information (which may be referred to as first identification information), which is used to indicate whether the data of the corresponding network element can be obtained by other network elements that are different from the corresponding network element. For details, please refer to the introduction of the first identification information in the communication process 200 above.

[0092] After receiving the data read request 215, the second network element 120 sends (216) the first user context 225 to the first network element 110, and correspondingly, the first network element 110 receives (218) the first user context 225. The user context 225 sent by the second network element 120 to the first network element 110 is the user context corresponding to the identifier of the user context that the first network element 110 wants to read. In some examples, before sending the user context 225, the second network element 120 also verifies the requester's credentials to determine whether the data read request 215 is valid. For example, if the requester's credentials belong to the first network element 110 and the requester's credentials allow the first network element 110 to read the first user context corresponding to the type of the first user context, then the data read request 215 is valid; otherwise, the data read request 215 is invalid. If the data read request 215 is valid, the second network element 120 sends the user context 225 to the first network element 110.

[0093] The first network element 110 determines (220) the process to be orchestrated based on the first user context 225 and / or the first message. The determined process includes interactions with one or more network elements that are different from the service orchestrator (i.e., the first network element 110 in this example).

[0094] The first network element 110 can also send (222) a data submission request 235 to the second network element 120. The data submission request 235 can be an example of the second request in the above embodiment. Accordingly, the second network element 120 receives (224) the data submission request 235. The data submission request 235 is used to store the second user context in the second network element 120. In some examples, the data submission request 235 includes a second user context identifier, a requester credential, and the second user context. In some examples, the second user context can include the type of the second user context, the data or data set corresponding to the type of the second user context, and the second identification information, as described in the relevant introduction in the communication process 200 above. The requester credential is an example of the second credential, where the requester is the party requesting the data submission, which in this example refers to the first network element 110. Then the second network element 120 stores (226) the second user context and returns (222) a response 245 corresponding to the data submission request 235 to the first network element 110, which is an example of the second response in the above embodiment. In some examples, before sending the second response 245, the second network element 120 also verifies the second credential to determine whether the data submission request 235 is valid. For example, if the second credential belongs to the first network element 110 and allows the first network element 110 to store the second user context in the second network element 120, then the data submission request 235 is valid; otherwise, the data submission request 235 is invalid. If the data submission request 235 is valid, the first network element 110 receives (230) the response 245.

[0095] The above-described communication process 201 can be used as an example implementation of communication process 200. Therefore, it is understood that the specific implementation of some network element functions, methods, steps, or contents contained in messages / requests / data in communication process 201 can be referred to the description of the same functional network element, corresponding steps, or messages / requests / data in communication process 200, and will not be repeated in communication process 201.

[0096] Figure 2C illustrates a communication process diagram of some further embodiments of this disclosure. As shown in Figure 2C, communication process 203 involves a first network element 110 and a second network element 120. In some examples, the first network element 110 involved in communication process 200 can be replaced by a chip, module, or assembly within the first network element 110. The second network element 120 can be replaced by a chip, module, or assembly within the second network element 120. This example uses an instance where the first network element 110 is an NF (Network Function). In other examples, the first network element 110 can also be an instance of other network elements such as SM (Site Module) or MM (Model Module). The second network element 120 can be a DB (Database). For a description of the first network element 110 and the second network element 120, please refer to the description of the embodiments above.

[0097] In the communication process 203, the first network element 110 receives (232) a request message, which can be an example of the first message in the above embodiment, specifically a request message sent by SDF.

[0098] First network element 110 sends (234) a data read request 217 to second network element 120. The data read request 217 is used to obtain the user context 227 to be read. The data read request 217 includes the identifier of the user context 227 to be read, the requester's credentials, and the type of the user context 227 to be read. Accordingly, second network element 120 receives (236) the data read request 217 from first network element 110. This data read request 217 can be another example of the first request 205. The user context 227 to be read is another example of the first user context in communication process 200, which can be referred to as the first user context 227 below. The identifier of the user context 227 to be read is another example of the first user context identifier in communication process 200. The requester's credentials are another example of the first credentials in communication process 200, where the requester is the party requesting to read data, which in this example refers to first network element 110. The type of the user context 227 to be read is another example of the type of the first user context in communication process 200.

[0099] After receiving the data read request 217, the second network element 120 sends (238) the first user context 227 to the first network element 110, and the first network element 110 receives (240) the first user context 227. The user context 227 sent by the second network element 120 to the first network element 110 is a user context corresponding to the identifier of the user context that the first network element 110 wants to read. In some examples, before sending the user context 227, the second network element 120 also verifies the requester's credentials to determine whether the data read request 217 is valid. For example, if the requester's credentials belong to the first network element 110 and the requester's credentials allow the first network element 110 to read the first user context corresponding to the type of the first user context, then the data read request 217 is valid; otherwise, the data read request 217 is invalid. If the data read request 217 is valid, the second network element 120 sends the first user context 227 to the first network element 110.

[0100] The first network element 110 processes (242) request messages, for example, processing request messages sent by SDF based on the first user context.

[0101] The first network element 110 may also send a data submission request 237 (244) to the second network element 120. This data submission request 237 may be an example of the second request in the communication process 200 described above. Accordingly, the second network element 120 receives (246) the data submission request 237. The data submission request 237 is used to store the second user context in the second network element 120. In some examples, the data submission request 237 includes a second user context identifier, requester credentials, and the second user context. The second network element 120 then stores (248) the second user context and returns (250) a response 247 corresponding to the data submission request 237 to the first network element 110, which is another example of the second response in the above embodiment. Accordingly, the first network element 110 receives (250) the response 247. The data in the second user context is obtained based on the processing result of the first message. In some examples, after receiving the data submission request 237, the second network element 120 can verify the requester's credentials to determine whether the data submission request 237 is valid. For example, if the requester's credentials belong to the first network element 110 and the requester's credentials allow the first network element 110 to store the second user context in the second network element 120, then the data submission request 237 is valid; otherwise, the data submission request 237 is invalid. If the data submission request 237 is valid, the second network element 120 stores (248) the second user context.

[0102] The above-described communication process 203 can be used as another example implementation of communication process 200. Therefore, it is understood that the specific implementation of some network element functions, method steps, or the contents contained in messages / requests / data in communication process 203 can be referred to the description of the same functional network element, corresponding steps, or messages / requests / data in communication process 200, and will not be repeated in communication process 203.

[0103] Figures 3 and 4 illustrate communication processes of some embodiments of this disclosure. The communication process 400 shown in Figure 4 can be part of the communication process 300 shown in Figure 3. For example, communication process 300 is the main task lifecycle management process, while communication process 400 is the sub-task lifecycle management process, which is a detailed description of the specific process of step 309 in Figure 3.

[0104] At 301, SDF 320 receives the first message from UE / RAN (not shown in the figure) and selects the TCF instance serving the domain based on the domain information (such as slice) carried in the message header of the first message. TCF 310 in the following steps may refer to the TCF instance.

[0105] In step 303, SDF forwards the first message to the corresponding TCF instance for processing. If the header of the first message carries a user identifier (e.g., a temporary user identifier, which can be a globally unique temporary identifier (GUTI)), the context saved in SDF 320 is located based on the GUTI, and the user context identifier in the saved context is carried in the message sent in step 305. The user context identifier can be a context ID, SUPI, IMSI, etc.

[0106] At 305, TCF 310 sends a data read request to DB 340. The data read request carries the user context identifier, the service credentials of TCF 310, and the data type, service type, or network element type to be read. As an example, the service type or network element type can be TCF, meaning the request is to read data from TCF. The data type can be all, meaning the request is to read data from all services (including TCF).

[0107] Upon receiving the data read request, DB 340 can verify the validity of the service credential. For example, DB 340 checks whether the service credential belongs to TCF 310. If so, the service credential is valid; otherwise, it is invalid. The TCF 310 service credential corresponds to the read and write permissions of the TCF 310. DB 340 further verifies the validity of the data read request based on the corresponding read and write permissions.

[0108] If DB 340 locates the corresponding user context based on the user context identifier, it will include the previously saved user context data (which could be an example of the first user context) in the response (which could be an example of the first response). If the service type or network element type requested by TCF 310 is TCF, it will return the internal and public data previously submitted by TCF 310. If the requested data type is all, it will return the internal data previously submitted by TCF and the public data submitted by all services.

[0109] In some examples, DB 340 can determine the service type of the requester based on the service credentials, and thus determine whether to return the internal data corresponding to the requested data type. For example, if DB 340 determines that the service credentials belong to a TCF, then when TCF 310 requests a data type of TCF, it returns both the internal and public data of TCF 310. When the requested data type is another NF (such as SM), it only returns the public data of that other NF.

[0110] In some examples, when the data read request carries the data type, service type, or network element type to be read, it may also carry an internal data identifier (hereinafter referred to as internal identifier) ​​and / or a public data identifier (hereinafter referred to as public identifier). These carried internal data identifiers and / or public data identifiers are examples of the first identification information. DB 340 verifies the validity of the service type request from the requesting party (e.g., TCF 310) based on the service credential and returns the corresponding internal or public data. For example, when the requested data type is TCF and the data read request carries an internal identifier, DB 340 verifies the validity of the service credential in the data read request and confirms that the read / write permissions corresponding to the service credential support reading the internal data of TCF 310; then DB 340 returns the internal data of TCF 310. When the data type requested by TCF 310 is another NF (such as SM) and the data read request carries a public identifier, DB 340 verifies the validity of the service credential in the data read request and confirms that the read / write permissions corresponding to the service credential support reading the public data of that other NF; then DB 340 returns the public data of that other NF. The internal data of TCF 310 or the public data of SM returned above are included in the user context and are included in the response returned by DB 340, which can serve as an example of the first response. When the data type requested by TCF 310 is another NF (such as SM), and the data read request carries an internal identifier, DB 340 verifies the validity of the service credential in the data read request and confirms that the read / write permissions corresponding to the service credential do not support reading the internal data of that other NF. In this case, DB 340 returns a read failure / rejection response.

[0111] At step 307, TCF 310 creates a master task based on the initial message and the response from DB 340, and assigns a master task ID. The response from DB 340 can serve as an example of the first response, including the user context requested to be read in step 305. At step 309, TCF 310 decomposes subtasks based on the master task and invokes NF to execute the subtasks. Step 309 can be found in communication procedure 400 for details.

[0112] In 311, TCF 310 determines that the main task has been completed based on the arrangement of the main task and the execution status of the subtasks.

[0113] In step 313, TCF 310 sends a data submission request to DB 340. This request carries the user context identifier, TCF 310's service credentials, and the internal and public data that TCF 310 wants to submit. For example, if the network element type or service type is TCF, the data may include the processing results of the main task and subtasks, or the user status that needs to be refreshed. Upon receiving the data submission request, DB 340 can verify the validity of the service credentials. For instance, DB 340 confirms whether the service credentials belong to TCF 310; if so, the service credentials are valid; otherwise, they are invalid. DB 340 also verifies the validity of the data submission request based on the read and write permissions corresponding to the service credentials. If the verification passes, DB 340 saves the data submitted by TCF 310.

[0114] At 315, TCF 310 releases the main task and the locally saved context.

[0115] As shown above, step 309 in the above communication process 300 can be specifically referred to in communication process 400. In communication process 400, at 401, TCF 310 decomposes or arranges subtasks (for ease of description, the subtask is referred to as subtask X) based on the main task, the execution results of the previous subtasks (if any), and the locally configured main task information, and assigns the corresponding subtask ID.

[0116] In 403a, the TCF 310 selects NF group information that meets the conditions based on subtask X and locally configured subtask information. In 403b, the TCF 310 constructs a task request based on subtask X and NF group information. In some examples, the TCF 310 can determine the conditions that an NF must meet based on the subtask information and use these conditions as discovery parameters to request the NRF (network repository function) to discover NF group information that meets the conditions. This request carries the aforementioned discovery parameters. An NF group can contain multiple NF instances with the same capabilities.

[0117] At 405, TCF 310 sends the NF group information and the task request for subtask X to SDF 320. The task request carries TCF information, task information (including the main task ID and subtask ID, task type and task content), and user context identifier.

[0118] In section 407, the SDF 320 selects an NF-A instance based on NF group information. In some examples, the SDF 320 can obtain NF instance information from the NF group from the NRF or from its local database; this invention does not limit the method by which the SDF obtains NF instance information from the NF group. In other examples, the SDF 320 can randomly select an NF instance from the NF group, or select a less loaded NF instance based on factors such as the NF instance's load status.

[0119] In 409, SDF 320 forwards the task request for subtask X to the selected NF instance, such as NF-A 331.

[0120] In section 411, NF-A 331 can send a data read request to DB 340 to obtain the user context. The data read request carries the user context identifier, NF-A 331's service credentials, and the type of the user context to be obtained. The user context type can include one or more of the following: data type, network element type, or service type. In some examples, the data read request may also include an internal data identifier and / or a public data identifier. In some examples, NF-A 331 can determine the type of the user context to be obtained (e.g., one or more such as data type, network element type, or service type) based on the task type. Alternatively, NF-A 331 can obtain the required data type, network element type, or service type from the task content. In some examples, after receiving the data read request, DB 340 can verify the validity of the service credentials and the validity of the data read request based on the corresponding read / write permissions. In some examples, if the user context type is NF-A 331, the internal and public data previously submitted by NF-A 331 are returned. In some examples, if the user context type also includes NF-B, the public data previously submitted by NF-B is also returned. Step 411 is similar to step 305 in communication process 300; therefore, the specific implementation of step 411 and its examples can also be found in the above description of step 305 and its examples. In some examples, the task request is the first request for NF-A, that is, there is no user context corresponding to NF-A in the DB. For example, when the UE sends the initial registration to the network, the NF (such as AMF) in the network does not have a corresponding user context, and NF-A 331 may not need to read the user context from DB 340. In such an example, NF-A 331 will not send the above data read request to DB 340, and correspondingly, DB 340 will not send the user context to NF-A 331.

[0121] In step 413, NF-A331 completes the relevant processing of subtask X based on the task request and recovery context information of subtask X, and obtains the processing result of subtask X.

[0122] At 415, NF-A 331 sends a data commit request to DB 340, carrying the user context identifier, NF-A 331's service credentials, and the data that NF-A 331 wants to commit (as well as internal data identifiers and / or public data identifiers).

[0123] In step 417, NF-A 331 constructs a task response and sends it to SDF 320. The task response may carry TCF information and task information (such as the main task ID and subtask ID) and task processing results (such as task success / failure indicators). In some examples, NF-A 331 may include the entire processing result of step 413 in the task response and send it to SDF 320 / TCF 310. In such cases, NF-A 331 may omit step 415, and TCF 310 may omit step 421.

[0124] At 419, SDF 320 forwards task information and task results to TCF 310 based on TCF information. TCF 310 then locates the locally stored task context based on the task information.

[0125] At step 421, TCF 310 sends a data read request to DB 340 to obtain the processing result of NF-A 331 and determine the completion status of the subtask. This data read request may carry service credentials, user context identifier, and NF-A type (optionally, it may also include a public identifier). Step 421 is similar to step 305 in communication procedure 300; please refer to the above description of step 305 and its examples for details. In some examples, TCF 310 determines the service / data type to be read as NF-A 331 of the subtask X based on the type of subtask X.

[0126] After completing the steps related to subtask X, TCF 310 can further decompose the next subtask (denoted as subtask Y), as shown in step 423. Step 423 is similar to step 401, and can be found in step 401 for details, which will not be repeated here.

[0127] The processes shown in Figures 3 and 4 above, taking the lifecycle management of the main task and sub-tasks as an example, provide a detailed description of the communication process shown in Figure 2A. Figures 5 to 7 below will further describe the communication process (e.g., communication process 200) of this embodiment using the registration process as a specific example. In the following examples, the terminal is described using UE as an example; "terminal device," "terminal," and "UE" can be used interchangeably. When the first network element (e.g., the first network element 110 in the above embodiment) is a network function, AM 514, MM 516, SM 518, UDM / PCF 520, and AUSF 506 in the following examples can all be examples of the first network element.

[0128] Referring first to Figure 5, in communication process 500, at 501, terminal 510 sends a registration request to RAN 512. At 503, RAN 512 selects SDF 504 to support the service for the location of terminal 510 based on the location information of terminal 510. At 505, RAN 512 sends the registration request of terminal 510 and the location information of terminal 510 to SDF 504.

[0129] At step 507, SDF 504 selects TCF instance 502 to serve UE 510 based on the location information (e.g., tracking area identity, TAI) and domain information of terminal 510. This step can be an example of step 301 in communication procedure 300. In some examples, when terminal 510 sends registration requests multiple times (such as periodic registration update, mobility registration update, etc.), SDF 504 can select a different TCF instance to process each time. The steps related to TCF mentioned below are specifically performed by the selected TCF instance; that is, TCF 502 can be regarded as the selected TCF instance 502.

[0130] At step 509, SDF 504 forwards the registration request received from RAN 512 to TCF 502. This step is an example of step 303 in communication procedure 300. In some examples, if the service request received from UE 510 / RAN 512 (i.e., the registration request in this example) carries a user temporary identifier (such as GUTI), SDF 504 may also carry the context identifier corresponding to the locally stored user temporary identifier in the registration request message and forward it to TCF 502.

[0131] At step 511, TCF 502 reads its own internal / public data. Specifically, after receiving a request message (i.e., a registration request), TCF 502 obtains the user's context identifier from the request message, or obtains the user's hidden identifier from the registration request of terminal 510 as the user's context identifier. Based on the user context identifier, TCF 502's service credentials, and the type of the user context to be read (e.g., data type is TCF data), and optionally also based on the internal identifier and / or public identifier in the request message, TCF 502 obtains the user context previously submitted by other TCFs from DB 508. Based on the recovered user context (i.e., the user context previously submitted by other TCFs), TCF 502 performs task orchestration and processing, where task orchestration can be an example of the process orchestration mentioned in the Internet access embodiment. In some examples, if TCF 502 determines that terminal 510 is not registered to the network based on the recovered context, it executes the initial registration process / task and calls subtask 3 after subtasks 1 and 2 are completed. In other examples, if TCF 502 determines that terminal 510 is already registered with the network and terminal 510 requests to carry a periodic registration identifier, then it executes the periodic registration update process / task, skipping subtask 3 and executing subtasks 1, 2, and 4. In still other examples, if TCF 502 determines that terminal 510 is not registered with the network, but terminal 510 requests to carry a periodic registration identifier, then TCF 502 can construct a registration rejection message for terminal 510.

[0132] In step 513, TCF 502 creates a main task - initial registration process based on the registration request from terminal 510 and the obtained DB response, and assigns a main task ID. This step can be used as an example of step 307 in communication process 300. In step 515, TCF 502 decomposes subtask 1 based on the main task - initial registration process and the task orchestration strategy (or business orchestration chain) corresponding to the preset / predefined registration process. In this example, subtask 1 is an authentication preparation task. TCF 502 confirms that it needs to support the NF Group (NF type = authentication function, such as AUSF) to complete subtask 1, and constructs a task request. This task request carries TCF information, task information (including main task ID and subtask ID, task type = authentication preparation, and task content), and user context identifier. This step 515 can be used as an example of steps 401, 403a, and 403b in communication process 400.

[0133] At 517, TCF 502 sends the NF group information and task request to SDF 504. This step can be seen as an example of step 405 in communication procedure 400. At 519, SDF 504 selects an AUSF instance from the NF group. This step can be seen as an example of step 407 in communication procedure 400. At 521, SDF 504 forwards the task request to the AUSF instance. This step can be seen as an example of step 409 in communication procedure 400. An AUSF instance is an example of an NF instance in communication procedure 400. Hereinafter, AUSF refers to the selected AUSF instance; that is, AUSF 506 refers to AUSF instance 506.

[0134] In step 523, AUSF 506 acquires or generates authentication data / vectors corresponding to the user. In some examples, AUSF 506 can acquire the authentication vector from UDM 520 carrying the user's context identifier or SUCI. In some examples, AUSF 506 can acquire authentication data from the data plane UDR (unified data repository) carrying the user's context identifier or SUCI and generate the authentication vector. The authentication vector may include AUTN (authentication token), RAND (random value), XRES (expected response), key K_AUSF, and security algorithm. In some examples, AUSF 506 can also acquire the user's subscription permanent identifier (SUPI) from UDM 520 / data plane UDR. Step 523 can be an example of subtask processing, such as the example in step 413 above. In some examples, the data plane supports storing context data for network services, which can be understood as UDSF or database DB. In some examples, the data plane also supports storing user subscription and policy data, such as the UDR mentioned above. When the data plane refers to the UDR, it is different from UDSF / DB.

[0135] At step 525, the NF (AUSF 506 in this example) writes its internal / public data. AUSF 506 sends a data commit request to DB 508, carrying the user context identifier, AUSF 506's service credentials, and the data to be committed by AUSF 506 (e.g., data type AUTN and its corresponding public data identifier, data type RAND and its corresponding public data identifier, data type XRES and its corresponding internal data identifier, data type SUPI and its corresponding internal data identifier, data type K_AUSF and its security algorithm and its corresponding internal data identifier). This step can be seen as an example of step 415 in communication process 400.

[0136] In step 527, AUSF 506 constructs a task response, which carries TCF information, task information (such as the main task ID and subtask ID), and task processing result (such as task success / authentication preparation complete), and sends the task response to SDF 504. This step can be used as an example of step 417 in communication procedure 400.

[0137] At 529, SDF 504 forwards the subtask information and task processing result to TCF 502 based on the TCF information. TCF 502 locates the task context based on the task information (such as the main task ID and subtask ID). This step can be used as an example of step 419 in communication process 400.

[0138] At step 531, TCF 502 reads public data from other NFs. Specifically, TCF 502 reads the data submitted to DB 508 in step 525, based on the user context identifier, TCF 502's service credentials, and the type of the user context to be read (e.g., data type). This step can be used as an example of step 421 in communication procedure 400. In some examples, TCF 502 can determine the data type to be read as the NF type executing subtask 1 (i.e., AUSF 506) based on the type of subtask 1, i.e., authentication preparation task. In some examples, the data read request sent by TCF 502 for reading public data from other NFs may also carry a public data identifier. In some examples, TCF 502 can determine, based on the orchestration strategy corresponding to the main task, i.e., the registration process, that the next step requires constructing an authentication request for UE 510, and determine the data type to be read as AUTN and RAND based on the next action. Upon receiving the data read request, DB 508 verifies the validity of the service credential of TCF 502, determines that TCF 502 is permitted to read public data (such as AUTN and RAND) of AUSF 506, and returns the corresponding data.

[0139] At step 533, TCF 502 constructs an authentication request based on the orchestration strategy corresponding to the main task, i.e., the registration process, and the acquired data, and sends the authentication request to UE 510. In some examples, the authentication request message can be first sent to SDF 504, which forwards it to RAN 512, and then RAN 512 forwards it to UE 510. At step 535, TCF 502 receives the authentication response from UE 510. In some examples, UE 510 can first send the authentication response message to RAN 512, which forwards it to SDF 504, and then SDF 504 forwards it to TCF 502.

[0140] Referring to Figure 6, in communication process 600, at steps 601 and 603, TCF 502 decomposes the main task (registration process and corresponding orchestration strategy), the processing result of subtask 1, and the UE's authentication response into subtask 2. Subtask 2 can be an authentication verification task. Specifically, TCF 502 confirms the need to support the NF Group (NF type = AUSF) to complete subtask 2 and constructs a task request. The task request sent by TCF 502 to SDF 504 carries TCF information, task information (including main task ID and subtask ID, task type = authentication verification, and task content = RES*(response*) obtained from the UE's authentication response), and user context identifier. TCF 502 can send the NF Group information along with the task request to SDF 504. The above operation can be used as an example implementation of steps 401 to 405 shown in communication process 400.

[0141] At step 605, SDF 504 selects an AUSF instance 506 for subtask 2. This step can be used as an example of step 407 in communication process 400. It should be noted that, for ease of description of the interaction between network elements in the flowchart, the AUSF (AUSF instance) in Figures 5 and 6 above is labeled as 506. However, it is understood that the AUSF instance selected by SDF 504 for subtask 2 can be different from the AUSF instance selected for subtask 1 at step 519, that is, AUSF 506 in Figures 5 and 6 can also be implemented as different instances of AUSF.

[0142] At 607, SDF 504 forwards the task request to the selected AUSF instance 506. This step can be used as an example of step 409 in communication procedure 400.

[0143] At 609, the NF (in this case, AUSF instance 506) reads its own internal / public data. This step can be used as an example of step 411 in communication procedure 400.

[0144] AUSF 506 reads the authentication data submitted by AUSF 506 in step 525 from DB 508 based on the user context identifier, AUSF 506's service credentials, and the type of the user context to be read (e.g., data type). As described above, the AUSF 506 that submitted the authentication data may be a different AUSF instance from the AUSF 506 that reads the user context. In some examples, AUSF 506 determines, based on the type of subtask 2, i.e., the authentication verification task, whether the data to be read is internal and public data of AUSF 506 (e.g., network element or service type is AUSF, carrying internal and public data identifiers), or data type XRES, SUPI, key K_AUSF, carrying an internal data identifier.

[0145] AUSF 506 determines whether UE authentication was successful based on the acquired XRES and RES* in the request. AUSF 506 can generate a corresponding key K_TCF for TCF 502 based on the acquired key K_AUSF. This step can be used as an example of step 413 in communication procedure 400.

[0146] At step 611, AUSF 506 sends a data submission request to DB 508 to store the authentication result. The data submission request carries the user context identifier, AUSF 506's service credentials, and the data to be submitted by AUSF 506 (data types include: user status = authenticated, SUPI, key K_TCF and security algorithm, and carries a public data identifier). This step can be used as an example of step 415 in communication procedure 400.

[0147] At 613, AUSF 506 constructs a task response to send to SDF 504. The task response carries TCF information, task information, and task processing result (e.g., indicating authentication passed). This step can be an example of step 417 in communication procedure 400, where the task response, i.e., the task processing result, can serve as an example of the execution result of subtask X in step 417.

[0148] At 615, SDF 504 forwards the subtask information and task processing results to TCF 502 based on TCF information. TCF 502 locates the task context based on the task information (such as the main task ID and subtask ID). This step can be an example of step 419 in communication procedure 400.

[0149] At step 617, TCF 502 reads the data submitted in step 611 (AUSF 506) from the DB based on the user context identifier, TCF 502's service credentials, and the type of the user context to be read (e.g., data type). This step can be an example of step 421 in communication process 400. In some examples, TCF 502 determines the data type to be read based on the type of subtask 2, i.e., authentication verification task, whether it is the NF type (i.e., AUSF) executing subtask 2, or the data type is SUPI, key K_TCF, and security algorithm. Optionally, the data read request for reading public data of other NFs may also carry a public data identifier. DB 508 verifies the validity of the service credentials, determines that TCF 502 allows reading the public data of AUSF 506, and returns the corresponding data.

[0150] In steps 619 and 621, TCF 502 decomposes subtask 3 based on the main task (registration process) and corresponding orchestration strategy, as well as the processing results of subtasks 1 and 2. Subtask 3 may be an example of a subscription policy task. Steps 619 and 621 can serve as another example implementation of steps 401, 403a, and 403b in communication process 400. TCF 502 confirms the need to support the NF group (NF type = subscription policy function, such as UDM / PCF) to complete subtask 3 and constructs a task request. The task request sent by TCF 502 to UDM / PCF 520 carries TCF information, task information (including main task ID and subtask ID, task type = subscription policy and task content), and user context identifier. TCF 502 sends the NF group information and task request to SDF 504.

[0151] At 623, SDF 504 selects a UDM / PCF instance for subtask 3. This step can be an example of step 407 in communication procedure 400.

[0152] At 625, SDF 504 forwards the task request to the selected UDM / PCF instance. This step can be an example of step 409 in communication procedure 400. In some examples, UDM / PCF determines that it does not need to read data from DB 508 based on the type of subtask 3. In other examples, TCF 502 does not carry SUPI in the task content, so UDM / PCF determines that it needs to obtain SUPI based on the task type of subtask 3, and sends a data read request to DB 508 (carrying the user context identifier, service credentials, and the data type to be read as SUPI), and obtains SUPI from DB 508. In such examples, this step of reading data from DB 508 can be an example of step 411 in communication procedure 400.

[0153] At step 627, UDM / PCF 520 completes registration based on the TCF information in the task request or the user's context identifier. At step 629, UDM / PCF 520 obtains the user's subscription data from the data plane UDR according to the SUPI. At step 631, UDM / PCF completes subscription for subscription data changes based on the TCF information in the task request or the user's context identifier. At step 633, UDM / PCF obtains the user's policy data from the data plane UDR according to the SUPI. Steps 627, 629, 631, and 633 can be used as examples of step 413 in communication process 400.

[0154] At 635, UDM / PCF 520 sends a data submission request to DB 508. The data submission request carries the user context identifier, UDM / PCF 520's service credentials, and the data to be submitted (the data type is the user's subscription and policy data, carrying a public data identifier). This step can be an example of step 415 in communication procedure 400.

[0155] At 637, UDM / PCF 520 constructs a task response to send to SDF 504. The task response carries TCF information, task information, and task processing results (e.g., an indication that the task was executed successfully). This step can be an example of step 419 in communication procedure 400.

[0156] At 639, SDF 504 forwards the subtask information and task processing result to TCF 502 based on the TCF information. TCF 502 locates the task context based on the task information (such as the main task ID and subtask ID). This step can be an example of step 419 in communication procedure 400.

[0157] In step 641, TCF 502 reads the data submitted by UDM / PCF 520 from DB 508 based on the user context identifier, TCF 502's service credentials, and the data type to be read. In some examples, TCF 502 can determine the network element type to be read as the NF type executing subtask 1 (i.e., UDM / PCF) or the data type to be read as a trigger event in policy data, based on the type of subtask 3, i.e., the subscription policy task. Optionally, the data read request used to read the data also carries a public data identifier. DB 508 can verify the validity of the service credentials and determine whether TCF 502 allows reading the public data of UDM / PCF. If allowed, it returns the corresponding data. This step can be an example of step 421 in communication process 400.

[0158] Referring to Figure 7, in communication process 700, at steps 701 and 703, TCF 502 decomposes subtask 4 based on the main task (registration process) and corresponding orchestration strategy, as well as the processing result of subtask 3. Subtask 4 is, for example, an access task. Steps 701 and 703 can be used as example implementations of steps 401, 403a, and 403b in communication process 400. TCF 502 confirms the NF group (NF type = AM) that needs to support the completion of subtask 4 and constructs a task request. The task request sent by TCF 502 to AM 514 carries TCF information, task information (including main task ID and subtask ID, task type = access, and task content), and user context identifier. TCF 502 sends the NF group information and task request to SDF 504.

[0159] At 705, SDF 504 selects an AM instance 514 for subtask 4. This step can be an example of step 407 in communication procedure 400.

[0160] At 707, SDF 504 forwards the task request to the selected AM instance 514. This step can be an example of step 409 in communication procedure 400.

[0161] At 709, AM 514 reads data from DB 508 based on the user context identifier, AM 514's service credentials, and the data type to be read.

[0162] Optionally, AM 514 determines the data type it wants to read—UDM / PCF data or subscription policy data—based on the type of subtask 4: access task, and optionally also carries a public data identifier. This step can be an example of step 411 in communication procedure 400.

[0163] In step 711, AM 514 compares the obtained subscription data (such as RAT (radio access technology), TAI (tracking area identity) / 4G access or 5G access) with the RAT / TAI information carried in the task content by TCF 502 to determine whether terminal 510 can access the network. In step 713, AM 514 compares the obtained policy data (such as service area restrictions) with the TAI information carried in the task content by TCF 502 to determine whether terminal 510 can access the network. Steps 711 and 713 can be used as an example of step 413 in communication process 400.

[0164] At step 715, the NF (AM 514 in this example) writes its internal or public data. In some examples, AM 514 sends a data commit request to DB 508, carrying the user context identifier, AM 514's service credentials, and the data to be committed (e.g., data type access status = passed, carrying a public data identifier). This step can be an example of step 415 in communication procedure 400.

[0165] At 717, AM 514 constructs a task response, carrying TCF information, task ID, and task processing result (access successful), and sends it to SDF504 / TCF 502. This step can be an example of step 417 in communication procedure 400.

[0166] At 719, SDF 504 forwards the subtask information and task processing results to TCF 502 based on the TCF information. TCF 502 locates the task context based on the task information (such as the main task ID and subtask ID). This step can be an example of step 419 in communication procedure 400.

[0167] In step 721, TCF 502 determines that the registration process is complete based on the main task (registration process) and the corresponding orchestration strategy, as well as the processing results of subtasks 1-4. It then determines the data type to be submitted, including the processing results of the main task or all user data stored by TCF 502. This step can be an example of step 311 in communication process 300.

[0168] At 723, TCF 502 sends a data submission request to DB 508. The data submission request carries the user context identifier, TCF 502's service credentials, and the data to be submitted by TCF 502 (e.g., public data includes: user status = registered, etc.; internal data of TCF 502 includes: processing results of main tasks and subtasks). This step can be an example of step 313 in communication procedure 300.

[0169] At 725, TCF 502 notifies SDF 504 of SUPI and other information. At 727, TCF 502 constructs a registration acceptance response, performing encryption integrity protection based on the result of subtask 2 in the context. At 729, TCF 502 sends a registration acceptance message to SDF 504. At 731, TCF 502 releases the registration task. At 733, SDF 504 allocates GUTI. At 735, SDF 504 sends an acceptance registration message to UE 510 via RAN 512.

[0170] It should be noted that if the registration process is initiated again in the future, SDF 504 in step 507 can select another TCF instance. This TCF instance can obtain data such as the user's registration status from the DB based on the user context identifier and the TCF service credentials, and start executing from step 509 of process 500. For the specific subsequent process, please refer to the steps above, which will not be repeated here.

[0171] Figure 8 shows a schematic process block diagram implemented at a first network element in some embodiments of this disclosure. As shown in Figure 8, the process shown in process block diagram 800 can be executed by a first network element, such as first network element 110, or a chip, module, or assembly within first network element 110. The following description uses the execution of the process by a first network element as an example. In block 810, the first network element receives a first message, which includes a first user context identifier. In block 820, the first network element sends a first request to a second network element, which is used to obtain a first user context. The first request includes a first user context identifier, a first credential, and a type of the first user context. In some embodiments, the process may also include other operations performed at the first network element in conjunction with Figures 2A to 7 as described in embodiments of this disclosure.

[0172] Figure 9 shows a schematic process block diagram of some embodiments of this disclosure implemented at a second network element. As shown in Figure 9, the process shown in process block diagram 900 can be executed by a second network element, such as second network element 120, or a chip, module, or assembly within second network element 120. The following description uses the execution of the process by a second network element as an example. In block 910, the second network element receives a first request from a first network element. The first request is used to obtain a first user context, and the first request includes a first user context identifier, a first credential, and the type of the first user context. In some embodiments, the process may also include other operations performed at the second network element in conjunction with Figures 2A to 7 as described in the embodiments of this disclosure.

[0173] Figure 10 is a block diagram of a device 1000 that can be used to implement some embodiments of the present application. In some embodiments, device 1000 may be a component of a communication network infrastructure, such as a base station (e.g., NodeB, evolved NodeB (eNodeB or eNB), next-generation NodeB (sometimes called next-generation NodeB, gNodeB or gNB), home subscriber server (HSS), gateway (GW), such as packet gateway (PGW) or serving gateway (SGW), or various other nodes or functions within a core network (CN) or Public Land Mobility Network (PLMN). In other embodiments, device 1000 may be a device connected to the network infrastructure via a wireless interface, such as a mobile phone, smartphone, or other such device that can be classified as user equipment (UE). In some embodiments, device 1000 may be machine-type communication (M2C). Communications (MTC) devices (also known as machine-to-machine (M2M) devices), or other devices that, although not providing direct service to users, can be classified as UEs. In some embodiments, device 1000 may be a roadside unit (RSU), a vehicle UE (V-UE), a pedestrian UE (P-UE), or an infrastructure UE (I-UE). In some scenarios, device 1000 may also be referred to as a mobile device, a term intended to reflect a device connected to a mobile network, regardless of whether the device itself is designed for or capable of being mobile. A particular device may utilize all or only a subset of the components shown, and the level of integration may vary depending on the device. Furthermore, device 1000 may contain multiple instances of components, such as multiple processors, memories, transmitters, receivers, etc.

[0174] Device 1000 typically includes a processor 1002, such as a central processing unit (CPU), and may further include a dedicated processor, such as a graphics processing unit (GPU) or other such processor, memory 1004, a network interface 1006, and a bus 1008 for connecting the components of device 1000. Optionally, device 1000 may also include components such as a mass storage device 1010, a video adapter 1012, and an I / O interface 1016 (shown in dashed lines).

[0175] Memory 1004 may include any type of non-transitory system memory readable by processor 1002, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or combinations thereof. In one embodiment, memory 1004 may include more than one type of memory, such as ROM used at startup and DRAM used for program and data storage during program execution. Bus 1008 may be one or more of a plurality of bus architectures of any type, including a memory bus or memory controller, a peripheral bus, or a video bus.

[0176] Device 1000 may also include one or more network interfaces 1006, which may include at least one of wired network interfaces and wireless network interfaces. As shown in FIG10, network interface 1006 may include a wired network interface for connecting to network 1022, and may also include a wireless access network interface 1020 for connecting to other devices via a wireless link. When device 1000 is a network infrastructure element, the wireless access network interface 1020 may be omitted for nodes or functions that are elements of a PLMN rather than elements at the wireless edge. When device 1000 is infrastructure at the wireless edge of a network, both wired and wireless network interfaces may be included. When device 1000 is a wirelessly connected device, such as a user equipment, the wireless access network interface 1020 may be present and may be supplemented by other wireless interfaces such as a WiFi network interface. Network interface 1006 allows device 1000 to communicate with remote entities such as those connected to network 1022.

[0177] Mass storage 1010 may include any type of non-transitory storage device configured to store data, programs, and other information and make the data, programs, and other information accessible via bus 1008. Mass storage 1010 may include, for example, one or more of a solid-state drive, hard disk drive, disk drive, or optical disk drive. In some embodiments, mass storage 1010 may be located remotely from device 1000 and may be accessed using a network interface such as interface 1006. In the illustrated embodiment, mass storage 1010 is distinct from the memory 1004 that includes it, and mass storage 1010 typically performs storage tasks compatible with higher latency but typically provides low or no fluctuation. In some embodiments, mass storage 1010 may be integrated with heterogeneous memory 1004.

[0178] Optional video adapter 1012 and I / O interface 1016 (shown in dashed lines) provide interfaces for coupling device 1000 to external input and output devices. Examples of input and output devices include a display 66 coupled to video adapter 1012 and an I / O device 1018, such as a touchscreen, coupled to I / O interface 1016. Other devices may be coupled to device 1000 and may utilize additional or fewer interfaces. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide interfaces for external devices. Those skilled in the art will understand that in embodiments where device 1000 is part of a data center, I / O interface 1016 and video adapter 1012 may be virtualized and provided via network interface 1006.

[0179] Figure 11 is a schematic diagram of the structure of a device 1100 according to some embodiments of this application. As shown in Figure 11, the device 1100 includes a receiving unit 1102 and a transmitting unit 1104. The device 1100 can be applied to the communication system shown in Figure 1A and can implement the methods provided in the preceding embodiments, such as method 800. Optionally, the physical manifestation of the device 1100 can be a communication device, such as a network device. Alternatively, the device 1100 can be other devices capable of implementing the functions of a communication device, such as a processor or chip inside a communication device. Specifically, the device 1100 can be a programmable chip, such as a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), an application-specific integrated circuit (ASIC), or a system on a chip (SOC).

[0180] In some embodiments, the receiving unit 1102 may be configured to receive a first message, the first message including a first user context identifier. The sending unit 1104 may be configured to send a first request to a second network element, the first request being used to obtain the first user context, the first request including the first user context identifier, a first credential, and the type of the first user context.

[0181] In some embodiments, the apparatus 1100 may include various other units or modules that can be configured to perform the various operations or functions described with respect to the foregoing method embodiments. Specific details can be obtained by referring to the detailed description of the foregoing method embodiments, and will not be repeated here.

[0182] Figure 12 is a schematic diagram of the structure of a device 1200 according to some other embodiments of this application. As shown in Figure 12, the device 1200 includes a receiving unit 1202. The device 1200 can be applied to the communication system shown in Figure 1A and can implement the methods provided in the foregoing embodiments, such as method 900. Optionally, the physical manifestation of the device 1200 can be a communication device, such as a UE. Alternatively, the device 1200 can be other devices capable of implementing the functions of a communication device, such as a processor or chip inside the communication device. Specifically, the device 1200 can be a programmable chip, such as a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), an application-specific integrated circuit (ASIC), or a system on a chip (SOC).

[0183] In some embodiments, the receiving unit 1202 may be configured to receive a first request from a first network element, the first request being used to obtain a first user context, the first request including a first user context identifier, a first credential, and a type of the first user context.

[0184] In some other embodiments, the apparatus 1200 may include various other units or modules that can be configured to perform the various operations or functions described with respect to the foregoing method embodiments. Specific details can be obtained by referring to the detailed description of the foregoing method embodiments, and will not be repeated here.

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

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

[0187] Based on the above embodiments, this application also provides a computer program that, when run on a computer, causes the computer to execute any of the methods provided in the above embodiments.

[0188] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program. When executed by a computer, the computer program causes the computer to perform any of the methods provided in the above embodiments. The storage medium can be any available medium that can be accessed by a computer. By way of example, but not limited to, a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code having the form of instructions or data structures and that can be accessed by a computer.

[0189] Based on the above embodiments, this application also provides a chip for reading a computer program stored in a memory and implementing any of the methods provided in the above embodiments.

[0190] Based on the above embodiments, this application provides a chip system including a processor for supporting a computer device in implementing the functions involved in the communication devices in the above embodiments. In one possible design, the chip system further includes a memory for storing necessary programs and data of the computer device. This chip system may be composed of chips or may include chips and other discrete components.

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

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

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

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

Claims

1. A communication method applied to a first network element, the method comprising: Receive a first message, the first message including a first user context identifier; as well as A first request is sent to the second network element. The first request is used to obtain a first user context. The first request includes the first user context identifier, the first credential, and the type of the first user context.

2. The method of claim 1, wherein the type of the first user context includes at least one of the following: Data type, wherein the data type indicates at least one piece of data corresponding to the network element; Network element type, wherein the network element type indicates the data set of the corresponding network element; or Service type, which indicates the data set of the corresponding service of the corresponding network element.

3. The method according to claim 1 or 2, wherein at least one of the following: The first request includes a data type, and the first user context includes data corresponding to the data type; or The first request includes a network element type or a service type, and the first user context includes a data set corresponding to the network element type or the service type.

4. The method according to claim 3, wherein the first request further includes first identification information, the first identification information being used to indicate whether the data of the corresponding network element supports being obtained by other network elements different from the corresponding network element.

5. The method of claim 4, wherein at least one of the following: The data type indicates the data of the first network element, and the first identification information indicates that it is not supported to be obtained by network elements other than the first network element. The first user context includes the internal data of the first network element. The data type indicates the data of the first network element, and the first identification information indicates that it supports acquisition by network elements other than the first network element; the first user context includes the public data of the first network element; or The data type indicates data of a third network element that is different from the first network element, and the first identification information indicates that it can be obtained by network elements other than the third network element. The first user context includes the public data of the third network element.

6. The method according to any one of claims 1 to 5, further comprising: A second request is sent to the second network element. The second request is used to store the second user context in the second network element. The second request includes a second user context identifier, a second credential, and the second user context.

7. The method of claim 6, wherein the second user context comprises: The type of the second user context, and the data or data set corresponding to the type of the second user context, wherein the type of the second user context includes at least one of network element type, service type, and data type; or The second user context type, the data or data set corresponding to the second user context type, and the second identification information, wherein the second identification information indicates whether the data of the first network element supports being acquired by a third network element different from the first network element.

8. The method according to claim 6 or 7, further comprising: Receive a second response corresponding to the second request, the second response including an indication of the processing result of the second request.

9. The method according to any one of claims 1 to 8, further comprising: Receive a first response corresponding to the first request, the first response including the first user context.

10. The method according to any one of claims 1 to 9, wherein the type of the first network element is a service orchestrator, and the method further comprises: A process to be orchestrated is determined based on at least one of the first user context or the first message, the process including interactions with one or more network elements different from the first network element.

11. The method of claim 10, wherein the interaction comprises: Send a third request, the third request including information about the first network element, information about the process, and the first user context identifier; as well as Receive a third response corresponding to the third request, the third response including information about the first network element, information about the process, and the processing result of the third request.

12. The method according to any one of claims 1 to 9, wherein the type of the first network element is a network function, the first message is a fourth request, the fourth request including information of the service orchestrator, process information, and the first user context identifier, the method further comprising: Process the fourth request; as well as Send a fourth response corresponding to the fourth request, the fourth response including information about the service orchestrator, information about the process, and the processing result of the fourth request.

13. The method according to any one of claims 1 to 12, wherein the first network element is an instance of a service orchestrator or an instance of a network function, and the second network element is a data management function.

14. A communication method applied to a second network element, the method comprising: A first request is received from a first network element. The first request is used to obtain a first user context. The first request includes a first user context identifier, a first credential, and a type of the first user context.

15. The method of claim 14, wherein the type of the first user context includes at least one of the following: Data type, wherein the data type indicates at least one piece of data corresponding to the network element; Network element type, wherein the network element type indicates the data set of the corresponding network element; or Service type, which indicates the data set of the corresponding service of the corresponding network element.

16. The method according to claim 14 or 15, wherein at least one of the following: The first request includes a data type, and the first user context includes data corresponding to the data type; or If the first request includes a network element type or a service type, the first user context includes a data set corresponding to the network element type or the service type.

17. The method according to claim 16, wherein the first request further includes first identification information, the first identification information being used to indicate whether the data of the corresponding network element supports being obtained by other network elements different from the corresponding network element.

18. The method of claim 17, wherein at least one of the following: The data type indicates the data of the first network element, and the first identification information indicates that it is not supported to be obtained by network elements other than the first network element. The first user context includes the internal data of the first network element. The data type indicates the data of the first network element, and the first identification information indicates that it supports acquisition by network elements other than the first network element; the first user context includes the public data of the first network element; or The data type indicates data of a third network element that is different from the first network element, and the first identification information indicates that it can be obtained by network elements other than the third network element. The first user context includes the public data of the third network element.

19. The method according to any one of claims 14-18, further comprising: The first request is deemed legitimate based on the first credential of the first network element.

20. The method of claim 19, wherein determining the legitimacy of the first request comprises: The access rights of the first network element are determined based on the first credential; as well as It is determined that the permission to acquire supports acquiring the first user context indicated by at least one of the following: The type of the first user context; or The first user context type and the first identification information, wherein the first identification information is used to indicate whether the data of the corresponding network element can be obtained by other network elements different from the corresponding network element.

21. The method according to any one of claims 14 to 20, further comprising: A second request is received, the second request being used to store a second user context to the second network element, the second request including a second user context identifier, a second credential, and the second user context.

22. The method of claim 21, wherein the second user context comprises: The type of the second user context, and the data or data set corresponding to the type of the second user context, wherein the type of the second user context includes at least one of network element type, service type, and data type; or The second user context type, the data or data set corresponding to the second user context type, and the second identification information, wherein the second identification information indicates whether the data of the first network element can be obtained by a third network element different from the first network element.

23. The method according to claim 21 or 22, further comprising: The second request is deemed legitimate based on the second credential.

24. The method of claim 23, wherein determining the legitimacy of the second request comprises: The storage permissions of the first network element are determined based on the second credential; as well as The storage permissions are determined to support storage of the second user context indicated by at least one of the following: The type of the second user context; or The second user context type and the second identification information, the second identification information indicating whether the data of the first network element supports being acquired by a third network element different from the first network element.

25. The method according to any one of claims 21 to 24, further comprising: Send a second response corresponding to the second request, the second response including an indication of the processing result of the second request.

26. The method according to any one of claims 14 to 25, further comprising: Send a first response corresponding to the first request, the first response including the first user context.

27. A communication device, comprising: A module for performing the method according to any one of claims 1 to 13, or a module for performing the method according to any one of claims 14 to 26.

28. A communication device, comprising: A processor for performing the method according to any one of claims 1 to 13 or claims 14 to 26.

29. A communication system comprising a first network element and a second network element, wherein the first network element is configured to perform the method as described in any one of claims 1 to 13, and the second network element is configured to perform the method as described in any one of claims 14 to 26.

30. A computer-readable storage medium storing instructions that, when executed, cause the method according to any one of claims 1 to 13 or claims 14 to 26 to be performed.

31. A computer program product comprising instructions for causing the method according to any one of claims 1 to 13, or claims 14 to 26, to be implemented.

Images