Context migration method, apparatus and system

Abstract

The present application relates to the technical field of communications. Provided are a context migration method, apparatus and system. The method comprises: a first node in a first domain acquiring first information, wherein the first information is used for indicating an identifier of first context of a user and an identifier of a second node in the first domain, and the user moves from a second domain to the first domain; and on the basis of the first information, determining to migrate second context from the second domain to the first domain, wherein the second context comprises at least one of the following in the first context: context supported by the first domain, context that the second node can take over, or context related to a function of the second node. In the technical solution of the present application, a first node can decide, on the basis of first information, whether to perform migration and determine context to be migrated, thereby implementing on-demand migration of the context.

Description

Context transfer methods, apparatus and systems

[0001] This application claims priority to Chinese Patent Application No. 202510318551.0, filed on March 14, 2025, entitled “Context Transfer Method, Apparatus and System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communications, and more particularly to a context transfer method, apparatus, and system. Background Technology

[0003] In a stateless network architecture, context can be stored and managed through a unified data plane. Consumer nodes (such as mobility management nodes or session management nodes) obtain context from the data plane to perform tasks. For example, a mobility management node can obtain a user's context from the data plane based on the user's identifier. This reduces the signaling required for consumer nodes to obtain context.

[0004] However, this method can result in significant signaling overhead when consumer nodes acquire context during cross-domain changes in user services. Summary of the Invention

[0005] This application provides a context migration method, apparatus, and system, so that consumer nodes can migrate contexts on demand, thereby reducing signaling overhead when acquiring context.

[0006] Firstly, a context transition method is provided, which can be applied to a first node. For example, the first node can be a data management node.

[0007] For example, the method includes: obtaining first information, the first information indicating: an identifier of a first context and an identifier of a second node, the second node being used to request the first context; determining a second context to migrate based on the first information, the second context including the following contexts in the first context: a context in a first domain where the second node is located, and / or a context that the second node can take over, and / or a context related to the functionality of the second node.

[0008] Based on the above scheme, the first node can decide whether to migrate and determine the context to be migrated based on the first information. In the method of this application embodiment, the first node can migrate the context on demand based on the capabilities and / or functions of the second node, enabling the second node to obtain the context in the local network, thereby reducing signaling overhead.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, obtaining the first information further includes: receiving a first request from a second node, the first request being used to obtain a first context, the first request carrying an identifier of the first context and / or an identifier of the second node; and obtaining the first information according to the first request.

[0010] Based on the above scheme, when the first node receives a request from the second node to obtain the first context, it can obtain the first information and trigger migration decisions, which helps to quickly respond to the needs of the second node and reduce the latency of context migration.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, determining the migration of the second context based on the first information further includes: obtaining the second information, which is used to indicate: a first data node, the first data node belongs to a first domain, the first data node is used to store the context in the first domain, and the first node is used to manage the context in the first data node; and determining the migration of the second context based on the first information and the second information.

[0012] Based on the above scheme, the first node can obtain the first data node it manages, which is also the node that stores the context in the first domain. Thus, the first node can obtain information from the first data node, which helps the first node make migration decisions based on the information from the first data node and the second information, making the decision results more accurate.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, the second information is also used to indicate the information of the second data node, the second data node being the data node where the first context is located, and obtaining the second information further includes: sending the identifier of the first context to the routing node, the identifier of the first context being used by the routing node to obtain the information of the second data node according to the first distribution information, the first distribution information being used to indicate that the first context is distributed in the second data node; and receiving the information of the second data node from the routing node.

[0014] Based on the above scheme, the first node can obtain the data node where the first context is located based on the information of the data nodes distributed in the context maintained in the routing node. This helps the first node make migration decisions based on the information of the first data node and the second information, making the decision results more accurate. Furthermore, through the routing node, the first node can complete the addressing of the second data node, enabling end-to-end communication between the two.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, determining the migration second context based on the first information and the second information includes determining the migration second context in at least one of the following situations: the first context does not exist in the first data node; or, the first context does not exist in the first node; or, the first data node and the second data node are different; or, the first domain and the second domain are different, and the second domain is the domain where the second data node and the data management node are located, wherein the second data node is managed by the data management node.

[0016] Based on the above scheme, the first node can make a migration decision based on whether the first context exists in the data plane of the first domain, or whether the second data node obtained through the routing node is a local node, or whether the domain where the first context is located is the current domain. The migration decision combines multiple factors and can more accurately determine the necessity of context migration, thereby helping to reduce the signaling overhead caused by context migration.

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the second node is used for task orchestration of the first domain, and the second context includes: part or all of the public context belonging to the first domain in the first context; or, the second node is used for task orchestration, and the second node supports user context migration, and the second context includes: the user's context; or, the second node is used for mobility management, and the second context includes: the user's context; or, the second node is used for session management, and the second context includes: the session's context; or, the second node is used for providing services, and the second context includes: the service's context; or, the first information is also used to indicate context description information, and the context description information is used to indicate data type or service type, and the second context includes: part or all of the context in the first context that satisfies the context description information.

[0018] Based on the above scheme, the first node makes further selections on the context requested by the second node, including determining to migrate different contexts based on the different functions of the second node, or determining to migrate different contexts based on the different services of the second node, or determining to migrate contexts of specific data types or service types based on context description information. Therefore, it is possible to migrate contexts on demand, reduce unnecessary context transmission, reduce context transmission volume, thereby helping to reduce context transmission overhead and shorten the latency of context migration.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, migrating the second context includes: sending a second request to a second data node, the second request being used to obtain the second context, the second request carrying an identifier of the first context; and receiving the second context from the second data node.

[0020] Based on the above scheme, the second data node can identify which contexts need to be migrated and, through interaction between the first and second data nodes, migrate the context from the second domain to the first domain. The context migration process occurs between the two data planes, simplifying signaling interactions between the data plane and other network elements and reducing the complexity of other network elements.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, sending a second request to a second data node includes: sending a second request to a second data node via a routing node; or sending a second request to a second data node via a data management node.

[0022] Based on the above scheme, the first node can interact with the second data node through multiple paths for signaling or information transmission, which facilitates end-to-end transmission of context across different network architectures and communication paths. The transmission method using routing nodes simplifies the maintenance of routing information between different domains and saves routing resources. The transmission method using data management nodes simplifies signaling interaction between the data plane and other network elements, contributing to the security of data within the data plane.

[0023] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: obtaining an identifier of a second context, the identifier of the second context being used to indicate the second context, the identifier of the second context being assigned by the first node, the routing node, or the first data node.

[0024] Based on the above scheme, the context migrated to the first domain can obtain a new context identifier, thereby establishing a connection between the second context identifier and the second context, simplifying the instruction method in the subsequent processing of the second context. Furthermore, the network can be configured to assign context identifiers to specific nodes, which helps adapt to different scenarios or network architectures.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending the identifier of the second context and the second context to the first data node, the routing node, the second data node, the data management node, and / or the second node.

[0026] Based on the above scheme, the migrated context and context identifier can be transmitted to the data plane and consumer nodes in the first domain. During the current or subsequent task execution of the consumer nodes, the context can be obtained locally, which helps reduce signaling overhead and context acquisition latency. Furthermore, the migrated context and its identifier can also be transmitted to the data plane in the second domain, realizing information synchronization between the first and second domains, which is beneficial for business decision-making.

[0027] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending synchronization information to a second data node and / or a data management node, the synchronization information being used to indicate: when the second context in the first domain changes, the changed second context is sent to the second data node and / or the data management node; the synchronization information is used to indicate one or more of the following: the identifier of the first context, the identifier of the second context, the first data node, the information of the first node, or the type of the context to be synchronized.

[0028] Based on the above scheme, by indicating the information at both ends of the synchronization and the information of the context that needs to be synchronized, information synchronization between the data plane of the first domain and the data plane of the second domain can be achieved, which is helpful for business decision-making.

[0029] Secondly, a context transition method is provided, which can be applied to a second node, for example, a consumer node that can be used for task orchestration or business execution.

[0030] For example, the method includes: obtaining third information, the third information indicating: an identifier of a first context; requesting a first data management node to obtain the first context based on the third information; receiving a second context from the first data management node, the second context being a context in the first context, a context in the first domain where the second node is located, and / or a context that the second node can take over, and / or a context related to the functionality of the second node.

[0031] In conjunction with the second aspect, in some implementations of the second aspect, obtaining the third information includes: receiving a third request from a third node, the third request carrying the third information, and the third node being used to request the first context.

[0032] In conjunction with the second aspect, in some implementations of the second aspect, requesting the first context from the first data management node based on the third information includes: sending a first request to the first data management node, the first request being used to obtain the first context, and the first request carrying the identifier of the first context.

[0033] In conjunction with the second aspect, in some implementations of the second aspect, the first data management node belongs to the first domain, the first data management node is used to manage the first data node, the second context is obtained by the first data management node from the second data node, and the second data node belongs to the second domain.

[0034] In conjunction with the second aspect, in some implementations of the second aspect, the second node belongs to the first domain, and the second node or the third node is used for task orchestration in the first domain. The second context includes: part or all of the common context belonging to the first domain in the first context; or, the second node or the third node is used for task orchestration, and the second node supports user context migration. The second context includes: the user's context; or, the second node or the third node is used for mobility management, and the second context includes: the user's context; or, the second node or the third node is used for session management, and the second context includes: the session's context; or, the second node or the third node is used for providing services, and the second context includes: the service's context.

[0035] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: obtaining an identifier of the second context, the identifier of the second context being used to indicate the second context, the identifier of the second context being assigned by the first data management node or the first data node; and performing a task based on the identifier of the second context and the second context.

[0036] Thirdly, a context transition method is provided, which can be applied to a third node, for example, a consumer node that can be used for task orchestration or business execution.

[0037] For example, the method includes: obtaining fourth information, which is used to indicate the identifier of the first context and fifth information, which is used to indicate one or more of the following: the network element type or service type of the third node, the user's location information, the location information of the third node, or service deployment information, wherein the third node is used to request the first context, and the service deployment information is used to indicate the node supporting the service; and determining a migration second context based on the fourth information, wherein the second context is part or all of the first context.

[0038] Based on the above scheme, consumer nodes can make context migration decisions based on information such as function, location, service deployment, and context identifiers, enabling context migration to be performed on demand. This can better meet business needs, allowing consumer nodes to obtain context locally, reducing signaling overhead, and also reducing unnecessary context transmission, thereby reducing signaling overhead and resource waste caused by context migration.

[0039] In conjunction with the third aspect, some implementations of the third aspect further include obtaining the fourth information by: receiving a fourth request from a fifth node or a third node, wherein the fifth node is used for user access or signaling distribution, or the fifth node is a consumer node different from the third node, and the fourth request is used to obtain the first context; when the fourth request carries the identifier of the first context, the first context identifier is obtained according to the fourth request; or, when the fourth request carries a user identifier, the identifier of the first context is obtained according to the user identifier and the first mapping relationship, wherein the first mapping relationship is used to indicate the context identifier corresponding to the user identifier.

[0040] In conjunction with the third aspect, in some implementations of the third aspect, the migration second context is determined based on the fourth information, including: obtaining the location information of the second data node and / or the location information of the fourth node, wherein the second data node is used to store the first context and the fourth node is used to manage the second data node; and determining the user's cross-domain change and determining the migration second context based on the location information of the second data node, the location information of the fourth node, the user's location information, and / or the location information of the third node.

[0041] In conjunction with the third aspect, in some implementations of the third aspect, the third node belongs to the first domain, which also includes a first data node and a fourth node. The fourth node is used to manage the first data node. Determining the migration of the second context based on the fourth information also includes: obtaining first distribution information, which is used to indicate that the first context is stored in the second data node, and the second data node belongs to the second domain; determining the migration of the second context in at least one of the following situations: the first context does not exist in the first data node; or, the first context does not exist in the fourth node; or, the first data node and the second data node are different; or, the first domain and the second domain are different.

[0042] In conjunction with the third aspect, in some implementations of the third aspect, the migration of the second context is determined based on the fourth information, including: determining, based on the service deployment information, that the nodes in the first domain support the service corresponding to the second context; and determining the migration of the second context if the nodes in the first domain support the service corresponding to the second context.

[0043] In conjunction with the third aspect, in some implementations of the third aspect, the network element type or service type of the third node is a task orchestration network element, and the second context includes: part or all of the common context in the first context; or, the network element type or service type of the third node is a task orchestration network element, and the third node supports user context migration, and the second context includes: the user's context; or, the network element type or service type of the third node is a mobility management network element, and the second context includes: the user's context; or, the network element type or service type of the third node is a session management network element, and the second context includes: the session's context; or, the network element type or service type of the third node is a basic connectivity service, a sensing service, a computing power service, or an analytics service, and the second context includes: the service's context.

[0044] In conjunction with the third aspect, in some implementations of the third aspect, migrating the second context includes: sending a migration instruction to the fourth node, the migration instruction being used to instruct the fourth node to migrate the second context from the second data node to the first data node, the migration instruction carrying an identifier of the first context.

[0045] In conjunction with the third aspect, in some implementations of the third aspect, the second context is migrated from the second data node to the first data node through the routing node.

[0046] In conjunction with the third aspect, some implementations of the third aspect also include: obtaining the identifier of the second context, which is assigned by the fourth node, the routing node, or the first data node.

[0047] In conjunction with the third aspect, some implementations of the third aspect also include: sending the identifier of the second context and the second context to the access device, signaling distribution device, third node, or fifth node; and performing tasks based on the identifier of the second context and the second context.

[0048] Fourthly, a context transition method is provided, which can be applied to a fourth node, for example, the fourth node can be a data management node.

[0049] For example, the method includes: obtaining a migration instruction, the migration instruction indicating the migration of a second context from a second data node to a first data node, the second context being part or all of the first context; the migration instruction being obtained based on an identifier of the first context and fifth information, the fifth information indicating one or more of the following: a network element type or service type of a third node, user location information, location information of the third node, or service deployment information, the third node being used to request the first context, and the service deployment information indicating services supported by a node; and performing context migration according to the migration instruction.

[0050] Based on the above scheme, the data management node can perform specific context migrations according to the migration instruction information. This includes context migration based on the context identifier and other information in the migration instruction, such as service type, location information, and service deployment information. This allows the data management node to perform migration actions on demand. After context migration, consumer nodes can obtain the context locally, reducing signaling overhead and transmission latency. Furthermore, the data management node does not make migration decisions, which simplifies the data management node's processing mechanism and reduces information processing complexity.

[0051] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first data node belongs to the first domain, the migration indication includes the identifier of the first context, and the method further includes: sending the identifier of the first context to the routing node, the identifier of the first context being used by the routing node to obtain information of the second data node and / or information of the data management node according to the first distribution information, the data management node being used to manage the second data node, the first distribution information being used to indicate that the first context is distributed in the second data node; and receiving information of the second data node and / or information of the data management node.

[0052] In conjunction with the fourth aspect, some implementations of the fourth aspect also include: sending a sixth request to the second data node, the sixth request being used to request the acquisition of the second context, the sixth request carrying the identifier of the first context; and receiving the second context from the second data node.

[0053] In conjunction with the fourth aspect, in some implementations of the fourth aspect, a sixth request is sent to the second data node, including sending the sixth request to the second data node via a routing node.

[0054] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the third node is used for task orchestration, and the second context includes: part or all of the common context in the first context; or, the third node is used for task orchestration, and the third node supports user context migration, and the second context includes: the user's context; or, the third node is used for mobility management, and the second context includes: the user's context; or, the third node is used for session management, and the second context includes: the session's context; or, the third node is used for providing services, and the second context includes: the service's context.

[0055] In conjunction with the fourth aspect, some implementations of the fourth aspect also include: obtaining the identifier of the second context, which is assigned by the fourth node, the routing node, or the first data node; and sending the identifier of the second context and the second context to the first data node, the routing node, and / or the third node.

[0056] Fifthly, a communication device is provided. In one design, the device may include modules corresponding to the methods / operations / steps / actions described in the first aspect or any embodiment of the first aspect. These modules may be hardware circuits, software, or a combination of hardware circuits and software. In one design, the device includes: a transceiver unit for acquiring first information, the first information indicating: an identifier of a first context and an identifier of a second node, the second node requesting the first context. The device further includes: a processing unit for determining a second context to migrate based on the first information, the second context including the following contexts in the first context: a context in a first domain where the second node resides, and / or a context that the second node can take over, and / or a context related to the function of the second node.

[0057] In a sixth aspect, a communication device is provided. In one design, the device may include modules corresponding to the methods / operations / steps / actions described in the second aspect or any embodiment of the second aspect. These modules may be hardware circuits, software, or a combination of hardware circuits and software. In one design, the device includes: a transceiver unit configured to acquire third information indicating: an identifier of a first context; and to receive a second context from a first data management node, wherein the second context is a context supported by a first domain in which the second node resides, and / or a context that the second node can take over, and / or a context related to the functionality of the second node. The device further includes: a processing unit configured to request the first context from the first data management node based on the third information.

[0058] A seventh aspect provides a communication device. In one design, the device may include modules corresponding to the methods / operations / steps / actions described in the third aspect or any embodiment of the third aspect. These modules may be hardware circuits, software, or a combination of hardware circuits and software. In one design, the device includes: a transceiver unit configured to acquire fourth information, which indicates an identifier of a first context, and fifth information, which indicates one or more of the following: a network element type or service type of a third node, user location information, location information of the third node, or service deployment information. The third node requests the first context, and the service deployment information indicates nodes supporting the service. A processing unit configured to determine a second context to migrate based on the fourth information, wherein the second context is part or all of the first context.

[0059] Eighthly, a communication apparatus is provided. In one design, the apparatus may include modules corresponding to the methods / operations / steps / actions described in the fourth aspect or any embodiment of the fourth aspect. These modules may be hardware circuits, software, or a combination of hardware circuits and software. In one design, the apparatus includes: a transceiver unit configured to acquire a migration instruction, which indicates migrating a second context from a second data node to a first data node. The second context is part or all of the first context. The migration instruction is acquired based on an identifier of the first context and fifth information, which indicates one or more of the following: a network element type or service type of a third node, user location information, location information of the third node, or service deployment information. The third node requests the first context, and the service deployment information indicates the services supported by a node. A processing unit is configured to perform context migration according to the migration instruction.

[0060] A ninth aspect provides a communication device including a processor. The processor can implement the methods of the first to fourth aspects and any possible implementations thereof. Optionally, the communication device further includes a memory, and the processor is coupled to the memory and can be used to execute instructions in the memory to implement the methods of the first to fourth aspects and any possible implementations thereof. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface. In the embodiments of this application, the communication interface may be a transceiver, a pin, a circuit, a bus, a module, or other types of communication interface, and is not limited thereto.

[0061] In one implementation, the communication device is a communication equipment (such as a consumer node or a data management node). When the communication device is a communication equipment, the communication interface can be a transceiver, or an input / output interface.

[0062] In another implementation, the communication device is a chip configured within a communication device. When the communication device is a chip configured within a communication device, the communication interface can be an input / output interface.

[0063] Optionally, the transceiver can be a transceiver circuit. Optionally, the input / output interface can be an input / output circuit.

[0064] A tenth aspect provides a processor, comprising: an input circuit, an output circuit, and a processing circuit. The processing circuit is configured to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute the methods described in the first to fourth aspects and any possible implementation thereof.

[0065] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit can be, for example, but not limited to, output to and transmitted by a transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as both the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0066] Eleventhly, a computer program product is provided, comprising: a computer program (also referred to as code or instructions) that, when run, causes a computer to perform the methods described in the first to fourth aspects and any possible implementation thereof.

[0067] In a twelfth aspect, a computer-readable storage medium is provided that stores a computer program (also referred to as code or instructions) that, when executed on a computer, causes the computer to perform the methods described in the first to fourth aspects and any possible implementation thereof.

[0068] In a thirteenth aspect, a chip system is provided, which is applied to an electronic device. The chip system includes one or more processors, which are used to invoke computer instructions to cause the electronic device to perform the methods described in the first to fourth aspects and any possible implementation thereof.

[0069] In a fourteenth aspect, a communication system is provided, comprising at least one first node and at least one second node, or at least one third node and at least one fourth node. The first node can execute the method provided in any implementation of the first aspect; the second node can execute the method provided in any implementation of the second aspect; the third node can execute the method provided in any implementation of the third aspect; and the fourth node can execute the method provided in any implementation of the fourth aspect.

[0070] It should be understood that the beneficial effects of the features corresponding to the first aspect in the second to fourteenth aspects can be referred to the relevant description of the first aspect above, and will not be repeated here. Attached Figure Description

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

[0072] Figure 2 is a schematic diagram of a data plane functional structure provided in an embodiment of this application;

[0073] Figure 3 is a schematic diagram of a data plane data storage structure provided in an embodiment of this application;

[0074] Figure 4 is a schematic diagram of a context management method provided in an embodiment of this application;

[0075] Figure 5 is a schematic diagram of a context transition method provided in an embodiment of this application;

[0076] Figure 6 is a schematic diagram of another context transition method provided in an embodiment of this application;

[0077] Figure 7 is a schematic diagram of another context transfer method provided in an embodiment of this application;

[0078] Figure 8 is a schematic diagram of a specific implementation of context transfer provided in the embodiments of this application;

[0079] Figure 9 is a schematic diagram of another specific implementation of context transfer provided in the embodiments of this application;

[0080] Figure 10 is a schematic diagram of another specific implementation of context transfer provided in the embodiments of this application;

[0081] Figure 11 is a schematic diagram of a communication device provided in an embodiment of this application;

[0082] Figure 12 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0083] To facilitate understanding of the embodiments of this application, the following points will be explained first:

[0084] In this application, "instruction" can include direct instruction, indirect instruction, explicit instruction, and implicit instruction. When describing a certain instruction information for the purpose of instructing A, it can be understood that the instruction information carries A, directly instructs A, or indirectly instructs A.

[0085] In this application, " / " can indicate that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" can be used to describe three relationships between the related objects. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0086] In this application, "at least one" means one or more, and "more than one" means two or more, such as three, four, or more. Similar expressions (such as at least one, at least one, etc.) are used in the same way. "At least one of the following," "one or more of the following," or similar expressions refer to any combination of these items, which may include only a single item or a combination of multiple items. For example, at least one of a, b, or c can mean: a, or b, or c; a and b; or a and c; or b and c; or a, b, and c. Where a, b, and c can be single or multiple.

[0087] In this application, for the convenience of describing the technical solutions of the embodiments of this application, the terms "first" and "second" may be used to distinguish them. The terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0088] In this application, the words "exemplary," "example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "example," or "for example" should not be construed as being more preferred or advantageous than other embodiments or designs. The use of the words "exemplary," "example," or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0089] In this application, "sending information / data" only indicates the direction of information / data transmission, including direct transmission via the device's communication interface (such as an air interface, or simply air interface). "Sending" can also be understood as the "output" of a module interface. "Sending" can include indirect transmission by the processing unit through the communication interface, meaning that after the processing unit outputs information / data through the module interface, it is transmitted to the device's communication interface and then sent out. "Receiving information / data" only indicates the direction of information / data transmission, including direct reception via the communication interface. "Receiving" can also be understood as the "input" of a module interface. "Receiving information / data" can include indirect reception by the processing unit through the communication interface, meaning that after the communication interface receives information / data, it is transmitted to the processing unit's module interface and then input to the processing unit. "Sending information / data to… (such as a terminal)" can be understood as the destination of the information being the terminal. It can include sending information / data directly or indirectly to the terminal. "Receiving information / data from… (such as a terminal)" can be understood as the source of the information being the terminal, and can include receiving information / data directly or indirectly from the terminal. Information / data may undergo necessary processing, such as format changes, between the source and destination, but the destination can understand the valid information / data from the source. Similar statements in this application can be understood in a similar way, and will not be repeated here.

[0090] The technical solutions of this application can be applied to various communication systems, such as Long Term Evolution (LTE) systems, 5th Generation (5G) communication systems, satellite communication systems, Wireless Fidelity (WiFi) systems, and the solutions provided in this application can also be applied to future communication systems or other communication systems. This application does not limit these applications.

[0091] Figure 1 is a schematic diagram of the architecture of a communication system applicable to the context transition method provided in this application. Figure 1 shows a schematic diagram of a possible, non-limiting system architecture.

[0092] As shown in Figure 1, the communication system includes a radio access network (RAN) 10 and a core network (CN) 20. Optionally, the communication system also includes a data network (DN) 30. RAN 10 includes at least one RAN node and at least one terminal. RAN 10 may also include other RAN nodes, such as wireless relay equipment and / or wireless backhaul equipment, etc. The terminal connects to the RAN node wirelessly. The RAN node connects to the core network 20 wirelessly or via a wired connection. The core network equipment in the core network 20 and the RAN node in the RAN 10 can be different physical devices, or they can be the same physical device integrating core network logical functions and radio access network logical functions.

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

[0094] RAN nodes, sometimes also called access network equipment, access devices, RAN entities, or access nodes, are part of a communication system used to help terminals achieve wireless access. RAN nodes can be base stations, evolved NodeBs (eNodeBs), access points (APs), transmission and reception points (TRPs), next-generation NodeBs (gNBs), next-generation base stations in 6G mobile communication systems, base stations in future mobile communication systems, or access nodes in WiFi systems, etc.

[0095] In one possible scenario, multiple RAN nodes collaborate to assist a terminal in achieving wireless access, with each RAN node performing a portion of the base station's functions. For example, a RAN node can be a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU), etc. CUs and DUs can be configured separately or included within the same network element.

[0096] In one possible scenario, the RAN node in Figure 1 may also include a user plane function (UPF), which can provide routing and forwarding of user plane packets between the access device and the data network.

[0097] A terminal can also be called a terminal device, user equipment (UE), mobile station, mobile terminal, etc. Terminals can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, etc. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, etc.

[0098] Core network equipment can provide a variety of functions, including signaling distribution function (SDF), task-centric function (TCF), and other network functions (NF) or services.

[0099] A function in a core network device can be implemented through a logical function of a physical device or through a single physical device. A physical entity that can perform a network function through multiple logical functions can also be called a network element or node.

[0100] SDF network elements can maintain signaling routing-related state information to provide signaling offloading functions to terminals and core network elements. Specifically, this includes, but is not limited to, the following functions:

[0101] 1. Signaling transmission between the UE and the access and mobility management function (AMF) may include centralized forwarding of non-access-stratum (NAS) messages and allocation of a globally unique AMF identifier (GUAMI).

[0102] 2. Signaling transmission between access devices and AMF: Used to transmit radio bearer control information from the core network side to the RAN, which may include centralized forwarding of application protocol (AP) messages, application link management, device or network element level AP message endpoints, and allocation of AP UE identifiers (IDs).

[0103] 3. Signaling transmission between the Session Management Function (SMF) and the UPF is used to exchange information between the control plane and the user plane. This includes the distribution of forwarding rules, QoS control rules, and traffic calculation rules from the control plane to the user plane, as well as the reporting of information from the user plane. Examples include centralized forwarding of Packet Forwarding Control Protocol (PFCP) messages, link management, and device-level PFCP message endpoints.

[0104] 4. Network element selection: The TCF issues logical network element information, and the SDF selects the physical instance of the network element.

[0105] The TCF (Transmission over CF) element is responsible for task orchestration based on request messages and completing the tasks corresponding to the request messages, such as session management tasks, by calling the business capabilities provided by NF / Services. Because TCF has frequent interaction requirements, it can be designed to be stateful or have time-sensitive states. For example, TCF can store state information or obtain context from the data plane.

[0106] Network functions (NFs) refer to functional modules, devices, or network elements in the core network that perform specific tasks or operations. Examples include SMFs, AMFs, application functions (AFs), unified data management functions (UDMs), and authentication server functions (AUSFs). Network functions are the foundation for implementing and supporting services.

[0107] A service refers to a function or capability provided to a user or other system, such as mobility services, subscription services, security services, or policy services. A service is typically provided by multiple network functions working together. For example, in a 5G network, voice call services may require the support of mobility management, session management, and data management functions.

[0108] NF / servics can be stateless, and do not need to store user / session-related context locally. They only need to perform task processing based on task requests and / or context obtained from the data plane.

[0109] Core network equipment can also provide data plane functionality. Data plane functionality is used to store the context, helping to achieve a stateless architecture, reducing coupling between service nodes, and thus enabling service nodes to independently perform operations such as upgrades.

[0110] In the embodiments of this application, the terminal, access network device and core network device can be hardware devices, or software functions running on dedicated hardware. Software functions running on general-purpose hardware, such as virtualization functions instantiated on a platform (e.g., cloud platform), or entities that include dedicated or general-purpose hardware devices and software functions, are not limited in the specific form of the terminal, access network device and core network device.

[0111] The stateless communication architecture provided in this application embodiment enables unified control of network services, reduces contextual coupling between different functions or services, and facilitates network function expansion.

[0112] To better understand the methods provided in the embodiments of this application, the terms involved in the embodiments of this application will be briefly explained below.

[0113] 1. Context

[0114] In communication networks, context typically refers to a set of state information associated with a specific session, connection, or user. This information is used to manage and maintain the state of network connections and ensure that data can be transmitted and processed correctly. Context may contain different content at different network layers and functions, and may include, for example, the following aspects:

[0115] User context (or UE context) can include user identifiers (such as International Mobile Subscriber Identity (IMSI) and International Mobile Equipment Identity (IMEI)), subscription information (such as service packages and permissions), location information (such as the currently connected base station), and service configurations and permissions. This information is used to identify and verify the user's identity.

[0116] Session context can include session indication information (such as session ID), IP address information (such as the IP address assigned to the user device), session state (such as active or deactivated), QoS parameters, and IP address and port information of the data stream, to ensure the correct establishment and maintenance of data sessions.

[0117] In 5G networks, the connection session used to describe the connection between user equipment and the data network can be called a protocol data unit session (PDU session). The PDU session is responsible for managing and transmitting user data and supports different types of traffic, such as IP and non-IP data.

[0118] Connection context: can include connection identifiers (such as connection ID), connection status (such as established, disconnected), transport layer information, such as channel configuration and resource allocation (such as TCP / UDP port numbers), encryption and integrity protection information, as well as cell information and handover parameters, supporting the establishment and management of wireless connections.

[0119] Policy and charging context: The policy and charging context includes policy control rules, such as QoS parameters (e.g., bandwidth, latency, priority), charging rules and parameters (e.g., flow identification based on 5-tuples), data flow priorities, and charging identifiers and information, used to manage quality of service and charging.

[0120] Network context can include network topology information (such as routing paths), routing information, network node identifiers (such as eNodeB ID, Serving General Packet Radio Service Support Node (SGSN) ID), and network status (load and congestion status), as well as service function chain information (such as the order of network functions) to help optimize the use of network resources.

[0121] Security context: This involves encryption keys and algorithms, integrity protection keys, security protocol versions, and security policies and configurations to ensure the confidentiality and integrity of communications.

[0122] The aforementioned session context, connection context, network context, and security context can be used for specific services and can also be called service context. The system may also contain other contexts, which are passed and shared between network nodes to support user mobility, quality of service, and security, as well as to enable effective resource management, traffic control, and quality of service assurance.

[0123] 2. Consumption Nodes

[0124] In this embodiment, a service provided by one node is used by another node, and the node using the service is called a consumer node. For example, the services provided by the data plane include context creation, retrieval, and updating. These services can be used by SMF, AMF, and AF, etc., and SMF, AMF, and AF, etc., can be called consumer nodes. A consumer node can directly or indirectly request the context it needs from the data plane, or it can directly or indirectly receive the context provided by the data plane.

[0125] Consumer nodes can also be TCFs. After receiving request messages, they can combine the data plane context to perform task orchestration, invoke various services, and instruct each network element to perform corresponding tasks to realize the service.

[0126] In addition to the functions and names listed above, the consumer node in this application embodiment can also be any node or network function that needs to call the context. This application embodiment does not limit the specific functions and names of the consumer node.

[0127] 3. Cross-domain changes

[0128] Cross-domain changes of a terminal device refer to the movement of a terminal device from one core network service area to another, requiring the use of network elements in the new network to complete business operations. The service area of ​​a core network can be called a network domain or simply a domain. Specifically, this process can be based on network domains defined by physical service areas, such as central networks and edge networks, or on logical areas (such as user scope, service scope, access standards (e.g., 4G, 5G, 6G, or terrestrial mobile access, satellite access)). For example, a public network and a dedicated network for users within a campus may coexist. The communication network in this embodiment includes multiple network domains. For instance, Figure 1 includes domain 1 and domain 2, where domain 1 can be the service area of ​​a public network, and domain 2 can be the service area of ​​a dedicated network (e.g., an enterprise private network).

[0129] Cross-domain change refers to a terminal device moving from a first domain to a second domain. For example, the first domain can be domain 1 of the public network in Figure 1, and the second domain can be domain 2 of the private network in Figure 1; or, the first domain can be the service area of ​​a public network, and the second domain can be the service area of ​​another public network; or, the first domain can be the service area of ​​a private network, and the second domain can be the service area of ​​another private network.

[0130] Cross-domain changes may also occur when a network element malfunctions, resulting in a network element switchover. The new network element is in another domain, requiring the terminal to complete its business through the new network element.

[0131] In the stateless architecture shown in Figure 1, when a terminal undergoes cross-domain changes (such as node failure or terminal movement), the context is still stored in the original data plane. The new terminal and consumer node need to obtain it from the original data plane. This context acquisition process is cumbersome and results in high signaling overhead in the network.

[0132] One possible approach is for the new terminal or consumer node to trigger the system to migrate the context from the original data plane to the new data plane, migrating the user context based on the user identifier. However, when a terminal changes across domains, it may not be necessary to migrate all contexts in some cases, such as when the new side does not support certain services. Migrating all user contexts based on the user identifier could actually cause service interruption.

[0133] In view of this, embodiments of this application provide a context migration method, which enables the network to migrate the context as needed after a terminal crosses domains, so that the service on the new side can obtain the relevant context in the local data plane, thereby reducing signaling overhead.

[0134] To enable context migration between data planes in different domains, embodiments of this application further refine the data plane functionality. Figure 2 is a schematic diagram of the data plane functionality, including a data management function (DMF) and a data storage function (DSF).

[0135] The DMF (Data Context Management Provider) is used to maintain the context, supporting context-based management requests and performing operations such as adding, deleting, modifying, and querying data within the context, like updating specific parameters or returning the requested target context. The DSF (Data Context Storage Provider) is used to store the context, acting as a storage node for the data plane and providing context storage capabilities.

[0136] In some cases, data plane functions can also include routing management functions (RMF). As a routing node, the RMF provides intra-domain / inter-domain routing capabilities to data plane nodes. For example, when there are multiple RMFs within a domain or multiple domains in a network, routing information can be synchronized through the interconnection interface between RMFs.

[0137] Context routing management can be implemented by the SDF (Software Provider Function), meaning that service requests sent by the NF (Network Element) can be forwarded to the target DMF (Data Plane Element) by the SDF in conjunction with routing information. Context routing management can also be implemented by the RMF (Resource Provider Function) within the data plane, or it can directly forward requests to the nearest DMF, which then completes signaling routing through interaction with the RMF. Network elements or data plane nodes between different domains can achieve signaling interaction through one or more SDFs or RMFs.

[0138] In this embodiment, a DMF can manage one or more DSFs, and a DSF may also be managed by multiple DMFs. The DMFs, DSFs, and / or RMFs in the data plane function can provide services externally as a whole node, or they can provide services internally / externally according to their respective logical functions.

[0139] Through the data plane architecture described above, the data plane can interact with other nodes in the network, such as consumer nodes, through management functions, and can also interact with other data planes through routing management functions, thereby enabling the storage, management and / or routing of contexts within the data plane.

[0140] The context in the data plane can be categorized and stored as public data and service data, using different identifiers for indication. Public data can include user-level context, user location information, or session lists, while service data can include session information, quality of service information, network element type, or service type.

[0141] Public data can be combined with multiple different service data to jointly complete specific tasks. As shown in Figure 3, the Domain 1 data plane includes Service 1 data, Service 2 data, Service 3 data, and public data. Domain 1 supports Service 1, Service 2, and Service 3. The context required by Service 1 when performing a specific task includes public data and Service 1 data; the context required by Service 2 when performing a specific task includes Service 2 data; and the context required by Service 3 when performing a specific task includes public data and Service 3 data. The Domain 2 data plane includes Service 4 data and public data. The context required by Service 4 when performing a specific task includes both public data and Service 4 data.

[0142] The public data in the data plane can also be called the public context, and the service data can also be called the service context.

[0143] In addition, from the user's perspective, the context required to execute a user's business in the data plane can also be called the user context. The user context can include the public context and service context related to that user.

[0144] The data plane may also include a context identifier, which indicates the specific context. One possible approach is that the context identifier can be associated with a user identifier, and also with the function instance, session, and / or connection to which the context identifier is assigned. Another possible approach is that the network can configure a context identifier segment based on the function instance to which the context identifier is assigned, pre-allocating the context identifier in the corresponding context identifier segment. Yet another possible approach is that the network can assign temporary identifiers to the context regardless of the function instance.

[0145] For example, Table 1 shows one possible format of the context stored in the data plane, and the context format shown in Table 1 can be called format one.

[0146] The context data ID is a context identifier that can be associated with one or more identifiers in the ID Context of the public data.

[0147] The public data in the context may include one or more of the following: ID Context, RAN Context, user-level Context, or event notification Context.

[0148] The ID Context can include user identifiers, notification-associated identifiers, session information, etc. For example, the user identifier can be a subscriber permanent identifier (SUPI), a globally unique temporary identifier (GUTI), or a generic public subscription identifier (GPSI). The ID Context can also include session-related information, such as a list of PDU session IDs.

[0149] RAN Context can include the identifier of the RAN node. RAN Context can also include information about other RAN nodes, such as the Next Generation Application Protocol (NGAP) ID, or base station type, base station location, or cell information.

[0150] User-level context can include data related to user mobility management (MM), policy management (PM), charging, subscription data management, subscription data, and capability exposure.

[0151] An event notification context is used to process and deliver information and status related to event notifications. An event notification context can include one or more of the following: event source, event type, event target, additional information, or processing logic. The event source indicates the entity or system component that generated the event; the event type indicates the nature or category; the event target indicates the entity or system component; and the processing logic describes how to handle the received event notification.

[0152] Service data in the context can include data from multiple different services, such as session management data related to sessions (e.g., PDU Session ID), policy management data (e.g., QoS Flow ID), billing data, subscription data, or capability exposure data. It can also include data from other service types, such as data from sensing, computing, intelligence, and twin services.

[0153] In some cases, a session context can also serve as a service context.

[0154] Optionally, the context may include data synchronization information to indicate that data between different data planes needs to be synchronized. For example, if a user's services are partially in domain 1 and partially in domain 2, billing services require the accumulation of billing-related data from both domains 1 and 2 to obtain complete billing information. To achieve data synchronization, the data synchronization information may include information about the other node that is synchronized with the current node (such as the node's identifier or address). The data synchronization information may also include synchronization instructions, which can be data types that need to be synchronized or not, or partial context of public data or service data that needs to be synchronized or not.

[0155] Table 1

[0156] In the context format shown in Table 1, the context identifier can indicate the public context and the service context. Consumer nodes can obtain the full context corresponding to the context identifier, or they can obtain a portion of the context by combining other context description information, such as service type, data type, user-related information, PDU session list, or data filter conditions.

[0157] Service types can include basic connectivity services, sensing services, computing power services, analysis services, and other network capability information.

[0158] Data types can be public data, service data, or specific data types within public / service data, such as billing data, policy data, session data, etc.

[0159] User-related information can include the user's location, access standard, access technology, etc.

[0160] Data filtering criteria can include session identifiers (such as PDU Session ID), quality of service identifiers (such as QoS ID), and data flow identifiers (such as QoS Flow ID).

[0161] For example, the context identifier `context data A` indicates a user's context, which can be called context A. This includes the public context and the contexts of services 1, 2, 3, and 4. If service 1 corresponds to a service-aware service, service 2 corresponds to a data type of billing data, service 3 corresponds to a data type of policy data, and service 4 corresponds to a data type of session data, then the consumer node can combine `context data A` with the data type and / or service type to obtain a portion of the context. For example, if the data type is policy data, then the consumer node can combine `context data A` with the data type "policy data" to obtain the context related to service 3.

[0162] For example, Table 2 shows another possible format for the context stored in the data plane, which can be called format two.

[0163] Table 2

[0164] In the context format shown in Table 2, the context identifier can indicate the data type or service type of the context. For example, if the data type is public data, the context identifier can indicate a public context; if the data type is service data, the context identifier can indicate a service context. Alternatively, if the data type is divided into billing data, policy data, session data, mobility management data, etc., then the context identifier can indicate a billing context, policy context, or session context.

[0165] In this context format, the consumer node can obtain the user's context through multiple context identifiers. For example, if the consumer node needs to perform billing and session-related services, it can obtain the corresponding context through the identifiers of the billing context, session context, and optionally public context.

[0166] Optionally, the service context identifier can be an internal identifier within the core network domain or an external identifier outside the core network (such as a third-party application), and can be used as an external routing index.

[0167] For example, context data 1 is a public context identifier, and context data 2, context data 3, and context data 4 are service context identifiers, indicating the contexts of services 2, 3, and 4, respectively. If a consumer node needs to obtain the context of service 3, it can do so through context identifier context data 3.

[0168] In this embodiment, Tables 1 and 2 are merely examples of possible forms of data structure in the data plane. In actual applications, other structures may exist, and the information contained therein may also differ. They should not be constrained by the embodiments of this application.

[0169] The following description, in conjunction with Figure 4, illustrates a context management method for a stateless communication architecture, which includes the data plane functional structure shown in Figure 2. The method 400 shown in Figure 4 may include steps 401 to 406, and each step in method 400 will be described in detail below.

[0170] 401. The consumer node sends a context management request to the data management node.

[0171] Context management requests can be used to create, query, retrieve, or update contexts.

[0172] For example, during user registration, a context management request is used to create a user context, which can be called a context request or context creation request. The context creation request can carry user information, such as user identifier, session identifier, or network element identifier.

[0173] For example, when confirming whether a data plane supports a certain service or function, a context management request can be used to query whether the corresponding context exists. A context management request can be called a context query request. A context query request can carry information such as user information, context identifiers, or service types.

[0174] For example, if a consumer node needs to use a context to execute a task, it can obtain the corresponding context through a context management request. A context management request can be called a context request or a context retrieval request. The context management request can contain a context identifier and can also carry other context indication information, such as service type, to indicate the context required by the consumer node.

[0175] When the context changes, the context in the data plane can be updated through a context management request.

[0176] The aforementioned context management request can be sent not only by the consumer node (such as TCF or SMF), but also by the terminal, RAN node, or second consumer node, or it can be sent by the terminal, RAN node, or second consumer node to the consumer node and then forwarded to the data management node through the consumer node. The terminal, RAN node, or second consumer node sending the context management request can belong to the same domain or different domains as the consumer nodes.

[0177] 402. Context addressing is performed between the data management node and the routing node.

[0178] Data management nodes (such as DMF) send addressing requests to routing nodes (such as RMF or SDF), carrying a context identifier. The routing node can store the address of the data node corresponding to the context identifier, thus allowing it to retrieve the data node containing the context.

[0179] Alternatively, the routing node can store the correspondence between the data management node and the data node, and this correspondence can be used to determine the data node where the context resides.

[0180] The routing node sends the information of the data node containing the context to the data management node.

[0181] In one scenario, the data management node addressing process involves multiple cascaded routing nodes. In this case, the data node can be ultimately determined through the nearest routing node and the cascading mechanism with other routing nodes.

[0182] In this embodiment, this step is optional. If the corresponding context already exists in the data management node during the context query and retrieval process, context addressing can be omitted. Alternatively, if the data management node stores the information of the corresponding data node, context addressing can also be omitted.

[0183] 403. Context management is performed between data management nodes and data nodes.

[0184] If the context management request is used to create a context, the data management node can generate a context for the user based on information such as the user identifier, including assigning a context identifier. The data management node then sends the generated context to the data nodes for storage. Alternatively, the data management node may not assign a context identifier; instead, the data nodes, upon receiving the context-related data for the user, will assign a context identifier and store the context.

[0185] If a context management request is used to query, retrieve, or update a context, the data management node can send a context identifier to the data node to query, retrieve, or update the context corresponding to that context identifier.

[0186] The storage of context in data nodes can refer to the data structure shown in Figure 3. The specific context format can be found in the detailed descriptions in Table 1 or Table 2, which will not be elaborated here.

[0187] After processing the context, the data node can send the requested context to the data management node. For example, when requesting to retrieve a context, the data node sends the context identifier corresponding to the context to the data management node. Similarly, when creating a context, the data node sends the assigned context identifier to the data management node. Finally, it sends the corresponding processing results to the data management node, such as whether the query was successful or whether the context creation was successful.

[0188] Data management nodes and data nodes can interact through request and response messages.

[0189] 404. The data management node sends a context management response to the consumer node.

[0190] The context management response and the context management request in step 401 can be a message pair used to send the processing result of the context management request.

[0191] For example, Table 3 shows the information that may be included in the request and response messages for different context management actions.

[0192] Table 3

[0193] Optionally, the consumer node may also send a context management response to the terminal, RAN node, or second consumer node, carrying the information requested by the terminal, RAN node, or second consumer node, or the corresponding request result.

[0194] 405. Data management nodes and routing nodes interact to perform context storage / association.

[0195] During or after the execution of context management, the data management node performs context storage or association. This includes storing the data management node, data nodes, and / or context identifiers, or establishing a mapping between data management nodes and data nodes, a mapping between context identifiers and data planes (DMF and / or DSF), and / or a mapping between context and context identifiers. These mappings can be used for context addressing or context management.

[0196] This step is optional; the data management node can decide whether to execute it. For example, if the data management node obtains a new data node during context creation, it needs to store that data node, along with the mapping between the data management node and the data node, and the mapping between the context identifier and the data node, in the routing node. If the routing information does not change during context querying or retrieval, this step is not required.

[0197] The context management method shown in Method 400 supports context management by separating management, storage, and routing functions within the data plane. Interaction between the data plane and consumer nodes in the core network can be achieved through the data management node, while storage and routing functions can be omitted from the consumer nodes. This avoids the complexity of interaction caused by the coupling of data plane functions, simplifies the interaction process between the data plane and consumer nodes during context management, and reduces signaling overhead.

[0198] The functional nodes involved in the above context management methods can belong to the same core network service area. When a user is within this core network service area, the data plane within that service area can store and manage the context. Consumer nodes can then request context management, such as retrieving the context, and execute tasks based on that context.

[0199] In some situations, such as user migration or partial node failure, when some or all of a user's services need to be migrated to a different core network service area, the corresponding context needs to be migrated from one domain to another. The network domain where the user is currently located can be referred to as the first domain, and the network domain where the user was located before migration can be referred to as the second domain. The context migration method provided by the embodiments of this application will be described in detail below with reference to Figures 5 to 7.

[0200] Figure 5 illustrates a context transfer method, including steps 501 to 503, which will be described in detail below.

[0201] 501. The second node indicates the first information to the first node. Accordingly, the first node obtains the first information.

[0202] In this embodiment, the first node and the second node belong to the first domain. The first node can be a first data management node in the first domain, and the second node can be a consumer node in the first domain, such as a task center function node or other consumer node.

[0203] In this embodiment of the application, the first information is used to indicate: the identifier of the first context and the identifier of the second node, and the second node is used to request the first context.

[0204] The first context identifier is used to indicate the context identifier that the second node expects to obtain. This first context identifier may be assigned by a node in the second domain where the user was before moving. The first context identifier may be one or more context identifiers. The specific form of the context identifier can be found in the detailed explanation above, and will not be repeated here.

[0205] The identifier of the second node is used to indicate the second node. It can be the node name or number, etc. The identifier of the second node can also indicate the type, function or address information of the second node.

[0206] The second node may indicate the first information to the first node by sending a first request to the first node, the first request carrying the identifier of the first context and / or the identifier information and / or the address information of the second node. Accordingly, the first node receives the first request from the second node.

[0207] For example, the first request may be a context management request (such as a context fetch request, a context update request, etc.) to obtain the first context.

[0208] If the context identifier indicated by the first information adopts format two, for example, the first request carries the identifiers of the first context: context data1, context data2, context data3, and context data4, where context data1 is used to indicate the public context, context data2 is used to indicate the mobility management context, context data3 is used to indicate the session context, and context data4 is used to indicate the authentication service context.

[0209] If the context identifier indicated by the first information adopts format one, for example, the first request carries the identifiers context data A and context data B for the first context, where context data A indicates the context of user A and context data B indicates the context of user B. The consumer node can obtain the complete context of user A based on context data A.

[0210] In some cases, if the context identifier uses Format 1, the first information can also indicate context description information. Accordingly, the first request can also carry context description information, indicating the specific service type or data type, so that the consumer node can obtain specific type of service data (such as session, mobility management, billing, or authentication) from context data A.

[0211] The method for obtaining the identifier of the first context in the first request sent by the second node can be as follows: The second node receives a third request from other nodes in the first domain besides itself. The third request carries third information, and the identifier of the first context is obtained based on the third information. For example, the second node is a task center functional node, and the other nodes are consumer nodes (such as SMF or AMF). The consumer nodes send a third request (such as a context retrieval request) to the task center functional node, carrying the identifier of the first context in the third request. For example, the identifier of the first context includes context data 1, context data 2, context data 3, and context data 4, thereby enabling the second node to obtain the identifier of the first context.

[0212] In some cases, such as when the context identifier uses format one, the third request can also carry context description information. The second node can send the obtained first context identifier and context identifier information to the first node.

[0213] The third information may also include user location information, network deployment information, etc., which are used by the first node to make decisions on context migration in subsequent steps.

[0214] 502. The first node determines the migration of the second context based on the first information. The second context is the context supported in the first domain where the second node is located, and / or the context that the second node can take over, and / or the context related to the functionality of the second node.

[0215] The first node determines whether to migrate the second context based on the first information, including: the first node determines whether to migrate the context and determines the context to be migrated (which can be called the second context). Alternatively, the first node can determine whether to migrate the context based on the first information by obtaining the second information and then determining the second context to migrate based on both the first and second information.

[0216] The second information can indicate the first data node, which stores the context within the first domain. The first data node belongs to the first domain, and the first data management node can manage the context within it. For example, the first data node could be a DSF (Data Provider Function) within the first domain, and the DSF can be managed by a DMF (Data Management Function). The second information can be the DSF's identification information or address information.

[0217] The second information can be obtained by sending the identifier of the first context to the routing node. The routing node includes first distribution information, which indicates that the first context is distributed across the second data nodes. For example, the first distribution information may include the correspondence between context identifiers and data nodes. Based on the context identifier and the first distribution information, the routing node can obtain information about the data node (second data node) where the first context resides, such as the identifier or location information of the second data node. The routing node sends the information about the second data node to the first node, and correspondingly, the first node receives the second information from the routing node.

[0218] Therefore, the first node can determine whether to migrate the second context based on one or more of the following conditions:

[0219] Condition 1: The first context does not exist in the first data node;

[0220] Condition 2: The first node does not contain a first context;

[0221] Condition 3: The first data node and the second data node are different;

[0222] Condition 4: The first domain and the second domain are different.

[0223] The first node's determination of the context to be migrated (the second context) may be related to the type or function of the second node (the first consumer node in the first domain). For example, if the context node adopts format one, the second context can also be determined in conjunction with context description information (such as data type). If the first consumer node is used for task orchestration in the first domain, then the second context may include: part or all of the public context belonging to the first domain within the first context, such as the public context with data type public data in context data A; or, if the first consumer node is used for task orchestration and supports user context migration, the second context may include all contexts in context data A or the user context; or, if the first consumer node is used for mobility management, the second context may include all contexts in context data A, or a mobility management context with data type mobility management; or, if the first consumer node is used for session management, the second context may include a session context with data type session data in context data A.

[0224] For example, if the context node adopts format two, and the first consumer node is used for task orchestration in the first domain, then the second context may include: a public context belonging to the first domain in the first context, such as context data 1; or, if the first consumer node is used for task orchestration and supports user context migration, the second context may include the user's context, such as context data 1, context data 2, context data 3, and context data 4; or, if the first consumer node is used for mobility management, the second context may include the user's context, such as context data 2; or, if the first consumer node is used for session management, the second context may include the session's context, such as context data 3; or, if the first consumer node is used to provide authentication services, the second context may include the authentication service's context, such as context data 4.

[0225] The service or function description of the first consumer node can be found in the detailed description in the aforementioned communication structure, and the specific format of the context can be found in the aforementioned description of the context, which will not be repeated here.

[0226] The migration decision also requires consideration of whether the context to be migrated can be supported in the first domain, or whether the second node can take over it. Only contexts supported by the first domain and manageable by the second node can be migrated.

[0227] In some cases, the first node can obtain its own or other network elements' capability information within the first domain through pre-configuration or capability querying. This capability information can indicate whether network elements in the first domain support the first context. For example, if no authentication service is deployed in the first domain, but the first context is an authentication context, then it can be determined that the first domain does not support this context, and migration is not possible. Alternatively, the pre-configuration information in the first node indicates supported or unsupported context identifiers or identifier segments, etc., allowing the first node to determine whether the first domain supports or does not support the context. If the first domain supports it, the first node can determine to migrate the second context.

[0228] In some cases, the first node can obtain information such as the context types and service types supported by the second node through pre-configuration or capability queries, and determine whether the second node can take over the context. Alternatively, the second node can carry corresponding indications of whether it can or cannot take over the context in its second request, or it can assume that the second node can take over the context upon receiving the first request from the second node. If the first node confirms that the second node can take over the second context, it will determine to migrate the second context.

[0229] The first node sends a second request to the second data node. This second request is used to obtain a second context, and it may carry an identifier of the first context. The second request can be a context management request. Correspondingly, the first node receives the second context from the second data node.

[0230] During the second context migration process or after acquiring the second context, the first node can assign a corresponding identifier to the second context. In some cases, the identifier of the second context can also be assigned by the first data node or the routing node.

[0231] For example, if the context identifier adopts format two, the obtained second context includes the contexts identified as context data1, context data2, and context data3 in the first field. After obtaining the corresponding contexts, the data management node assigns the identifiers context data5, context data6, and context data7 to the second context, respectively, where context data5 corresponds to context data1, context data6 corresponds to context data2, and context data7 corresponds to context data3. If the context adopts format one, the obtained context can be part or all of context data C, corresponding to part or all of context data A, which is related to the context description information used when determining the second context.

[0232] 503. The first node sends the second context to the second node. Correspondingly, the second node receives the second context from the first node.

[0233] The first node can send a second context to the second node through a context management response. The context management response may also include the identifier of the second context in the first domain (the identifier of the second context), context data 5, context data 6, and context data 7. This context management response may be related to the context management request in step 502.

[0234] In some cases, the first node can also send the identifier of the second context in the second domain (the identifier of the first context) to the second node.

[0235] In some cases, the first node can also send the results of context management requests to the second node. For example, a successful request for context data 1, context data 2, and context data 3, but a failed request for context data 4.

[0236] For example, the context identifiers for the second context in the second domain include context data 1, context data 2, and context data 3, while the context identifiers in the first domain correspond to context data 5, context data 6, and context data 7, respectively. Upon receiving the context identifiers from both the first and second domains, the second node replaces context data 1 with context data 5, context data 2 with context data 6, and context data 3 with context data 7. The new context identifiers indicate the second context.

[0237] The above explanation of the context refers to the case corresponding to format two. When the context identifier uses format one, for example, the second node obtains the context identifier of the first field as context data B, corresponding to the context identifier of the second field as context data A. After receiving the corresponding identifier, it replaces context data A with context data B, and uses context data B to indicate the second context. The corresponding message (such as context management request / response) can carry or the context can contain context description information.

[0238] After completing the context migration, the second node can execute tasks based on the second context and its identifier. For example, if the second node is a task center function node that orchestrates tasks, including session management, then the task center function node can issue new context identifiers related to session management, such as context data 7.

[0239] In the above method, the form of the identifier of the first context or the second context can be referred to the previous explanation of context identifiers, and will not be repeated here.

[0240] In the context migration method shown in Figure 5, the first data management node decides whether to perform migration and determines the context to be migrated based on the acquired first information, and obtains the context to be migrated from the second data node. In this embodiment of the application, the data plane can perform on-demand context migration based on the first information. Furthermore, by making migration decisions and executing migration actions through the data plane, the signaling interaction between the consumer node and the data plane can be simplified, reducing the complexity of context migration.

[0241] Figure 6 illustrates another method for context transfer, including steps 601 to 604. The method of this application embodiment will be described in detail below with reference to Figure 6.

[0242] 601. The third node obtains fourth information, which is used to indicate the identifier of the first context and fifth information. The fifth information is used to indicate one or more of the following: the network element / service type of the third node, the user's location information, the location information of the third node, or service deployment information. The third node is used to request the first context, and the service deployment information is used to indicate the node supporting the service.

[0243] The third node can be a consumer node in the first domain, such as a task center functional node or other consumer node, and can be called the first consumer node, used to request the first context. The fifth information can also indicate the network element / service type and location information of other consumer nodes besides the third node.

[0244] The network element / service type and user location information of the third node can be referred to the description in the foregoing embodiments. Service deployment information can indicate the nodes that support the service. Service deployment information can indicate that a certain service is deployed in a specific network domain or a specific node, or that a certain network domain or a certain node supports a specific service.

[0245] The third node can obtain the fourth information by receiving a fourth request from the fifth node. The fourth request can carry the identifier of the first context and the fifth information.

[0246] The fourth request can be a context management request to obtain the first context. The fifth node can be a user access node (such as a RAN node) or a signaling distribution node (such as an SDF), or the fifth node can be a consumer node other than the first consumer node.

[0247] In some cases, the fourth request may carry a user identifier, and a first mapping relationship exists in the third node. This first mapping relationship indicates the context identifier corresponding to the user identifier. After receiving the user identifier, the third node can obtain the first context identifier by combining it with the first mapping relationship.

[0248] 602. The third node determines the second context for migration based on the fourth information. The second context is part or all of the first context.

[0249] The third node determines the migration of the second context based on the fourth information, including: determining whether to migrate the second context and what information the second context to migrate includes.

[0250] One way to determine whether to migrate the second context is based on information from each location.

[0251] The third node's determination of the migration of the second context based on the fourth information also includes: obtaining the location information of the second data node and / or the location information of the second data management node. The second data node is the node that stores the first context, and the second data management node can manage the second data node. The second data node belongs to the second domain, which can be the domain where the user was before the migration. The third node compares the location information of the second data node and / or the location information of the second data management node with the user's location information and / or the location information of the first consumer node to determine whether the user has undergone a cross-domain change, and if not, whether to migrate the second context.

[0252] Another way to determine whether to migrate the second context is to judge whether there is a corresponding second context in the data plane of the first domain where the current user is located.

[0253] The first consumer node belongs to the first domain. The data plane within the first domain includes the first data node and the first data management node, which manages the first data node. To determine whether a second context exists in the current data plane, the third node can obtain first distribution information from the routing node, the first data node, or the first data management node. This first distribution information indicates that the data node for the second context is the second data node. If the first data node does not contain a second context, or the first data management node does not contain a second context, or the first data node and the second data node are different, or the first domain and the second domain are different, then the third node can determine to migrate the second context. If the second context exists in the data plane of the first domain, then migration of the second context is not necessary.

[0254] Another way to determine whether to migrate the second context is to determine whether the nodes in the first domain support the service corresponding to the second context based on the service deployment information. If the nodes in the first domain support the service corresponding to the second context, the third node can determine to migrate the second context.

[0255] The above methods for determining whether to migrate the second context can be singular, such as judging whether to migrate based solely on location-related information, or a combination of multiple methods, such as simultaneously judging whether migration is supported based on location information or whether the corresponding service is supported, and determining to migrate the second context when both conditions are met.

[0256] The method by which the third node determines the second context of the migration includes information can be referred to the description in the embodiment shown in Figure 5, and will not be repeated here.

[0257] 603. The third node sends a migration instruction to the fourth node, which is used to indicate that the second context is migrated from the second data node to the first data node.

[0258] Accordingly, the fourth node obtains the migration instruction.

[0259] The fourth node can be the second data management node in the second domain.

[0260] The third node sends a migration instruction to the fourth node. The migration instruction is used to instruct the second data management node to migrate the second context from the second data node to the first data node. The migration instruction can also indicate the identifier of the first context.

[0261] In some cases, such as when the context identifier uses Format 1, the migration indicator can also indicate the description information of the second context, such as the service type or data type, to obtain contexts of different types.

[0262] 604. Perform context migration according to the migration instructions.

[0263] After obtaining the migration instruction, the fourth node can interact with the nodes in the data plane of the second domain to obtain the second context based on the information in the migration instruction. The specific migration process can be referred to the relevant steps in the embodiment of Figure 5, which will not be repeated here.

[0264] After context migration, the fourth node can also allocate the identifier of the second context, and perform synchronization or task execution based on the identifier of the second context. For details, please refer to the relevant description of the embodiment in Figure 5, which will not be repeated here.

[0265] The above description of the identification of the first and second contexts in the context transition process can be based on the context identifiers in Format 2. If the context identifiers in the above context transition method adopt Format 1, the corresponding fourth information, fourth request, and / or transition instructions can also indicate or carry context description information, and the context identifiers and context description information can be used to jointly decide whether to transition the context, determine the second context, and assign the identifier of the second context.

[0266] In the context migration method shown in Figure 6, the third node decides whether to migrate and the context to be migrated based on the acquired first information, and obtains the context to be migrated from the first data node through the data plane. The method in this embodiment makes migration decisions through the third node and executes the migration action through the data plane, achieving on-demand migration of the context based on the first information, reducing the signaling overhead of the consumer node obtaining the context. Furthermore, the data plane is only responsible for executing the context migration action, simplifying the processing complexity of the data plane.

[0267] This application also provides another context transfer method, including steps 701 to 703, which will be described in detail below with reference to FIG7.

[0268] 701. The sixth node obtains the identifier of the first context and the description information of the second context. The description information of the second context is used to indicate the session identifier, service identifier, data type and / or service type of the second context.

[0269] The sixth node can be a routing node (RMF) in the data plane, or a node (SDF) with signaling distribution and routing functions.

[0270] The second context is determined by the first data management node or the first consumer node in the first domain. The identifier of the first context and the description information of the second context can be a fifth request from the first data management node or the first consumer node in the first domain. The identifier of the first context is carried in the message (e.g., the message header) of the fifth request sent to the sixth node.

[0271] Specifically, the identifier of the first context and the description information of the second context, as well as the method of obtaining these two pieces of information, can be referred to the descriptions in the embodiments corresponding to Figures 5 and 6, which will not be repeated here.

[0272] 702. The sixth node sends the identifier of the first context and the description information of the second context to the second data node and / or the second data management node. The second data node is used to store the first context, and the second data management node is used to manage the second data node.

[0273] If the fifth request is used to obtain or migrate a context, the sixth node can indicate the context to be migrated from the data plane of the second domain to the data plane of the first domain.

[0274] The second data node and the second data management node belong to the second domain. The sixth node can obtain the second data node and / or the second data management node based on the identifier of the first context. For example, the RMF or SDF stores the correspondence between context identifiers and data plane nodes (DMF or DSF). The RMF or SDF can obtain the corresponding data node and data management node based on the first context identifier and this correspondence.

[0275] The sixth node sends the identifier of the first context and the description information of the second context to the second data node and the second data management node, which can be used to migrate the second context.

[0276] 703. The sixth node receives a second context from the second data node and / or the second data management node, the second context being obtained based on the identifier of the first context and the description information of the second context.

[0277] The sixth node can also assign a corresponding identifier to the second context, which can indicate the second context. In some cases, the sixth node can also send the identifier of the second context and the second context to the first data node and / or the first data management section, thus completing the migration of the second context from the data plane in the second domain to the data plane in the first domain.

[0278] The sixth node can also store the correspondence between the identifier of the second context and the first data node and the first data management node to achieve context addressing.

[0279] The above describes the implementation of the sixth node during context migration. The fifth request can also be the context management request mentioned earlier. For example, if the fifth request is used to query the context, the sixth node can send a context query request to the data plane (first data node and / or first data management node) in the first domain to indicate that the corresponding context should be queried. If the fifth request is used to delete the context, the sixth node can send a context deletion request to the data plane in the first domain to indicate that the corresponding context should be deleted. Similarly, the sixth node can also forward requests for adding or updating the corresponding context.

[0280] The method in this application embodiment can realize signaling distribution and routing functions between the data plane and the consumer node, and between data planes, through the sixth node. In addition to enabling context migration on demand and reducing signaling overhead during the migration process, it can also realize unified management of signaling and routing, reducing the processing complexity of signaling distribution or routing by the data plane or consumer node during context migration.

[0281] Figures 5 to 7 above illustrate the context transfer method. The specific implementation method will be described in detail below with reference to Figures 8 to 10.

[0282] Figure 8 illustrates one implementation of the context transition method, where the context transition decision is made by the data plane, specifically including steps 801 to 814.

[0283] 801. Context management of the original domain.

[0284] The network domain in which the terminal was located before moving can be called the original network domain or the second domain. The consumer nodes in the second domain can be called the original consumer nodes or the second consumer nodes, and may include the task center node TCF2 and other consumer nodes (which can be called Consumer 2 or Data Consumer 2). The data plane in the second domain can be called the original data plane or the second data plane, including DMF2 and DSF2. Context management can be completed through interaction between the original consumer nodes and the original data plane. The context identifier stored in the original data plane includes the first context identifier, which can also be called the old context data ID.

[0285] Specifically, the context management process can be seen in the detailed description in Figure 4, which will not be repeated here.

[0286] 802, TCF1 receive request.

[0287] When a terminal moves or a core network node fails, causing the network functions or services providing services to that terminal to change to a new network domain, or when some of the terminal's services are migrated to a new network domain, the network may decide to have a node in the new network domain provide services to that terminal. This new network domain can be called the target network domain or the first domain.

[0288] The requests received by the task center node TCF1 in the target network domain can be handover requests from base stations or TCF2 in the original network domain, or service requests such as session management, mobility management, and authentication from other network functions or services. These requests can be sent to DMF1 directly or indirectly. Indirectly, base stations, network functions, or services can send requests to DMF1 via SDF.

[0289] The request may carry user-related information, such as user identifier and user location information. The user location information can be referred to the relevant description in the embodiment shown in Figure 5, which will not be repeated here.

[0290] The request may also include one or more optional context data IDs, referred to as old context data IDs.

[0291] 803. TCF1 sends a context acquisition request to DMF1.

[0292] TCF1 determines the identifier (old context data ID) of the context to be retrieved based on the old context data ID in the request, or based on user-related information obtained in the request, or information from network functions or services.

[0293] TCF1 can send a context retrieval request to DMF1 directly or indirectly. Indirectly, it can be sent via the routing node RMF or SDF. The context retrieval request contains the old context data ID.

[0294] In some cases, the source and target domains can use the same TCF, or TCF2 in the source domain can access the data plane (also known as the target data plane or first data plane) in the target domain. In this case, this step can be TCF2 sending a context acquisition request to DMF1.

[0295] 804. Context addressing.

[0296] DMF1 sends an addressing request to the routing node RMF or SDF to determine the DMF / DSF node information corresponding to the target user context.

[0297] As described in step 405 of the embodiment corresponding to Figure 4, the routing node (RMF or SDF) stores one or more mapping relationships. DMF1 can obtain the DMF and / or DSF containing the context corresponding to the context identifier based on the old context data ID and the mapping relationship between the context identifier and the data plane (DMF or DSF). For example, the DMF containing the old context data ID is DMF2, and the DSF containing it is DSF2. DMF1 can also obtain the DSF1 corresponding to DMF1 based on the information of DMF1 and the mapping relationship between the data management node and the data node.

[0298] The addressing method depends on the information contained in the context identifier.

[0299] For example, if the context identifier is related to the user identifier, DMF1 can perform a context query based on RMF or network repository function (NRF), querying the DMF / DSF (which can be called the relay DMF / DSF) in the first domain where the user resides based on the user identifier, and then querying the DMF / DSF node where the context actually resides, i.e., DMF2 / DSF2, through the relay DMF / DSF. The relay DMF / DSF can be DMF1 / DSF1, or it can be something other than DMF1 / DSF1.

[0300] For example, if the context identifier does not use the user identifier, the DMF1 performs an action similar to that described in step 402, obtaining the DMF1 / DSF1 where the context identifier is located.

[0301] 805 and DMF1 make context transition decisions.

[0302] Migration decisions involve determining whether to migrate and determining the context of the migration.

[0303] DMF1, based on itself or its corresponding DSF1, and / or the actual DMF2 / DSF2 where the context resides, decides whether to perform a context transition. A transition is performed if at least one of the following conditions is met:

[0304] DMF1 determines that there is no context related to the old context data ID in the local (DMF1 or DSF1) based on the old context data ID; or, DMF1 determines that DMF2 / DSF2 is not the local DMF1 / DSF1 based on the DMF2 / DSF2 obtained by addressing, or that DMF2 / DSF2 belongs to a different domain from DMF1 / DSF1.

[0305] If none of the above conditions are met, such as if there is a local context related to the old context data ID or the data plane where the obtained old context data ID is located (e.g., DMF2) is the local data plane (DMF1), then context migration is not required.

[0306] DMF1 determines that the context for a migration can be all or part of the context corresponding to the old context data ID. The context for determining the migration can be called the target context or the second context.

[0307] The target context for migration is determined based on the request source node. For example, if the request source is TCF1, DMF1 determines, based on the information from TCF1, that it is only responsible for the user's task orchestration in the target network domain (domain 2 as shown in Figure 1). For instance, if the target network domain is a subdomain of the original network domain (domain 1 as shown in Figure 1), the target context for migration could be the public data corresponding to the old context data ID. Alternatively, if DMF1 determines, based on the information from TCF1, that TCF1 can take over the user's context on the target side, then the target context for migration could be all the data corresponding to the old context data ID (including public data and service data).

[0308] For example, if the request originates from a consumer node (Consumer 1 or Data Consumer 1), such as SMF, DMF1 may decide to execute only a portion of the service data in the context corresponding to the old context data ID, such as migrating only the service data corresponding to a specific PDU session or QoS Flow, with the target context being the service data corresponding to the old context data ID.

[0309] 806. Context transfer is completed between DMF1 and DSF2.

[0310] Based on the decision result of step 805, DMF1 can send a context migration request to DSF2 directly or indirectly (via DMF2, RMF, and / or SDF). This request message may carry a target context identifier, which may include a public context identifier and a service context identifier. Optionally, it may also carry partial context description information. Specific information carried can be found in Table 4.

[0311] Table 4

[0312] Optionally, the service context identifier can be an internal identifier within the core network domain or an external identifier outside the core network (such as a third-party application), and can be used as an external routing index.

[0313] In addition to indicating the context to be migrated through the target context identifier, the migration request may also include the identification information or address information of DMF1 / DSF1 in the target network domain, which is used to indicate which data plane node DSF2 needs to send the target context to.

[0314] DSF2 sends the corresponding target context to DMF1 based on the migration request.

[0315] In some cases, DSF2 can also record the identification or address information of DMF1 / DSF1, enabling it to address the corresponding context.

[0316] 807, DMF1, and DSF1 perform context creation / update.

[0317] Based on the received context, DMF1 sends a context creation or update request to DSF1, which may include the acquired context.

[0318] In some cases, such as when the context identifier is related to information other than the user identifier (e.g., the DSF identifier), a new context identifier (new context data ID) needs to be assigned to the acquired target context during context creation or update. The new context data ID can be assigned by DMF1 / DSF1, and the assignment process may involve negotiation with the context identifier allocation in the original domain.

[0319] Corresponding to the target context identifier information in Table 4, the new context data ID may also include a public context identifier and / or a service context identifier.

[0320] 808. Synchronize the context identifiers of the target data plane and the original data plane.

[0321] In some cases, information synchronization between the source data plane and the target data plane is necessary. For example, some service contexts of a terminal reside on the source data plane, while others reside on the target data plane. When performing certain services (such as billing), nodes in the source network domain need to simultaneously acquire data from both the source and target data planes. Alternatively, during certain services (such as sensing), the source data plane also needs to synchronize some data to the target data plane, such as user-level event information, including UE location and billing results. Maintaining relevant data on both the source and target data planes helps with business decision-making.

[0322] To complete the context synchronization update between the original data plane and the target data plane, DMF1 / DSF1 can send a new context data ID to DMF2 / DSF2. In some cases, DMF1 / DSF1 can also send data synchronization information to DMF2 / DSF2.

[0323] For example, DMF1 / DSF1 can send a synchronization request to DMF2 / DSF2, and the synchronization request can carry data synchronization information (also called synchronization information, such as the data synchronization information shown in Table 1).

[0324] For example, the data synchronization information includes synchronization destination information. In the synchronization request, the synchronization destination information is the identification information or address information of DMF1 / DSF1, and DMF2 / DSF2 can store the identification information or address information of DMF1 / DSF1. The data synchronization information may also include a synchronization data type list, which can indicate the type of data that needs to be synchronized.

[0325] Accordingly, DMF2 / DSF2 can send a synchronization response to DMF1 / DSF1. This response can carry data synchronization information (such as the data synchronization information shown in Table 1), such as the identifier or address information of the DMF2 / DSF2 as the synchronization destination, and DMF1 / DSF1 can store the identifier or address information of DMF2 / DSF2. The data synchronization information can also include context description information to be synchronized, such as a list of data types to be synchronized, indicating the type of context to be synchronized, such as data type, service type, etc.

[0326] The synchronization request can be initiated by DMF1 to DSF2, or by DSF1 to DSF2, or processed and / or forwarded by other nodes. Correspondingly, the synchronization response can be initiated by DMF2 to DMF1, or by DSF2 to DMF1, or processed and / or forwarded by other nodes.

[0327] Synchronous requests and synchronous responses are only used to describe the function of the request. In actual implementation, the request may have other names or other capabilities, which are not restricted here.

[0328] Information synchronization between the source data plane and the target data plane can be unidirectional or bidirectional. The data synchronized from DMF2 / DSF2 to DMF1 / DSF1 can be the same as the data synchronized from DMF1 / DSF1 to DMF2 / DSF2, or they can be different.

[0329] For example, if the billing service is in the original network domain, information synchronization can involve only the original data plane obtaining the billing context of the target data plane, which is a one-way synchronization. Alternatively, if the target network domain needs to make service decisions based on the billing results, the data synchronization information can indicate the billing results (which can be part of the billing context). In this case, the target data plane also needs to obtain the billing context of the original data plane, which is a two-way synchronization, but the data in the original and target data planes will be inconsistent. Alternatively, if the awareness service is deployed in both the original and target network domains, the original and target data planes need to obtain each other's awareness context, which is a two-way synchronization, and the data in the original and target data planes can remain consistent.

[0330] For example, if the context identifier is not related to the user identifier, the request may also carry a new context data ID and an old context data ID, which correspond to the old context data ID in the original data plane. If the context identifier is related to the user identifier, the request may only carry the identification information of DMF1 / DSF1 or the synchronization address information, and may not carry the reassigned new context data ID.

[0331] In one possible scenario, DMF2 / DSF2 is also an intermediate node rather than the user's home node. That is, the DMF2 / DSF2 determined by addressing based on the old Context data ID is inconsistent with the DMF / DSF determined based on user identifiers such as SUPI / GPSI. In this case, during the synchronization relationship establishment process described above, DMF2 / DSF2 also stores the synchronization information corresponding to the DMF / DSF locally. Upon receiving the identification information or synchronization address information sent by DMF1 / DSF1, it can return the locally stored synchronization information of the DMF / DSF to DMF1 / DSF1 in the response. In this way, the subsequent context synchronization process can be performed directly between DMF1 / DSF1 and the DMF / DSF without going through DMF2 / DSF2.

[0332] In this embodiment, the aforementioned context identifier synchronization may not employ a synchronization request and response method. One possible approach is for the target data plane to send the context to be synchronized to the origin data plane based on its local synchronization information, for example, by sending a message to the origin data plane. The origin data plane receives the context and obtains (e.g., parses it) the corresponding synchronization information, such as the data type or service type of the context. After receiving the context synchronized from the target data plane, the origin data plane obtains the corresponding synchronization information, which may include destination information, context description information, etc. Alternatively, the origin data plane sends the context to be synchronized to the target data plane based on its local synchronization information, thereby allowing the target data plane to obtain the corresponding context and synchronization information.

[0333] 809. Routing information updated.

[0334] In this embodiment of the application, this step is optional. If DMF1 determines that the routing information in the routing node (such as RMF or SDF) needs to be updated, DMF1 can initiate a routing information update to the routing node. If the new context data ID and old context data ID are related to the user identifier or are related to the DSF instance ID, then the routing information update may not be performed.

[0335] 810. DMF1 sends a context acquisition response to TCF1 or Data Consumer 1.

[0336] DMF1 sends the acquired target context to TCF1 / Data Consumer 1, carrying the new context data ID. TCF1 / Data Consumer 1 can obtain the mapping between the old context data ID and the new context data ID through the context acquisition request and context acquisition response messages. Alternatively, the response can carry both the new and old context data IDs, thus obtaining the mapping between the old and new context data IDs.

[0337] Based on the information received in the response, TCF1 / Data Consumer 1 replaces the old context data ID with the new context data ID and associates it with the target context.

[0338] 811, TCF1 performs subtask calls.

[0339] After receiving the target context, TCF1 can orchestrate tasks based on the new context data ID and trigger one or more other consumer nodes (such as Data Consumer 1) to execute the corresponding tasks (which can include multiple subtasks). It can also initiate a subtask call process to the corresponding consumer node, carrying subtask information and the new context data ID. The new context data ID can include a service context identifier and an optional public context identifier.

[0340] 812. Data Consumer 1 interacts with DMF1 to obtain the subtask context.

[0341] Based on the context required by the subtask, Data Consumer 1 sends a context retrieval request to DMF1. The request carries the context identifier of the subtask. This identifier is the context identifier associated with the subtask in the new context identifier (new context data ID) assigned after the target context is migrated to the target data plane.

[0342] DMF1 retrieves the corresponding context from itself or the corresponding DSF1 based on the context identifier of the subtask and sends it to Data Consumer 1.

[0343] In this embodiment of the application, steps 811 and 812 are optional, executed when the triggering node for the context acquisition request is TCF1, and not executed when the triggering node is a consumer node.

[0344] 813. Data consumption nodes execute sub-tasks.

[0345] Data Consumer 1 executes the specific subtask based on the received task information and the obtained subtask context.

[0346] 814. The consumer node sends the subtask completion information to TCF1.

[0347] After executing the subtask, Data Consumer 1 sends a subtask completion message to TCF1.

[0348] 815. Perform context synchronization updates between the target data plane and the original data plane.

[0349] After completing the subtask execution process, Data Consumer 1 can initiate a context update process to the original data plane. For example, Data Consumer 1 requests a context update from DMF1, and DMF1 further updates DSF1 directly or via DMF2.

[0350] In this embodiment, this step is optional. If DMF1 / DSF1 determines that the current task execution requires an update to the context, such as as determined in step 808, where the target data plane and the original data plane need to maintain data synchronization with specific context identifiers, such as some data in the common context, then the context synchronization update process can be performed by combining the identifier information or address information of both ends saved in step 808. For details on which contexts to synchronize and the method of context synchronization, please refer to the detailed explanation of step 808.

[0351] In the above embodiments, the execution node for steps 802 and 803 can also be Data Consumer 1. This node, Data Consumer 1, can receive requests initiated by TCF1 or other data consumer nodes, determine that the corresponding context needs to be obtained, and further send a context acquisition request.

[0352] In this embodiment of the application, step 810 is executed in parallel with steps 808 and 809. That is, after DMF1 receives the target context, it can perform context identifier synchronization, route update and / or send the target context and the updated context identifier to TCF1 / Data Consumer 1 in parallel.

[0353] In this application embodiment, the old context data ID and new context data ID can be in either format one or format two. In the step of using the context identifier, if the context identifier is in format one, the corresponding request / response or information also needs to include context description information. The specific format of the context identifier and the context description information can be referred to the description in the embodiment corresponding to Figure 5, which will not be repeated here.

[0354] In this embodiment, the data management node in the target network domain makes a decision on context migration based on information obtained from consumer nodes, and migrates the corresponding context from the original data plane to the target data plane through interaction between the data management node in the target network domain and the data plane (data management node and / or data nodes) of the original network domain. In this implementation, the data management node in the target network domain can perform context migration on demand and can reduce the interaction between consumer nodes and the data plane during the context migration process, thus helping to reduce the complexity of consumer nodes.

[0355] Figure 9 illustrates another implementation of the context transition method, in which the task center node performs the context transition decision, specifically including steps 901 to 913, which will be described in detail below.

[0356] 901. Context management of the original domain.

[0357] 902, TCF1 receive request.

[0358] 903, TCF1 performs context transition decisions.

[0359] TCF1's context migration decision includes determining whether to instruct the data plane to perform a context migration, and determining the target context for the migration.

[0360] TCF1 may determine whether to instruct the data plane to perform a context migration in several ways.

[0361] One possible approach is for TCF1 to determine the need for context migration based on changes in the user's location. Specifically, TCF1 determines the DSF1 / DMF1 where the context resides based on the old context data ID and context description information from the request (which could come from SDF or TCF2, etc.). This allows it to obtain the configuration information of DSF1 / DMF1 and compare the DSF / DMF region information in the configuration information with the region information of TCF1 itself. This determines whether the user has moved to a new region, and if so, a context migration is required.

[0362] Another possible approach is for TCF1 to receive a request from TCF2 containing a service / user cross-domain handover indication. Based on this indication, TCF1 determines that the user has migrated to a new domain and a context migration is required. The handover indication can be provided through the type of the request message or information carried within the message.

[0363] Another possible approach is that TCF1 interacts with DMF1 / DSF1 to obtain the data distribution information fed back by DMF1 / DSF1. This data distribution information is used to indicate the DMF / DSF corresponding to the old context data ID. If the obtained DMF / DSF does not belong to the target network domain, it can be determined that a context migration needs to be performed.

[0364] To determine which specific data needs to be migrated from the target context, it may be necessary to consider one or more of the following information:

[0365] Information 1: The capabilities of nodes (TCF1, etc.) in the target network domain. For example, if the target network domain may only support some services, then only some service contexts in the context corresponding to the old context data ID can be migrated.

[0366] Information 2: The requester that sent the request in step 902. For example, the context to be migrated is determined based on the network element / service type of the requester. For instance, if the requester is an MM node, the user context can be migrated; if the requester is an SM or network data analytics function (NWDAF) node, only part of the context can be migrated, such as the corresponding service context or the session context corresponding to the target PDU session.

[0367] Information 3: UE location information / current network element / service location information. For example, if a user's location changes across domains and they move to a new network domain, it may trigger a service migration to the new network domain. In this case, TCF1 can decide to migrate the user context.

[0368] Information 4: Service deployment information of the original or target network. Based on this information, it can be determined whether the services used by the user in the original domain support migration to the target domain. If supported, the TCF can decide to migrate the corresponding service context.

[0369] In this embodiment, TCF1 can make a decision based on one or more of the above information. For example, based on the capabilities of the nodes in the target network domain, the target network domain supports context migration for services 1, 2, and 3. However, based on the service deployment information in the target network domain, service 2 is not deployed in the target network domain. Therefore, it can be determined that the contexts of services 1 and 3 should be migrated, while the context of service 2 should remain in the original network domain. 904. TCF1 sends a context management request to DMF1.

[0370] The context management request can carry information obtained from the migration decision, including the target context identifier to be migrated.

[0371] Context management requests can also carry information such as data type or service type. The data type can be service data, public data, or a specific data type within public / service data, such as billing data, policy data, or session data. The service type can be related to the function of the network or service. For NFs, the service type can be session management, mobility management, or authentication functions, etc. For services, the service type can be network capability information such as basic connectivity services, awareness services, computing power services, or analytics services.

[0372] The context management request may also carry a synchronization instruction. For details, please refer to the data synchronization information in the context and the description in step 808 of the embodiment in Figure 8.

[0373] In this embodiment of the application, the context management request can be sent directly or indirectly (via SDF) to the DMF.

[0374] 905. Contextual addressing.

[0375] DMF1 sends an addressing request to RMF to determine the DMF / DSF node information corresponding to the target user context. For details, please refer to the relevant description in the embodiment corresponding to Figure 8, which will not be repeated here.

[0376] 906. Context transfer.

[0377] Based on the determined DMF2 / DSF2 information, DMF1 initiates a context migration request to DSF2 directly or indirectly. The request may carry the old context data ID to be migrated, as well as descriptive information of the service context (such as data type, or PDU Session ID, QoS Flow, etc.).

[0378] This step can be described in detail with reference to step 806 in the embodiment shown in Figure 8, and will not be repeated here.

[0379] 907. Context creation / update and synchronization.

[0380] DMF / DSF determines whether a new context identifier needs to be allocated. If so, DMF / DSF allocates a new context data ID.

[0381] Optionally, DMF1 / DSF1 can also synchronize context identifiers with DMF2 / DSF2, sending new context data IDs and other synchronization information.

[0382] 908. DMF1 updates routing information with routing node RMF.

[0383] DMF1 can send routing information update requests to RMF so that routing nodes can record the correspondence between the new context data ID and DMF1 / DSF1.

[0384] 909. DMF1 sends a context response to TCF1.

[0385] The response can contain both the new context data ID and the old context data ID. Sometimes the response may also include the migration execution result (e.g., success or failure).

[0386] From steps 910 to 913, TCF1 triggers a subtask, Data Consumer 1 executes the subtask, and updates the context in DMF1 / DSF1 after the task is completed. In some cases, the context in DMF2 / DSF2 can also be updated.

[0387] Steps 901 and 902 in this embodiment can be referred to in the detailed description of steps 801 and 802 in the embodiment shown in FIG8. Step 905 can be referred to in the detailed description of step 804 in the embodiment shown in FIG8. Steps 907 and 908 can be referred to in the detailed description of steps 806 to 809 in the embodiment shown in FIG8. Steps 910 to 913 can be referred to in the detailed description of steps 811 to 815 in the embodiment shown in FIG8, and will not be repeated here.

[0388] In this application embodiment, the old context data ID and new context data ID can be in either format one or format two. In the step of using the context identifier, if the context identifier is in format one, the corresponding request / response or information also needs to include context description information. The specific format of the context identifier and the context description information can be referred to the description in the embodiment corresponding to Figure 6, which will not be repeated here.

[0389] In this embodiment, the task center node in the target network domain makes a decision on context migration based on information obtained from other consumer nodes, and triggers the data management node in the target network domain to execute the context migration, thereby completing the context migration. In this implementation, the task center node can migrate the context as needed based on location information, capability information, service deployment information, etc. Furthermore, having the task center node as the main body of the migration decision simplifies the functionality of the data plane (such as DMF) and helps reduce the complexity of the data plane.

[0390] Figure 10 illustrates another implementation of the context transfer method, specifically including steps 1001 to 1011.

[0391] 1001. Context management of the original domain.

[0392] 1002, TCF1 receives the request.

[0393] 1003, TCF1, Data Consumer 1, or DMF1 execute context migration decisions.

[0394] For a detailed description of the migration decision, please refer to Figures 8 and / or 9, which will not be repeated here.

[0395] 1004. Context Shift.

[0396] If the node making the migration decision is DMF1, DMF1 sends a context migration request to DMF2 and / or DSF2 via SDF. If the node making the migration decision is TCF1 or Data Consumer 1, the context migration also includes the node making the migration decision sending a migration instruction to DMF1, and then DMF1 sending a context migration request to DMF2 and / or DSF2 via SDF.

[0397] SDF can receive or send the old context data ID by including it in the header of the migration request message.

[0398] Context addressing may also be required before context migration to determine the DMF / DSF node information corresponding to the target context.

[0399] 1005. SDF performs context creation / update and synchronization.

[0400] SDF can assign a new context identifier (new context data ID) to the target context that is migrated to the target data plane.

[0401] During context creation / update and synchronization, the interaction between the target data plane and the original data plane can be performed via SDF, including receiving and forwarding context management requests or synchronization requests.

[0402] 1006. DMF1 interacts with SDF to update routing information.

[0403] DMF1 can send routing information update requests to SDF so that SDF can record the correspondence between the new context data ID and DMF1 / DSF1.

[0404] 1007. DMF1 sends a context response to TCF1.

[0405] 1008. Subtask Invocation.

[0406] 1009a and 1009b, Subtask Context Acquisition.

[0407] Data Consumer 1 executes the context acquisition process. The acquisition request is relayed through SDF and further forwarded to DMF1 or DSF1. DMF1 / DSF1 returns the corresponding context, which is used by Data Consumer 1 to execute the corresponding subtask process.

[0408] 1010. Subtask execution.

[0409] 1011. Context synchronization update.

[0410] Context update requests and responses can be relayed via SDF.

[0411] In addition to the SDF processing or forwarding content involved in the steps of this application embodiment, other processes, such as the context management of the original network domain and the interaction process between the target data plane and the original data plane, as well as the information involved, can be referred to the detailed description in the embodiments of Figure 8 and / or Figure 9, which will not be repeated here.

[0412] In this embodiment of the application, the SDF can be used to relay various information during the context migration process, completing signaling forwarding and context migration between the original data plane and the target data plane. The signaling distribution and routing functions of the SDF can realize signaling interaction between different network domains and help reduce the maintenance of routing information by nodes (such as data planes) in different network domains.

[0413] The methods provided in the embodiments of this application have been described in detail above with reference to several accompanying drawings. The apparatus provided in the embodiments of this application will now be described with reference to the accompanying drawings.

[0414] Figures 11 and 12 are schematic block diagrams of possible communication devices provided in embodiments of this application. One device provided in this application, as shown in Figure 11, includes a transceiver unit 1101 and a processing unit 1102.

[0415] The communication device 1100 can be a first node, a second node, a third node, a fourth node, a fifth node, or a sixth node, or it can be a component (such as a chip or module) of one of the first, second, third, fourth, fifth, or sixth nodes, used to implement the methods involved in the embodiments shown in Figures 4 to 10. The chip can be, for example, a system-on-a-chip (SoC). The first node can be a data management node, the second node can be a consumer node, the third node can be a consumer node, the fourth node can be a data management node, the fifth node can be a RAN node or a consumer node, and the sixth node can be a routing node. For details, please refer to the relevant descriptions in the above method embodiments.

[0416] As shown in Figure 11, the device 1100 may include a transceiver unit 1101 and a processing unit 1102. The transceiver unit 1101 can communicate with the outside world, and the processing unit 1102 is used for data processing. The transceiver unit 1101 may also be referred to as a communication interface or a transceiver unit. The processing unit 1102 can be used for processing. Optionally, the transceiver unit may also be a processing unit.

[0417] In this embodiment, the communication device 1100 may include a transmitting unit but not a receiving unit. Alternatively, the communication device 1100 may include a receiving unit but not a transmitting unit. Specifically, it depends on whether the above-described scheme executed by the communication device 1100 includes both transmitting and receiving actions.

[0418] Optionally, the communication device 1100 may further include a storage unit, which can be used to store instructions and / or data. The processing unit 1102 can read the instructions and / or data in the storage unit so that the device can implement the aforementioned method embodiments.

[0419] For example, the communication device 1100 may be a data management node, or a communication device applied to or used in conjunction with a data management node and capable of implementing methods executed by the data management node, such as a chip, chip system, or circuit.

[0420] For example, the communication device 1100 may be a consumer node, or a communication device applied to or used in conjunction with a consumer node and capable of implementing methods executed by the consumer node, such as a chip, chip system, or circuit.

[0421] For example, the communication device 1100 may be a routing node, or a communication device applied to or used in conjunction with a routing node and capable of implementing the methods executed by the routing node, such as a chip, chip system, or circuit, for details of which can be found in the relevant description of the chip system.

[0422] For example, the communication device 1100 may also be a data node, or a communication device applied to or used in conjunction with a data node and capable of implementing a method executed by the data node, such as a chip, chip system, or circuit, for details of which can be found in the relevant description of the chip system.

[0423] In one possible design, the communication device 1100 can implement the steps or processes corresponding to the first node executed in the above method embodiment, wherein the transceiver unit 1101 is used to perform the transceiver-related operations of the first node in the above method embodiment, and the processing unit 1102 is used to perform the processing-related operations of the first node in the above method embodiment.

[0424] As an example, the transceiver unit 1101 is used to obtain first information, which indicates: the identifier of a first context and the identifier of a second node, and the second node is used to request the first context; the processing unit 1102 is used to determine the migration of a second context based on the first information, and the second context includes the following contexts in the first context: the context in the first domain where the second node is located, and / or the context that the second node can take over, and / or the context related to the function of the second node.

[0425] In another possible design, the communication device 1100 can implement the steps or processes corresponding to the second node executed in the above method embodiment, wherein the transceiver unit 1101 is used to perform the transceiver-related operations of the second node in the above method embodiment, and the processing unit 1102 is used to perform the processing-related operations of the second node in the above method embodiment.

[0426] As an example, the transceiver unit 1101 is used to obtain third information, which indicates: the identifier of the first context; the transceiver unit 1101 is also used to receive a second context from the first data management node, the second context being the context in the first domain where the second node is located, and / or the context that the second node can take over, and / or the context related to the function of the second node; the processing unit 1102 is used to request the first context from the first data management node according to the third information.

[0427] In another possible design, the communication device 1100 can implement the steps or processes corresponding to the third node executed in the above method embodiment, wherein the transceiver unit 1101 is used to perform the transceiver-related operations of the third node in the above method embodiment, and the processing unit 1102 is used to perform the processing-related operations of the third node in the above method embodiment.

[0428] As an example, the transceiver unit 1101 is used to obtain fourth information, which is used to indicate the identifier of the first context and fifth information, which is used to indicate one or more of the following: the network element type or service type of the third node, the user's location information, the location information of the third node, or service deployment information. The third node is used to request the first context, and the service deployment information is used to indicate the node supporting the service. The processing unit 1102 is used to determine the migration of the second context based on the fourth information, where the second context is part or all of the first context.

[0429] In another possible design, the communication device 1100 can implement the steps or processes corresponding to the fourth node in the above method embodiment, wherein the transceiver unit 1101 is used to perform the transceiver-related operations of the fourth node in the above method embodiment, and the processing unit 1102 is used to perform the processing-related operations of the fourth node in the above method embodiment.

[0430] As an example, transceiver unit 1101 is used to obtain a migration instruction, which indicates that a second context be migrated from a second data node to a first data node. The second context is part or all of the first context. The migration instruction is obtained based on the identifier of the first context and fifth information, which indicates one or more of the following: the network element type or service type of the third node, the user's location information, the location information of the third node, or service deployment information. The third node is used to request the first context, and the service deployment information indicates the services supported by a node. Processing unit 1102 is used to perform context migration according to the migration instruction.

[0431] In another possible design, the communication device 1100 can implement the steps or processes corresponding to the fifth node in the above method embodiment, wherein the transceiver unit 1101 is used to perform the transceiver-related operations of the fifth node in the above method embodiment, and the processing unit 1102 is used to perform the processing-related operations of the fifth node in the above method embodiment.

[0432] In another possible design, the communication device 1100 can implement the steps or processes corresponding to the sixth node in the above method embodiment, wherein the transceiver unit 1101 is used to perform the transceiver-related operations of the sixth node in the above method embodiment, and the processing unit 1102 is used to perform the processing-related operations of the sixth node in the above method embodiment.

[0433] It should be understood that the specific process of each unit performing the above-mentioned corresponding steps has been described in detail in the above method embodiments, and will not be repeated here for the sake of brevity.

[0434] It should also be understood that the aforementioned communication device 1100 is embodied in the form of a functional unit. The term "unit" here can refer to an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, a proprietary processor, or a group processor, etc.) and memory for executing one or more software or firmware programs, integrated logic circuitry, and / or other suitable components supporting the described functions. In an alternative example, those skilled in the art will understand that the communication device 1100 can be specifically the communication device in the above embodiments, and can be used to execute the various processes and / or steps corresponding to the communication device in the above method embodiments; to avoid repetition, these will not be described again here.

[0435] The communication device 1100 of the above scheme has the function of implementing the corresponding steps performed by the communication device (such as a consumer node, data management node, data node, or routing node) in the above method. The function 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; for example, the transceiver unit can be replaced by a transceiver (e.g., the sending unit in the transceiver unit can be replaced by a transmitter, and the receiving unit in the transceiver unit can be replaced by a receiver), and other units, such as processing units, can be replaced by processors, each executing the transmission and reception operations and related processing operations in each method embodiment.

[0436] In addition, the aforementioned transceiver unit may also be a transceiver circuit (for example, it may include a transmitting circuit or a receiving circuit), and the processing unit may be a processing circuit.

[0437] It is understood that the division of units in the above-described device is merely a logical functional division. Each function can correspond to a functional unit, or two or more functions can be integrated into one functional unit. In actual implementation, all or some units can be integrated into a single physical entity, or they can be distributed across different physical entities. Furthermore, the aforementioned functional units can be implemented in hardware, software, or a combination of both. Whether a function is executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0438] Figure 12 is another schematic block diagram of the device provided in an embodiment of this application. As shown in Figure 12, the device 1200 includes one or more processors 1201. The processor 1201 may be a general-purpose processor or a special-purpose processor, etc. For example, it may be a baseband processor or a central processing unit. The baseband processor may be used to process communication protocols and communication data, and the central processing unit may be used to control the device (e.g., a vehicle or a chip), execute software programs, and process data from the software programs.

[0439] Optionally, in one design, processor 1201 may include a computer program (also referred to as code or instructions) that can be executed on processor 1201, causing device 1200 to perform the methods executed by the first node, second node, third node, fourth node, fifth node, or sixth node in the method embodiments described above. In yet another possible design, device 1200 includes circuitry (not shown in FIG12) for implementing the functions of the first node, second node, third node, fourth node, fifth node, or sixth node in the method embodiments described above.

[0440] For example, processor 1201 can be used to execute a computer program in memory to implement the steps performed by the first node, second node, third node, fourth node, fifth node or sixth node in the method embodiments shown in Figures 4 to 10.

[0441] Optionally, the device 1200 may include one or more memories 1202 storing computer programs (sometimes referred to as code or instructions) that can be run on the processor 1201, causing the device 1200 to perform the methods executed by the first node, second node, third node, fourth node, fifth node, or sixth node in the above embodiments.

[0442] Optionally, the processor 1201 and / or memory 1202 may also store data. The processor and memory may be configured separately or integrated together.

[0443] Optionally, the device 1200 may also include a communication interface 1203. The processor 1201, sometimes referred to as a processing unit, controls the device (e.g., a first node, second node, third node, fourth node, fifth node, or sixth node). The communication interface 1203, sometimes referred to as a transceiver unit, transceiver, transceiver circuit, or transceiver, is used to implement the device's transceiver functions; for example, the communication interface 1203 can be used to acquire first information.

[0444] Optionally, the device 1200 also includes a communication interface 1203. The processor 1201 and the communication interface 1203 are coupled to each other. It is understood that the communication interface 1203 can be a transceiver or an input / output interface.

[0445] When device 1200 is used to implement the methods shown in Figures 4 to 10, processor 1201 can be used to execute the functions of processing unit 1102, and communication interface 1203 can be used to execute the functions of transceiver unit 1101. Whether communication interface 1203 is used for sending or receiving depends on whether the scheme executed by device 1200 is used to perform a sending action or a receiving action.

[0446] When the aforementioned device 1200 is a chip applied to the first node, the chip implements the functions of the first node in the above method embodiments. The chip of the first node receives signals from other modules (such as radio frequency modules or antennas) in the first node, and these signals may be sent to the first node by the second node; or, the chip of the first node sends signals to other modules (such as radio frequency modules or antennas) in the first node, and these signals may be sent from the first node to the second node.

[0447] When the aforementioned device 1200 is a chip applied to a third node, the chip implements the functions of the third node in the above method embodiments. The chip of the third node receives signals from other modules in the third node, which may be signals sent to the third node by the fourth node; or, the chip of the third node sends signals to other modules in the third node, which may be signals sent from the third node to the fourth node.

[0448] It is understood that when the device 1200 is a first node, second node, third node, fourth node, fifth node, or sixth node, the communication interface 1203 can be a transceiver, specifically including a transmitter and a receiver. The transmitter is used to send signals, and the receiver is used to receive signals. When the device 1200 is a chip applied to a first node, second node, third node, fourth node, fifth node, or sixth node, the communication interface 1203 can be an input / output circuit, wherein the input circuit can be used for receiving, and the output interface can be used for sending.

[0449] Optionally, the device 1200 also includes a power supply circuit for supplying power to the device 1200.

[0450] The above-described method embodiments can be applied to a processor, or implemented by a processor. A processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed through integrated logic circuits in the processor's hardware or through software instructions.

[0451] The aforementioned processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0452] The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

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

[0454] This application also provides a chip system including at least one processor for supporting the implementation of the functions of the consumer node, data management node, data node, or routing node involved in any of the above method embodiments, such as sending, receiving, or processing the information involved in the above methods.

[0455] In one possible design, the chip system also includes a memory for storing computer program instructions and data, which may be located inside or outside the processor.

[0456] The chip system can consist of chips or include chips and other discrete components.

[0457] This application also provides a computer program product, which includes a computer program (also referred to as code or instructions) that, when the computer program is run, executes the methods used in the embodiments shown in Figures 4 to 10 to support the execution of the consumer node, data management node, data node, or routing node involved in any of the above method embodiments.

[0458] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, the methods used in the embodiments shown in Figures 4 to 10 to support the execution of the consumer node, data management node, data node, or routing node involved in any of the above method embodiments are executed.

[0459] This application also provides a communication system, which includes the aforementioned consumer node, data management node, data node, or routing node.

[0460] The methods provided in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. This computer program product may include one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic disk), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

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

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

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

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

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

[0466] If this function 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 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.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

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

Claims

1. A context transfer method, characterized in that, The method is executed by the first node in the first domain, and the method includes: Obtain first information, which is used to indicate: the identifier of the user's first context and the identifier of the second node in the first domain, wherein the user moves from the second domain to the first domain; Based on the first information, it is determined that a second context will be migrated from the second domain to the first domain, wherein the second context includes at least one of the following from the first context: a context supported by the first domain, a context that the second node can take over, or a context related to the functionality of the second node; Send the second context to the second node.

2. The method as described in claim 1, characterized in that, The acquisition of the first information includes: Receive a first request from the second node, the first request carrying the identifier of the first context and / or the identifier of the second node.

3. The method as described in claim 1 or 2, characterized in that, The step of determining, based on the first information, to migrate the second context from the second domain to the first domain includes: Obtain second information, which is used to indicate: a first data node, the first data node belongs to the first domain, the first data node is used to store the context in the first domain, and the first node is used to manage the context in the first data node; Based on the first information and the second information, it is determined that the second context will be migrated from the second domain to the first domain.

4. The method as described in claim 3, characterized in that, The second information is also used to indicate information about a second data node in the second domain, wherein the second data node is the data node where the first context resides, and obtaining the second information includes: Send the identifier of the first context to the routing node, the routing node including first distribution information, the first distribution information being used to indicate that the first context is distributed in the second data node; Receive information from the second data node from the routing node.

5. The method as described in claim 4, characterized in that, The step of determining to migrate the second context from the second domain to the first domain based on the first information and the second information includes: determining to migrate the second context from the second domain to the first domain under at least one of the following conditions: The first context does not exist in the first data node; or, The first context does not exist in the first node; or, The first data node and the second data node are different; or, The first field and the second field are different.

6. The method according to any one of claims 1 to 5, characterized in that, The second context includes the contexts supported by the first domain in the first context, and the method further includes: Based on the capability information of the network elements in the first domain or the pre-configuration information in the first node, determine the context supported by the first domain in the first context; The capability information is used to indicate the context supported by the network element in the first domain, and the pre-configuration information indicates the context identifier or identifier segment that the first domain supports or does not support.

7. The method according to any one of claims 1 to 6, characterized in that, The second context includes the context that the second node can take over in the first context, and the method further includes: Based on the context types and / or service types supported by the second node, determine the contexts that the second node can take over in the first context.

8. The method according to any one of claims 1 to 7, characterized in that, The second context includes the context in the first context related to the functionality of the second node, wherein: The second node is used for task orchestration in the first domain, and the second context includes: part or all of a public context in the first context where the data type is public data; or, The second node is used for task orchestration, and the second node supports user context migration, wherein the second context includes the user context in the first context; or, The second node is used for mobility management, and the second context includes a mobility management context in the first context whose data type is mobility management; or, The second node is used for session management, and the second context includes the session context in the first context whose data type is session data; or, The second node is used to provide authentication services, and the second context includes the context of the authentication services in the first context.

9. The method according to any one of claims 1 to 8, characterized in that, The first information is also used to indicate context description information, which indicates data type or service type, and the second context includes: some or all of the contexts in the first context that satisfy the context description information.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: Send a second request to the second data node in the second domain, the second data node being the data node where the first context is located, the second request being used to obtain the second context; Receive the second context from the second data node.

11. The method as described in claim 10, characterized in that, Sending the second request to the second data node in the second domain includes: The second request is sent to the second data node via a routing node; or, the second request is sent to the second data node via a data management node in the second domain, the data management node being used to manage the second data node.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: Obtain the first identifier of the second context in the first domain. The first identifier is used to indicate the second context. The first identifier is assigned by the first node or the first data node in the first domain. The first data node is used to store the second context. Send the first identifier to the second node.

13. The method as described in claim 12, characterized in that, Sending the first identifier to the second node includes: The first identifier and the second identifier of the second context in the second domain are sent to the second node, wherein the first identifier is used to replace the second identifier.

14. The method as described in claim 12 or 13, characterized in that, The method further includes: Send the first identifier and the second context to the first data node.

15. The method according to any one of claims 12 to 14, characterized in that, The method further includes: Send the first identifier and the second context to the second data node and / or the data management node of the second domain.

16. The method according to any one of claims 1 to 15, characterized in that, The method further includes: Send synchronization information to the second data node and / or the data management node, the synchronization information being used to indicate that when the second context in the first domain changes, the changed second context should be sent to the second data node and / or the data management node; The synchronization information is used to indicate one or more of the following: the identifier of the first context, the identifier of the second context, the first data node, the information of the first node, or the type of the context to be synchronized.

17. A context transfer method, characterized in that, The method is executed by the third node in the first domain, and the method includes: Obtain fourth information, which is used to indicate the identifier of the user's first context and fifth information, the user moves from the second domain to the first domain, the fifth information is used to indicate one or more of the following: the network element type or service type of the third node, the user's location information, the location information of the third node, or service deployment information, the service deployment information is used to indicate the node supporting the service; The migration second context is determined based on the fourth information, and the second context is part or all of the first context; Send a migration instruction to the fourth node, the migration instruction being used to instruct the second context to be migrated from the second data node in the second domain to the first data node in the first domain.

18. The method as described in claim 17, characterized in that, The acquisition of the fourth information also includes: A fourth request is received from a fifth node, which is used for user access or signaling distribution, or the fifth node is a consumer node different from the third node. The fourth request is used to obtain the first context, and the fourth request carries the identifier of the first context.

19. The method as described in claim 17, characterized in that, The acquisition of the fourth information also includes: A fourth request is received from a fifth node, which is used for user access or signaling distribution, or the fifth node is a consumer node different from the third node. The fourth request is used to obtain the first context and carries a user identifier. The identifier of the first context is obtained based on the user identifier and the first mapping relationship, wherein the first mapping relationship is used to indicate the context identifier corresponding to the user identifier.

20. The method according to any one of claims 17 to 19, characterized in that, Determining the second migration context based on the fourth information includes: Obtain first location information, the first location information including the location information of the second data node and / or the location information of the fourth node, the second data node being used to store the first context, and the fourth node being used to manage the second data node; If, based on the first location information and the second location information, it is determined that the user has undergone a cross-domain change, a second migration context is determined, wherein the second location information includes the user's location information and / or the location information of the third node.

21. The method according to any one of claims 17 to 19, characterized in that, The first domain also includes a first data node and the fourth node, the fourth node being used to manage the first data node, and the step of determining the migration second context based on the fourth information further includes: Obtain first distribution information, which is used to indicate that the first context is stored in the second data node; The migration of the second context is determined in at least one of the following situations: The first context does not exist in the first data node; or, The first context does not exist in the fourth node; or... The first data node and the second data node are different; or, The first field and the second field are different.

22. The method according to any one of claims 17 to 19, characterized in that, The fifth piece of information is used to indicate service deployment information, and the step of determining the migration second context based on the fourth piece of information includes: Based on the service deployment information, determine whether the nodes in the first domain support the service corresponding to the second context; If the node in the first domain supports the service corresponding to the second context, then the migration of the second context is determined.

23. The method according to any one of claims 17 to 22, characterized in that, The fifth piece of information is used to indicate the network element type or service type of the third node, wherein, The network element type or service type of the third node is a task orchestration network element, and the second context includes: part or all of the common context in the first context; or... The network element type or service type of the third node is a task orchestration network element, the third node supports user context migration, and the second context includes the user context in the first context; or... The network element type or service type of the third node is a mobility management network element, and the second context includes the mobility management context in the first context whose data type is mobility management; or, The network element type or service type of the third node is a session management network element, and the second context includes the session context in the first context whose data type is session data.

24. The method according to any one of claims 17 to 23, characterized in that, The second context is migrated from the second data node to the first data node via the routing node.

25. The method according to any one of claims 17 to 24, characterized in that, The method further includes: Obtain the first identifier of the second context in the first domain, the first identifier being assigned by the fourth node or the first data node.

26. The method as described in claim 25, characterized in that, The method further includes: The first identifier and the second context are sent to the access device, the signaling distribution device, the third node, or the fifth node. The first identifier and the second context are used to perform the task.

27. A context transfer method, characterized in that, For the fourth node, the method includes: Obtain a migration instruction, the migration instruction being used to instruct the migration of a second context from a second data node in a second domain to a first data node in a first domain, the second context being part or all of a user's first context, the user moving from the second domain to the first domain; The second context is migrated from the second data node to the first data node according to the migration instruction.

28. The method as described in claim 27, characterized in that, The context migration based on the migration instruction includes: Send a sixth request to the second data node, the sixth request being used to request the acquisition of the second context; Receive the second context from the second data node.

29. The method as described in claim 28, characterized in that, The migration indication includes an identifier of the first context, and the method further includes: The identifier of the first context is sent to the routing node. The identifier of the first context is used by the routing node to obtain information about the second data node and / or the data management node according to the first distribution information. The data management node is used to manage the second data node. The first distribution information is used to indicate that the first context is distributed in the second data node. Receive information from the second data node and / or the data management node.

30. The method as described in claim 29, characterized in that, Sending the sixth request to the second data node includes: The sixth request is sent to the second data node via the routing node.

31. The method according to any one of claims 27 to 30, characterized in that, The process of obtaining migration instructions includes: Receive the migration instruction from the third node in the first domain, wherein: The third node is used for task orchestration, and the second context includes: part or all of the common context in the first context; or... The third node is used for task orchestration, and the third node supports user context migration. The second context includes: the user context in the first context; or... The third node is used for mobility management, and the second context includes the mobility management context in the first context whose data type is mobility management; or, The third node is used for session management, and the second context includes the session context in the first context whose data type is session data; or... The third node is used to provide authentication services, and the second context includes the context of the authentication services in the first context.

32. The method according to any one of claims 27 to 31, characterized in that, The method further includes: Assign the first identifier of the second context in the first domain; Send the first identifier and the second context to the first data node and / or the third node.

33. The method according to any one of claims 27 to 32, characterized in that, The method further includes: A synchronization request is sent to the second data node or the data management node of the second domain. The data management node is used to manage the second data node. The synchronization request includes first data synchronization information, which includes a first synchronization indication and the identification information or address information of the fourth node. The first synchronization indication is used to indicate the type of data that needs to be synchronized in the first domain and the second domain.

34. The method as described in claim 33, characterized in that, The method further includes: Receive a synchronization response from the second data node or the data management node. The synchronization response includes second data synchronization information, which includes a second synchronization indication and identification information or address information of the second data node or the data management node. The second synchronization indication is the type of data that needs to be synchronized in the first domain and the second domain.

35. A communication device, characterized in that, The processor includes a processor coupled to a memory for storing computer programs, and the processor for executing the computer programs stored in the memory. So that the communication device performs the method as described in any one of claims 1 to 16; or, So that the communication device performs the method as described in any one of claims 17 to 26; or, So that the communication device performs the method as described in any one of claims 27 to 34.

36. A communication device, characterized in that, It includes a module for performing the method as described in any one of claims 1 to 16, or includes a module for performing the method as described in any one of claims 17 to 26, or includes a module for performing the method as described in any one of claims 27 to 34.

37. A computer-readable storage medium, characterized in that, The computer stores instructions that, when executed on a computer, cause the computer to perform the method as claimed in any one of claims 1 to 16, or cause the computer to perform the method as claimed in any one of claims 17 to 26, or cause the computer to perform the method as claimed in any one of claims 27 to 34.

38. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being configured to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 16, or to cause the electronic device to perform the method as described in any one of claims 17 to 26, or to cause the electronic device to perform the method as described in any one of claims 27 to 34.

Images