Method and system for managing function selection

Abstract

Systems and methods for initial access are provided. The method comprises: an RAN receiving an access request message from a terminal device, the access request message comprising at least one requested task ID, the requested task ID indicating at least one requested task; the RAN determines at least one allowed task from the at least one requested task; and the RAN sends the task ID of the at least one allowed task to the terminal device.

Description

Technical Field

[0001] This invention relates to the field of communication networks, and more particularly to methods and systems for managing function selection. Background Technology

[0002] For 6G, an X-centric network approach is proposed to provide X as a Service (XaaS). Specifically, XaaS can be Data Analytics and Management (DAM) as a Service (where X represents data analytics and management), Network for Artificial Intelligence (NET4AI) as a Service, Network for Data (NET4Data) as a Service, and so on. These services can collaborate to complete missions. For example, in the mission of optimizing network performance, the DAM service can collect useful data from data sources and then store the collected data in the NET4Data service's storage; the NET4AI service uses the collected data to perform AI training or AI inference to obtain trained models or inference results; then, it uses the trained models or inference results to run a virtual network of the physical network to verify whether the trained models or inference results are meaningful for optimizing network performance; finally, the verified models or inference results can be deployed to the physical network. This mission-based approach will be used in 6G to manage the collaboration of different services. A mission involves different services, and each service can be considered a task. In other words, a task consists of several jobs that cooperate with each other, executing sequentially or in parallel to complete the task. In some cases, a task may consist of several sub-missions and / or jobs, and a sub-mission may consist of several jobs. The existing technology does not provide details on task processing; specifically, it does not discuss how to select management functions when processing tasks. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for managing function selection.

[0004] A first aspect of the present invention provides a method for selecting a management function. The method includes: a first task management function sending a registration request message, wherein the registration request message indicates one or more tasks or one or more subtasks supported by the initial task management function; the first task management function receiving a first request message, wherein the first request message indicates a requested task; the first task management function determining one or more target task management functions, wherein the one or more target task functions are capable of providing the requested task or one or more subtasks involved in the requested task; and at least the first task management function selecting a second management function from the first task function and the one or more target task management functions.

[0005] In some embodiments of the first aspect of the present invention, the first task management function determining the one or more target task management functions includes: the first task management function determining whether the one or more target task management functions in the network are capable of providing the request.

[0006] In some embodiments of the first aspect of the present invention, the first task management function determines that there is no target task management in the network capable of providing the requested task, and the method further includes: the first management function sending a discovery message, wherein the discovery message indicates the one or more subtasks involved in the requested task.

[0007] In some embodiments of the first aspect of the present invention, the method further includes: the first management function receiving one or more target task management function IDs that indicate the one or more target task management functions, wherein the one or more target management functions are capable of providing the requested task.

[0008] In some embodiments of the first aspect of the present invention, the method further includes: the first management function receiving one or more candidate task management function IDs indicating the one or more candidate task management functions, wherein the one or more candidate management functions are capable of providing the one or more sub-tasks involved in the requested task; the first management function sending a second request message to the one or more candidate task management functions; the first management function receiving one or more response messages from the one or more candidate task management functions; and the initial management function determining the one or more target task management functions from the one or more candidate task management functions based on the one or more response messages.

[0009] In some embodiments of the first aspect of the present invention, the registration request message includes at least one of the following: a task ID, a task context, a subtask ID, and a subtask context, wherein the task ID indicates the task supported by the first task management function, the task context describes the task supported by the first task management function, the subtask ID indicates the subtask supported by the first task management function, and the subtask context describes the subtask supported by the first task management function.

[0010] In some embodiments of the first aspect of the present invention, the second request message includes at least one of the following: a task ID indicating the task to be requested, a task context describing the task to be requested, a subtask ID indicating a subtask involved in the task to be requested, and a subtask context describing a subtask not involved in the task to be requested.

[0011] A second aspect of the invention provides an apparatus comprising a processor for executing instructions stored in a memory, the instructions, when executed by the processor, performing the method of the first aspect.

[0012] A third aspect of the invention provides a computer-readable storage medium including instructions that, when executed by a computer, cause the computer to perform the method of the first aspect.

[0013] Another objective of this invention is to provide an initial access method and system.

[0014] A fourth aspect of the present invention provides a method for selecting management functions. The method includes: a radio access network (RAN) receiving an access request message from a terminal device, wherein the access request message includes at least one requested task ID, the requested task ID indicating at least one requested task; the RAN determining at least one allowed task from the at least one requested task; and the RAN sending the task ID of the at least one allowed task to the terminal device.

[0015] In some embodiments of the fourth aspect of the present invention, the RAN determining an allowed task ID from the requested task ID includes: the RAN determining whether there is an overlap between a supported task ID and the at least one requested task ID, wherein the supported task ID indicates a task supported by the task management function of the RAN and / or the core network (CN); and the RAN selecting the overlapping task ID as the allowed task ID.

[0016] In some embodiments of the fourth aspect of the present invention, the RAN determining an allowed task ID from the requested task ID includes: the RAN sending an initial terminal message to the core network (CN), wherein the initial terminal message includes the requested task ID; and the RAN receiving one or more allowed task IDs of the at least one allowed task from the CN.

[0017] In some embodiments of the fourth aspect of the invention, the RAN determining an allowed task ID from the requested task ID includes: the RAN determining that the at least one requested task ID does not overlap with a supported task ID, wherein the supported task ID indicates a task supported by the RAN's management functions; or The RAN determines that it does not support the at least one requested task ID in the cell, tracking area, or network in which the terminal device requests access; the RAN sends an initial terminal message to the core network (CN), wherein the initial terminal message includes the requested task ID; the RAN receives one or more allowed task IDs of the at least one allowed task from the CN.

[0018] In some embodiments of the fourth aspect of the invention, the RAN determining the allowed task ID from the at least one requested task ID includes: The RAN determines at least one overlapping task ID between the at least one requested task ID and at least one supported task ID, wherein the at least one supported task ID indicates at least one task supported by at least one task management function of the RAN; The RAN sends an initial terminal message to the core network (CN), wherein the initial terminal message includes the at least one overlapping task ID; The RAN receives one or more allowed task IDs of the at least one allowed task from the CN.

[0019] In some embodiments of the fourth aspect of the invention, the RAN determining the at least one overlapping task ID further includes: The RAN determines that it supports at least one overlapping task ID in the cell, tracking area, or network in which the terminal device requests access.

[0020] In some embodiments of the fourth aspect of the invention, the RAN determining the allowed task ID from the at least one requested task ID includes: The RAN determines at least one overlapping task ID between the at least one requested task ID and at least one supported task ID, wherein the at least one supported task ID indicates at least one task supported by at least one task management function of the RAN; The RAN determines that one or more of the requested task IDs do not overlap with any at least one supported task ID, wherein the at least one supported task ID indicates at least one task supported by at least one task management function of the RAN; or The RAN determines one or more of the task IDs of the task IDs for which the RAN does not support the at least one request in the cell, tracking area or network in which the terminal device requests access. The RAN sends an initial terminal message to the core network (CN), wherein the initial terminal message includes one or more of the at least one overlapping task ID and the at least one requested task ID; The RAN receives one or more allowed task IDs of the at least one allowed task from the CN.

[0021] In some embodiments of the fourth aspect of the present invention, the initial terminal message further includes one or more of the following: terminal device context and RAN capabilities.

[0022] In some embodiments of the fourth aspect of the present invention, the UE context includes one or more of the following: a cell ID identifying the cell where the terminal device is located, a tracking area ID identifying the tracking area where the terminal device is located, a public land mobile network (PLMN) ID identifying the public network where the terminal device is located or requests access, a non-public network (NPN) ID identifying the non-public network where the terminal device is located or requests access, and the computing and communication capabilities of the terminal device when performing the task.

[0023] In some embodiments of the fourth aspect of the present invention, the RAN capability includes one or more of the following: the RAN-supported task ID, the RAN-supported job ID, and the RAN-supported subtask ID.

[0024] In some embodiments of the fourth aspect of the present invention, the radio access network (RAN) receiving the access request message from the terminal device includes: Before the RAN receives the access request message, the radio access network (RAN) sends at least one supported task ID to the terminal device.

[0025] In some embodiments of the fourth aspect of the invention, the method further includes: the radioaccess network (RAN) sending the at least one supported task ID together with one or more of the following: cell ID, network ID, and tracking area ID.

[0026] The radio access network (RAN) sends the at least one supported task ID to the terminal device, including: In some embodiments of the fourth aspect of the present invention, the RAN sends to the terminal device one or more of the following: broadcast messages, unicast messages, system information, radio resource control (RRC) messages, paging messages, and dedicated signaling messages to the terminal device.

[0027] In some embodiments of the fourth aspect of the present invention, the method further includes: the RAN receiving a task data plane establishment request message from the terminal device, wherein the task data plane establishment request message is used to request the establishment of a task data plane for a first requested task, the first requested task being one of the tasks indicated by the at least one allowed task ID.

[0028] In some embodiments of the fourth aspect of the present invention, the method further includes: the RAN determining that the RAN can execute the first requested task on its own; the RAN responding to the terminal device that the task data plane has been successfully established.

[0029] In some embodiments of the fourth aspect of the present invention, the method further includes: the RAN determining that it cannot execute the first requested task on its own; the RAN sending the task data plane establishment request message to the core network (CN); the RAN receiving a task data plane establishment response message from the CN, wherein the task data plane establishment response message includes at least one of the following: the task ID of the first requested task, a subtask ID identifying a subtask involved in the first requested task and to be provided by the RAN, a work ID identifying a work involved in the first requested task and to be provided by the RAN, a task session ID identifying the task data plane, and a task context including an indication of whether the RAN should be involved in the task data plane; the RAN responding to the terminal device that the task data plane has been successfully established.

[0030] In some embodiments of the fourth aspect of the present invention, the RAN responding to the terminal device in response to the successful establishment of the task data plane includes: the RAN responding to the terminal device with one or more of the following: the task ID of the first requested task, the subtask ID identifying a subtask to be provided by the terminal device involved in the first requested task, the work ID identifying a work involved in the first requested task and to be provided by the terminal device, the task session ID identifying the task data plane, the task context including an indication of whether the terminal device should be involved in the task data plane, the radio bearer ID, and the configuration parameters on the radio bearer identified by the radio bearer ID.

[0031] A fifth aspect of the invention provides an apparatus comprising a processor for executing instructions stored in a memory, the instructions, when executed by the processor, performing the method of the fourth aspect.

[0032] A sixth aspect of the invention provides a computer-readable storage medium including instructions that, when executed by a computer, cause the computer to perform the method of the fourth aspect.

[0033] A seventh aspect of the present invention provides an initial access method, comprising: a radio access network (RAN) receiving an establishment request message from a CN, wherein the establishment request message is used to request the establishment of a task data plane for a first request task that is a network function (NF) or an application function (AF); and the RAN responding to the CN with an establishment response message indicating that the task data plane has been successfully established.

[0034] In some embodiments of the seventh aspect of the present invention, the establishment request message includes at least one of the following: a task ID of the first requested task, a subtask ID identifying a subtask involved in the first requested task and to be provided by the RAN side, a work ID identifying a work involved in the first requested task and to be provided by the RAN side, a task session ID identifying the task data plane, and a task context including an indication of whether the RAN should be involved in the task data plane.

[0035] In some embodiments of the seventh aspect of the present invention, the method further includes: the RAN requesting one or more terminal devices to establish the mission data plane.

[0036] In some embodiments of the seventh aspect of the present invention, the RAN requesting the establishment of the task data plane from the one or more terminal devices includes: the RAN determining that the task involves terminal devices; and the RAN selecting the one or more terminal devices.

[0037] In some embodiments of the seventh aspect of the present invention, the RAN requesting the establishment of the task data plane from the one or more terminal devices includes: the RAN sending to the terminal device at least one of the following: a task ID of the first requested task, a subtask ID identifying a subtask to be provided by the terminal device involved in the first requested task, a work ID identifying a work involved in the first requested task and to be provided by the terminal device, a task session ID identifying the task data plane, a task context including an indication of whether the terminal device should be involved in the task data plane, a radio bearer ID, and configuration parameters on the radio bearer identified by the radio bearer ID.

[0038] In some embodiments of the seventh aspect of the present invention, prior to the request, the method further includes: the RAN receiving a reporting message from the terminal device; the reporting message includes one or more of the following: a supported task ID identifying a task that the terminal device supports to perform, a subtask ID identifying a subtask that the terminal device supports to perform, a work ID identifying a job that the terminal device supports to perform, and the computing and communication capabilities of the UE when performing the task.

[0039] An eighth aspect of the invention provides an apparatus comprising a processor for executing instructions stored in a memory, the instructions, when executed by the processor, performing the method of the seventh aspect.

[0040] A ninth aspect of the present invention provides a computer-readable storage medium including instructions that, when executed by a computer, cause the computer to perform the method of the seventh aspect. Attached Figure Description

[0041] Other features and advantages of the present invention will become apparent from the following specific embodiments, taken in conjunction with the accompanying drawings, in which: Figure 1 A task diagram according to an embodiment is described.

[0042] Figure 2 The description corresponds to the embodiments. Figure 1 Physical task examples.

[0043] Figure 3 A block diagram of an alternative system architecture according to an embodiment is described.

[0044] Figure 4A workflow for a processing function selection method according to an embodiment is described.

[0045] Figure 5A A block diagram of a hierarchical MM according to an embodiment is described.

[0046] Figure 5B The description corresponds to the embodiments. Figure 5A The task map.

[0047] Figure 6 A workflow for another processing function selection method according to an embodiment is described.

[0048] Figure 7 A workflow for another processing function selection method according to an embodiment is described.

[0049] Figure 8 A workflow for another processing function selection method according to an embodiment is described.

[0050] Figure 9 A workflow for another processing function selection method according to an embodiment is described.

[0051] Figure 10 A workflow for selecting a method for task instantiation according to an embodiment is described.

[0052] Figure 11 A workflow for an initial access method according to an embodiment is described.

[0053] Figure 12 A workflow for another initial access method according to an embodiment is described.

[0054] Figure 13 It shows the corresponding Figure 10 The corresponding system architecture.

[0055] Figure 14 It shows the corresponding Figure 11 The corresponding system architecture.

[0056] Figure 15 It shows the corresponding Figure 12 The corresponding system architecture.

[0057] It should be noted that similar features are identified by similar reference numerals in all the accompanying drawings. Detailed Implementation

[0058] The term "anything-as-a-service" (XaaS) used herein adheres to the concepts proposed by the computer networking industry. For example, XaaS can be conceptualized as a generalized form of the Software as a Service (SaaS) or Infrastructure as a Service (IaaS) concepts. XaaS can leverage the concepts of cloud computing and device virtualization, combined with service models, to provide various functionalities. According to embodiments of the present invention, for example, XaaS can describe the functionality of any module disclosed herein as a service provided to other modules or external entities (e.g., clients). The phrase "as service" used herein is synonymous with "as a service." As the background art illustrates, a task may involve different services, each of which is considered a job. In the task processing cycle, there are multiple phases, including: the task development phase, the task deployment phase, and the task execution phase.

[0059] During the task development phase (e.g., task provision), a task map (work level) is developed to indicate the components of the task. For example, in Figure 1 In the task diagram, the task is sequentially composed of subtask 1 (including jobs 1 to 3), job 4, subtask 2 (including jobs 5 and 6), and job 4. The task diagram also shows the sequential or parallel workflows of the included subtasks and jobs. The task diagram represents the service chain of the included subtasks and jobs.

[0060] Following the task development phase, in the task deployment phase, the task graph (work level) is mapped to physical task instances (entity level). A physical task instance can consist of one or more available entities, each with the capability to perform one or more jobs involved in the task. For example, an available entity can be a service module consisting of a controller and a processing function (PF). A service module can be called an XaaS module, and a controller can be called an XaaS controller (XC). Each physical task instance can be viewed as a task slice.

[0061] For example, such as Figure 2 As shown, corresponding to Figure 1In the task graph, to instantiate the task, tasks 1 to 3 of the task are instantiated as XaaS module 1 (including XC1, three ingress PFs and one egress PF, namely in-PF1, in-PF2, in-PF3 and e-PF), XaaS module 2 (including XC2, two ingress PFs and one egress PF, namely in-PF1, in-PF2 and e-PF), and XaaS module 3 (including XC3, two ingress PFs and two egress PFs, namely in-PF, e-PF and i / e-PF, where i / e-PF is both an ingress PF and an egress PF). XaaS module 4 (including XC4, two ingress PFs and two egress PFs, i.e., in-PF1, in-PF2, e-PF1, and e-PF2), XaaS module 5 (including XC5, two ingress PFs and one egress PF, i.e., in-PF1, in-PF2, and e-PF), XaaS module 6 (including XC6, two ingress PFs and one egress PF, i.e., in-PF1, in-PF2, and e-PF), and XaaS module 7 (including XC7, two ingress PFs and one egress PF, i.e., in-PF1, in-PF2, and e-PF). The dashed arrows represent task workflows. Each work is instantiated as a work slice consisting of an XC and several PFs. In addition to the ingress PFs and egress PFs (called boundary PFs), intermediate PFs can also exist in an XaaS module to perform data processing. Figure 2 The intermediate PF is not shown in this application. We believe that the intermediate PF depends on the implementation of the XaaS module and will not be discussed in this application. The ingress PF is used to receive input data from external entities (e.g., the egress PF of the XaaS module), and the egress PF is used to output the processed data to external entities (e.g., the ingress PF of the XaaS module). The ingress PF and egress PF of the XaaS module can be the same PF.

[0062] In the mission execution phase following the mission deployment phase, when a mission needs to be executed—for example, at the request of the UE, application function (AF), network function (NF), or management plane—the control plane (e.g., mission management (MM) functions, XC) discovers, selects, connects to, and configures the PF of the mission instance to establish the mission-specific data plane. NFs include connectivity management (CM) functions and resource management (RM) functions (e.g., location-based multiple access (LOMA)). The appropriate PF for the mission instance should be selected by the control plane, taking into account communication (e.g., data forwarding) and computation (e.g., data processing) costs. It should be noted that while the appropriate PF involved in the mission is selected when the mission is to be executed, this does not preclude the selection of the appropriate PF involved in the mission when the mission is instantiated. Figure 2 As shown, an ingress PF and an egress PF are selected for each XaaS module. The control plane is configured to establish a connection between them, thereby establishing a task data plane. The PFs of two XaaS modules can be interconnected through one or more gateways (GW).

[0063] like Figure 2 As shown, different XaaS modules can connect to the same GW or different GWs. The ingress PF and egress PF of an XaaS module can also connect to the same GW or different GWs. Some GWs are controlled by the domain MM, while others are controlled by the global MM. The global MM and the domain DAM collaborate to provide services. For example, the global MM is responsible for the entire task and coordinates the domain MM, while the domain MM is responsible for subtasks or tasks. The ingress PF and egress PF of an XaaS module can be integrated (i.e., integrated PFs, e.g., the i / e-PF of XaaS module 3).

[0064] Previous research has left the following questions unanswered: When instantiating a task slice or establishing a task data plane, how does the Management Module (MM) obtain the network topology, i.e., how does the MM discover candidate boundary fields (PFs) and gatekeepers (GWs) involved in the task instance or task plane? When a task is instantiated or a task data plane is established, how does the MM select specific ingress PFs, egress PFs, and GWs? With multiple distributed MMs in the MM hierarchy, how is it determined which MM is the global MM or the domain MM? This application provides a task management method and system designed to address one or more of the above problems.

[0065] Figure 3A block diagram illustrating an embodiment of an alternative system architecture to which the present invention can be applied is shown. For example... Figure 3 As shown, the system architecture includes a radio access network (RAN), a core network (CN), and user equipment (UE). The XaaS module is deployed on both the RAN and CN sides.

[0066] MMs are deployed hierarchically. For example, there are global MMs and domain MMs. This hierarchy can originate from a task hierarchy (e.g., tasks under the control of a global MM and subtasks under the control of a domain MM) or a network management hierarchy (e.g., RAN and CN). A domain refers to a management domain or a task management domain. For example, MMs can be deployed in the RAN and CN respectively, i.e., RAN-MM and CN-MM. Global MMs and domain MMs can reside in the same network domain or in different network domains. For example, both MMs can reside in the CN, i.e., CN-MM, or both can reside in the RAN, i.e., RAN-MM, or one can reside in the RAN and the other in the CN. RAN-MM can be a domain MM, and CN-MM can be a global MM; or RAN-MM can be a global MM, and CN-MM can be a domain MM.

[0067] Within each XaaS module, there is one XC and one or more PFs. The XC connects to the PF via a T1 interface. Some PFs in the XaaS module are boundary PFs (e.g., ingress PF, egress PF) to connect to external entities.

[0068] The data plane gateway (GW) can be deployed in the RAN and CN. The RAN-GW connects to the RAN-PF via the M5 interface, to the RAN-GW via the M4 interface, to the RAN node via the M2 interface, and to the CN-GW via the T3 interface. The CN-GW connects to the CN-PF via the T5 interface, to the CN-GW via the T4 interface, and to the DN via the T6 interface. Integrated RAN nodes or separate RAN nodes can be deployed.

[0069] If an integrated RAN node is deployed (e.g., no CU or DU deployed): the RAN node connects to the XC via the M2-C interface, to the GW via the M2-U interface, to the PF via the M2-U and M5 interfaces, to the RAN-MM via the T7 interface, to the CN-MM via the T8 interface, to the CN-GW via the T3 interface, and to the UE via a radio link.

[0070] If a split RAN node is deployed (e.g., a CU and a DU): the split part of the RAN node (e.g., the DU) is connected to the XC via the M2-C interface, to the GW via the M2-U interface, to the PF via the M2-U and M5 interfaces, and to the UE via a radio link; the other part of the RAN node (e.g., the CU) is connected to the XC via the M2-C interface, to the GW via the M2-U interface, to the PF via the M2-U and M5 interfaces, to the RAN-MM via the T7 interface, to the CN-MM via the T8 interface, and to the CN-GW via the T3 interface.

[0071] The RAN-GW can connect directly to the CN-GW via the T3 interface, or indirectly via a RAN node. The GW is optional; for example, it can be deployed if no GW is currently deployed in the RAN. RAN nodes can connect directly to the CN-GW via the T3 interface.

[0072] PFs (i.e., boundary PFs and intermediate PFs) within an XaaS module are internally connected via the T2 interface. PFs (i.e., boundary PFs) deployed in different XaaS modules are interconnected via one or more GWs or directly. For example, on the CN side, PFs deployed in different XaaS modules can be interconnected via one or more GWs. On the RAN side, PFs deployed in different XaaS modules are directly interconnected via the T2 interface, but it is not excluded that RAN-PFs deployed in different XaaS modules can be interconnected via GWs.

[0073] The RAN-PF can connect to the CN-GW via intermediate M5 and T3 interfaces, or via intermediate M5, M2, and T3 interfaces. If no GW is deployed in the RAN, the RAN-PF can connect directly to the CN-GW, or via intermediate RAN nodes.

[0074] MM connects to XC via the T9 interface.

[0075] Hierarchical MMs are interconnected directly via the T10 interface or through intermediate entities. For example, hierarchical MMs in the same domain (e.g., all in the CN) can be interconnected directly via the SBI interface or via the T10 interface; hierarchical MMs in the same domain (e.g., all in the RAN) can be interconnected via RAN nodes. Hierarchical MMs in the same domain (e.g., all in the CN) can be interconnected directly or via network functions (e.g., CM). Hierarchical MMs in different domains (e.g., RAN-MM and CN-MM) can be interconnected via RAN nodes (i.e., via intermediate T8 and T7 interfaces) or directly via the T10 interface.

[0076] Some of the aforementioned entities can be integrated; for example, RAN nodes and XaaS modules on the RAN side can be integrated.

[0077] The UE in this application is a type of terminal device. This terminal device can be a device providing data connectivity to a user, a handheld device with wireless connectivity, or a wireless device. The terminal device can communicate with one or more CNs via the RAN. The terminal device can be a mobile terminal such as a mobile phone (also known as a "cellular" phone), or a computer with a mobile terminal, for example, a portable computer, pocket computer, handheld computer with built-in mobile device, or vehicle-mounted mobile device that exchanges voice and / or data with the radio access network. For example, the terminal device can be a personal communication service (PCS) phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a wireless local loop (WLL) station, or a personal digital assistant (PDA). The terminal device can also be referred to as a user unit, user station, mobile station, remote station, access point, remote terminal, access terminal, user terminal, user agent, user equipment, UE, smartphone, automotive equipment, or Internet of Things (IoT) device.

[0078] A RAN can be a form of radio station, a wireless transceiver station that transmits information between a mobile communication switching center and mobile phone terminals within a specific wireless coverage area. It can also be a device in an access network that communicates with terminal devices over the air interface through one or more sectors. The RAN can be used to convert between received air frames and Internet Protocol (IP) messages, acting as a router between the terminal device and the rest of the access network. The rest of the access network may include an Internet Protocol (IP) network. The RAN can also coordinate attribute management over the air interface. For example, the RAN can be a base station, such as a base transceiver station (BTS), a NodeB, an evolved NodeB (eNB), etc. This application does not limit this.

[0079] This application provides a method for selecting processing functions. Figure 4 An embodiment of the workflow of the processing function selection method according to the present invention is shown. Figure 5A An example of a hierarchical MM is shown. Figure 5B It shows the corresponding Figure 5A An example of a task graph. See also... Figure 4 , Figure 5A and Figure 5B The method includes: Step 401: The mission management (MM) function obtains a list of processing function identifiers (PF IDs) from the service controller. The PF ID list includes one or more PF IDs, each of which is used to indicate a PF, and each of these PFs is connected to a service controller.

[0080] See Figure 5A In XaaS module 1, in-PF1, in-PF2, e-PF1 and e-PF2 are connected to service controller XC1, and in XaaS module 2, in-PF1, in-PF2 and e-PF are connected to service controller XC2.

[0081] In some embodiments, the list of PF IDs is carried in a registration request message sent from the service controller. See also Figure 4 XC1 sends a registration request message to MM, which includes a list of PF IDs, comprising at least one of the following: the ID of in-PF1, the ID of in-PF2, the ID of e-PF1, and the ID of e-PF2. It is understood that this application is not limited to multiple XaaS modules; there may also be only one XaaS module, for example, only XaaS module 1 sending the PFID list to MM. When there is more than one XaaS module, each XC can send a registration request message separately. For example, XC2 sends another registration request message to MM, which includes a list of PF IDs, comprising at least one of the following: the ID of in-PF1, the ID of in-PF2, and the ID of e-PF in XaaS module 2.

[0082] In some embodiments, the MM also acquires processing function attributes corresponding to the PF. Processing function attributes can be included in the registration request message. PF attributes include the PF type (e.g., ingress PF, egress PF), the job ID supported by each PF, the location of each PF (e.g., cell, network, tracking area, geographic region), the capabilities of each PF (e.g., data processing capabilities, computing capabilities, and communication capabilities), and the input and output data formats supported by each PF. See also Figure 5AThe PF attributes corresponding to XaaS module 1 include: the type of each of the four PFs, the job IDs supported by each of the four PFs, the location of each of the four PFs, and the capabilities of each of the four PFs (e.g., data processing capabilities, computing capabilities, and communication capabilities). Supported job IDs include the IDs of the jobs that each of the four PFs can perform. For example, supported job IDs include the ID of job 1. PF attributes can be included in the registration request message. The PF attributes corresponding to XaaS module 2 include: the type of each of the three PFs, the job IDs supported by each of the three PFs, the location of each of the three PFs, and the capabilities of each of the three PFs. Supported job IDs include the IDs of the jobs that each of the three PFs can perform. For example, supported job IDs include the ID of job 2. PF attributes can be included in the registration request message. The registration request message may also include the ID of XC; for example, a registration request message sent from XC1 including the ID of XC1 can be represented as XC ID1. It should be noted that... Figure 5A and Figure 5B The diagram illustrates the mapping between XCs and jobs; for example, XC1 supports job 1, and XC2 supports job 2. In practice, the MM can control more than two XCs; for example, the MM also controls XC3 and XC4. XC3 and XC4 can also send registration request messages to the MM and provide a list of PF IDs. Furthermore, XC3 and XC4 may not support jobs 1 and 2. The MM can know which XC supports which job, thus determining which XC performs which job. For example, based on information received from XC1 to XC4, the MM determines that XC1 performs job 1 and XC2 performs job 2.

[0083] Step 402: The MM selects one or more PFs from the list. In step 402, when the MM receives the list of PFs from each of these XCs, the MM can select an ingress PF and an egress PF for the XC. See also Figure 5A and Figure 5B XC1 and XC2 send PF lists respectively. MM selects in-PF2 and e-PF in XaaS module 1 for XC1 and in-PF1 and e-PF in XaaS module 2 for XC2. Therefore, the processing of work 1 can involve in-PF2 and e-PF in XaaS module 1, and the processing of work 2 can involve in-PF1 and e-PF in XaaS module 2.

[0084] Step 403: The MM sends one or more PF IDs of the selected PFs to the service controller. In step 403, when the MM selects a PF from the list, the MM sends the PF ID of the selected PF to the XC. For example, the MM sends the ID of the in-PF2 and the e-PF of XaaS module 1 to XC1, and the MM sends the ID of the in-PF1 and the e-PF of XaaS module 2 to XC2.

[0085] In some embodiments, one or more PF IDs of one or more selected PFs are carried in a message, for example, in a requirement message, which may be a task data plane establishment requirement message or a task instantiation requirement message, and the MM sends the message to XC1 and XC2 respectively.

[0086] In some embodiments, the MM also selects a GW to be connected to the selected PF for the XC. The MM selects the GW based on the attributes of each GW under the MM. The attributes of each GW can be obtained from control plane functions, including the XC, or other functions. The attributes of the GW include GW load or GW location. Considering the efficiency of communication (e.g., data forwarding) and computation (e.g., data processing), the MM selects both the boundary PF and the GW.

[0087] In some embodiments, the message (e.g., a task data plane establishment request message or a task instantiation request message) further includes at least one of the following: a task ID, a job ID, and a selected GW corresponding to the selected PF. Each XC configures the selected PF to establish a connection with the selected GW. The selected GW is configured by the MM to establish a connection with the selected PF. When the MM sends a task data plane establishment request message to XC1, the task ID is the ID of task 1, and the job ID is the ID of job 1. When the MM sends a task data plane establishment request message to XC2, the task ID is the ID of task 1, and the job ID is the ID of job 2.

[0088] In some embodiments, the method further includes steps 404 and 405.

[0089] Step 404: The MM receives a message from the UE, AF, NF, or management plane (e.g., operations, administration and maintenance (OAM)). This message may be a task data plane establishment request message or a task instantiation request message, and it includes the task ID. The NF includes connectivity management (CM) functions and resource management (RM) functions (e.g., location-based multiple access (LOMA)). Figure 5A and Figure 5B For example, the task ID is the ID of task 1. Task 1 can be split into multiple jobs, such as job 1 and job 2, and each job is uniquely identified by a job ID (e.g., job ID1 and job ID2).

[0090] Step 405: The MM retrieves the task graph or task instance information corresponding to the task ID from local storage or from the Mission Data Repository (MDR) (e.g., retrieving the task graph during the task instantiation phase, and retrieving the task instance information during the task data plane establishment phase). The task graph or task instance information indicates the work involved in the task, and each work is identified by a work ID. The MM obtains the work ID based on the task graph or task instance information and the task ID obtained from the UE, AF, NF, or management plane. For example, the work ID includes... Figure 5B The IDs of job 1 and job 2 are specified, i.e., job ID1 and job ID2. Steps 404 and 405 can occur before or after any one or more of steps 401 to 403. In some embodiments, the order of these steps can be: steps 401, 404, 405, 402, and 403.

[0091] Figure 6 Another embodiment of the workflow of the processing function selection method according to the present invention is shown. Figure 6 Implementation examples and Figure 4 The implementation examples are similar, Figure 4 and Figure 6 The difference is: in Figure 4 In the middle, XC registers directly with MM, while... Figure 6 In this process, XC registers with network functions (e.g., network repository function, NRF). Figure 4 and Figure 6 Similar details will not be elaborated further. The method includes: Step 601: The service controller sends a registration request message to a network function (e.g., a network repository function, NRF). This service controller could be... Figure 5A The XC1 in the network function (XC1) is used for registration request messages. The registration request message includes a list of PF IDs, where each PF ID includes the ID of a PF connected to the XC1. For example, the PF ID list may include at least one of the following: the ID of in-PF1, the ID of in-PF2, the ID of in-PF3, and the ID of e-PF. Optionally, the PF ID list sent by the XC1 to a network function (e.g., NRF) may include the IDs of all PFs connected to the XC1. Similar to step 401, more than one service controller may send a registration request message to the MM; for example, some or all of the service controllers controlled by the MM may send a registration request message to the MM. The network function in the application supports maintaining configuration files of other available network functions (e.g., MM) in the network and supports service discovery. It supports receiving network function discovery requests from network functions and providing network functions with information about discovered network functions (discovery) (sending a discovery request). The network function may be deployed in a CN or RAN. The network function may be an existing 5G network function, such as a network repository function (NRF) or other existing network functions, or a newly defined 6G network function. The following steps are illustrated using an NRF as an example.

[0092] In some embodiments, the registration request message further includes a processing function attribute corresponding to the PF, the specific content of which can be found in step 401. The registration request message also includes the ID of the XC, for example, the ID of XC1. For example, in... Figure 5A and Figure 5B In the process, XC1 sends a list of PF IDs to a network function (e.g., NRF), which includes the PF ID of each of the four PFs connected to XC1, the working ID supported by each of the four PFs connected to XC1, and XC1's XC ID. XC2 sends a list of PF IDs to a network function (e.g., NRF), which includes the PF ID of each of the three PFs connected to XC2, the working ID supported by each of the three PFs connected to XC2, and XC2's XC ID.

[0093] Step 602: The MM receives a message from the UE, AF, NF, or management plane, such as a request message, which may be a mission data plane establishment request message. Details of step 602 can be found in step 404.

[0094] Step 603: The MM retrieves the task graph or task instance information. Details of step 603 can be found in step 405. For example, the MM retrieves the task graph or task instance information indicating that the task involves job 1 (identified by job ID1) and job 2 (identified by job ID2).

[0095] Step 604: The MM sends the job IDs (e.g., job ID1 and job ID2) obtained in step 603 to the network function (e.g., NRF), where these job IDs can be included in a message, such as an XaaS module discovery request message.

[0096] Step 605: The NRF (from the list of PFs received in step 601) selects PFs whose supported job IDs fully or partially overlap with job ID1 or job ID2 received in step 604. For example, if in-PF1, in-PF2, and e-PF of XaaS module 1 support at least job 1, and in-PF3 does not support job 1 or job 2, then the NRF will select in-PF1, in-PF2, and e-PF from the PF list and send these selected PF IDs to the MM. In other words, the NRF receives job IDs (job 1 and job 2) from the MM, and receives a list of PF IDs for each service controller in one or more service controllers controlled by the MM, as well as the job IDs supported by these PFs. Therefore, the NRF knows which PFs support job 1 and which PFs support job 2, and sends this information to the MM. Thus, if a PF does not support either job 1 or job 2, the PF will not be selected by the NRF, and the NRF will not send information about that PF to the MM.

[0097] Step 606: The MM receives a response message from the NRF, which includes a list of PF IDs. This list identifies the PFs selected by the NRF in step 605. In other words, the list of PF IDs sent by the NRF to the MM consists of the PF IDs of the PFs selected by the NRF. For example, the PF IDs of in-PF1, in-PF2, and e-PF of XaaS module 1 are in the PF ID list, while the PF ID of in-PF3 is not.

[0098] In some embodiments, the response message further includes at least one of the following: one or more job IDs, one or more XC IDs, and attributes of the PF, wherein the one or more XC IDs identify one or more XCs controlling the PF. For example, in a response message sent to XC1, the NRF includes the PF ID of the PF selected by the NRF from a list of PFs connected to XC1, an overlapping job ID (e.g., job ID1), and the XC ID of XC1. Similarly, in a response message sent to XC2, the NRF includes the PF ID of the PF selected by the NRF from a list of PFs connected to XC2, an overlapping job ID (e.g., job ID2), and the XC ID of XC2.

[0099] Step 607: The MM selects one or more selected PFs from the PFs previously selected by the NRF. Details of step 607 can be found in step 402.

[0100] Step 608: The MM sends one or more PF IDs of one or more selected PFs to the service controller. Details of step 608 can be found in step 403.

[0101] Figure 7 Another embodiment of the workflow of the processing function selection method according to the present invention is shown. Figure 7 Implementation examples and Figure 4 , Figure 6 The implementation examples are similar, Figure 4 , Figure 6 and Figure 7 The difference is: in Figure 4 In the process, XC sends a list of PF IDs to MM, which includes some or all of the PFs connected to XC. MM selects a PF from the list. Figure 6 In the process, XC sends a list of PF IDs to a network function (e.g., NRF), which includes some or all of the PFs connected to XC. The network function (e.g., NRF) selects one or more or all of the PFs in the list. The NRF sends the PFs selected by the NRF to the MM, and the MM selects a PF from the PFs previously selected by the NRF. Figure 7 In this process, XC identifies one or more candidate PFs from some or all of the PFs connected to XC, and XC sends the IDs of the candidate PFs to MM. Alternatively, XC directly sends a list of PF IDs, including the IDs of the candidate PFs, to MM. Figure 7In this method, the XC can register with the MM or a network function (e.g., an NRF). When the XC registers with the MM, it sends a list of job IDs to the MM, which includes the IDs of jobs that a PF connected to the XC can perform, but does not send the PF IDs of the PFs connected to the XC. When the XC registers with the NRF, it sends a list of job IDs to the NRF, which includes the IDs of jobs that a PF connected to the XC can perform, and the MM can obtain the list of job IDs from the NRF. The method includes: Step 701: The Service Controller (XC) sends a registration request message to the MM or Network Function (e.g., NRF), wherein the registration request message includes supported job IDs, which include the IDs of jobs that the PF connected to the Service Controller can perform. Figure 5A For example, the PFs connected to XC1 include in-PF1, in-PF2, in-PF3, and e-PF. The supported job IDs can include the IDs of all jobs supported by these four PFs. Similar to step 401, some XCs controlled by the MM, or all XCs controlled by the MM, can send a registration request message to the MM or NRF. The MM or NRF can then obtain information about the job IDs supported by each XC. The network function can be an existing 5G network function, such as a network repository function (NRF) or other existing network functions, or it can be a newly defined 6G network function. The following steps are illustrated using an NRF network function as an example.

[0102] Step 702: The MM receives a message from the UE, AF, NF, or management plane, such as a request message, which may be a task data plane establishment request message. This message includes a task ID, for example, the task ID is the ID of task 1. Task 1 can be divided into multiple jobs, such as job 1 and job 2, each job being uniquely identified by a job ID (e.g., job ID1 and job ID2). Details of step 702 can be found in step 404.

[0103] Step 703: The MM retrieves the task graph or task instance information. Details of step 703 can be found in step 405. The MM obtains the job ID (e.g., job ID1 and job ID2) based on the task graph or task instance information and the task ID obtained from the UE, AF, NF, or management plane. When an XC registers directly with the MM, the MM determines which XC corresponds to which job based on the job ID and the job IDs supported by each XC. For example, the MM determines that XC1 corresponds to job 1, and then executes step 706 after this step. When an XC registers with the NRF, the information on the job IDs supported by each XC is obtained by the NRF, therefore steps 704 and 705 are executed.

[0104] Step 704: The MM sends the job IDs obtained in step 703 to the NRF. These job IDs can be included in messages, such as XaaS module discovery request messages. When the NRF receives the job IDs from the MM, it determines which XC corresponds to which job based on the job ID and the job IDs supported by the XC. For example, the NRF determines that XC1 corresponds to job 1. Then, the NRF sends the job ID and XC ID to the MM. The XC ID identifies the XC that can provide the job identified by the job ID.

[0105] Step 705: The MM receives a response message from the NRF, which includes a job ID and an XC ID, the XC ID identifying the XC that can perform the job identified by the job ID. Based on the information included in the response message, the MM is notified of the ID of the XC that can perform the job identified by the job ID.

[0106] Step 706: The MM sends the task ID and / or job ID to the corresponding service controller (e.g., XC1 and / or XC2). For example, the MM sends the task ID of task 1 and the job ID of job 1 to XC1. The task ID and job ID are used by the XC to select candidate PFs. The task ID and job ID can be included in a message, such as a requirement message, which can be a task data plane establishment requirement message.

[0107] Step 707: The service controller (e.g., XC1 and / or XC2) selects candidate PFs from all PFs connected to XC based on the task ID, job ID, and attributes of all PFs connected to XC. For example, if XC1 determines that in-PF1, in-PF2, and e-PF can support the job indicated by the job ID based on the job ID and PF attributes, then XC1 selects in-PF1, in-PF2, and e-PF as candidate PFs.

[0108] Step 708: The MM receives the IDs of the candidate PFs from the XC. The IDs of the candidate PFs may be included in a response message, such as a task data plane establishment response message. In some embodiments, the task data plane establishment response message may also include at least one of the following: the processing function type (e.g., ingress PF, egress PF) of each of the candidate PFs, the job ID supported by each of the candidate PFs, the location (e.g., cell, network, tracking area, geographic region) of each of the candidate PFs, the capabilities (e.g., data processing capabilities, computing capabilities, and communication capabilities) of each of the candidate PFs, and the input and output data formats supported by each of the candidate PFs.

[0109] Step 709: The MM selects one or more selected PFs from the received candidate PFs. In some embodiments, the MM selects one or more selected PFs and GWs simultaneously based on the attributes of the candidate PFs and the attributes of the GW.

[0110] Step 710: The MM sends one or more PF IDs of one or more selected PFs to the XC. In some embodiments, one or more PF IDs of one or more selected PFs are carried in a message, such as a task data plane update request message.

[0111] It should be noted that, in Figure 7 In one embodiment, steps 704 and 705 can be skipped when XC registers with MM.

[0112] Figure 8 Another embodiment of the workflow of the processing function selection method according to the present invention is shown. Figure 8 The embodiments describe a processing function selection method with a hierarchical MM. See also Figure 1 and Figure 2 Hierarchical task managers (MMs) include two types: global MMs and domain MMs. Global MMs are responsible for the entire task, while domain MMs are responsible for subtasks or tasks. It should be noted that... Figures 4 to 7 The content of the embodiments can be incorporated into this embodiment. Therefore, this embodiment will not repeat the same details. The processing function selection method includes: Step 801: The first MM or network function (e.g., NRF) acquires at least one processing function ID indicating at least one processing function, wherein the at least one processing function is connected to one or more service controllers. The network function can be an existing 5G network function, such as a network repository function (NRF) or other existing network functions, or it can be a newly defined 6G network function. The following steps are illustrated using an NRF as an example. One or more service controllers can send a second registration request message to the first MM or NRF, the second registration request message including one or more PF IDs indicating at least one PF connected to the corresponding service controller. The first MM can be a domain MM. See also Figure 1 and Figure 2The first MM can be either the domain MM responsible for handling subtask 1 or the domain MM responsible for handling subtask 2. Taking the first MM as the domain MM responsible for handling subtask 2 as an example, the service controller can be XC5 and / or XC6. XC5 sends a second registration request message to the domain MM, which includes the PF ID of the PF connected to XC5, such as the PF IDs of in-PF1, in-PF2, and e-PF in XaaS module 5. XC6 can also send a second registration request message to the domain MM, which includes the PF IDs of in-PF, e-PF1, and e-PF2 in XaaS module 6.

[0113] When the service controller registers directly with the first MM, the service controller sends a second registration request message to the first MM, and the first MM directly obtains the PF ID from the service controller. When the service controller registers with the NRF, the service controller sends a second registration request message to the NRF, and the first MM obtains one or more PF IDs from the PF IDs through the NRF (see steps 605 and 606). In some embodiments, the second registration request message also includes PF attributes, which include the PF type of each PF (e.g., ingress PF, egress PF), the job ID supported by each PF, the location of each PF (e.g., cell, network, tracking area, geographic region), the capabilities of each PF (e.g., data processing capabilities, computing capabilities, and communication capabilities), and the input and output data formats supported by each PF.

[0114] Step 802: The first MM retrieves the subtask graph or subtask information corresponding to the subtask identified by the subtask ID from local storage or the Mission Data Repository (MDR). (The subtask graph is retrieved during the subtask instantiation phase, and the subtask information is retrieved during the subtask data plane establishment phase.) The subtask graph or subtask information indicates the work involved in the subtask, and each work is identified by a work ID. The first MM obtains the work ID based on the subtask graph or subtask instance information. In this step, the first MM can obtain the subtask ID and work ID by retrieving the subtask graph. The subtask ID identifies the subtask supported by the first MM, and the work ID identifies the work involved in the subtask.

[0115] Step 803: If the service controller (e.g., XC5 and / or XC6) registers with the first MM, then for a specific subtask supported by the first MM, the first MM can determine which XC supports the work involved in that subtask, and then the first MM selects a PF for that XC. Specifically, the first MM selects one or more selected PFs from at least one PF, the ID of which is received from the service controller (e.g., XC5 and / or XC6). If the service controller (e.g., XC5 and / or XC6) registers with the NRF, then the first MM selects one or more selected PFs from one or more PF IDs obtained from the service controller via the NRF (see steps 604 to 606, where the first MM sends the work ID identifying the work involved in a specific subtask to the NRF, and the NRF selects PFs that can support these work based on the information received in step 801, and sends the PF IDs of these PFs to the first MM). It should be noted that, based on the subtask graph, the first MM can support more than one subtask, and the first MM can obtain some work IDs identifying the work involved in one subtask and some other work IDs identifying the work involved in another subtask. This step and subsequent steps take one of the subtasks supported by the first MM as an example; other subtasks supported by the first MM have the same process.

[0116] In some embodiments, when the first MM receives a PF ID from the service controller or NRF, the first MM arranges the PFs sequentially based on the order of the jobs involved in a specific subtask supported by the MM, and selects one or more PFs based on the PF order. Specifically, the order of the jobs involved in the subtask can be understood as the processing order of the jobs. For example, when executing subtask 2, job 5 will be executed before job 6, so the order of the jobs is job 5 and job 6. In some embodiments, when arranging the PFs sequentially, all in-PFs can be arranged together, and all e-PFs can be arranged together. Based on the order of job 5 and job 6, the order of in-PFs is: in-PF1 of XaaS module 5, in-PF2 of XaaS module 5, and in-PF of XaaS module 6; the order of e-PFs is: e-PF of XaaS module 5, e-PF1 of XaaS module 6, and e-PF2 of XaaS module 6.

[0117] In some embodiments, the first MM selects all ingress PFs of the first involved XaaS module and all egress PFs of the last involved XaaS module as one or more selected PFs. For example, the first MM selects in-PF1, in-PF2 of XaaS module 5, e-PF1 and e-PF2 of XaaS module 6 as one or more selected PFs.

[0118] Step 804: The first MM sends the PF IDs of one or more selected PFs to the second MM. There are two options for sending the PF IDs to the second MM: Option 1: The first MM directly sends the PF IDs of one or more selected PFs to the second MM, and the first MM sends a first registration request message to the second MM, i.e., the first MM registers with the second MM. The first registration request message includes the PF IDs of one or more selected PFs. In some embodiments, the first registration request message also includes the subtask IDs and processing function attributes of the subtasks supported by the first MM. These processing function attributes include at least one of the following: the processing function type of each of the one or more selected PFs (e.g., ingress PF, egress PF), the subtask IDs and / or job IDs supported by each of the one or more selected PFs, the location of each of the one or more selected PFs (e.g., cell, network, tracking area, geographic region), the capabilities of each of the one or more selected PFs (e.g., data processing capabilities, computing capabilities, and communication capabilities), and the input and output data formats supported by each of the one or more selected PFs.

[0119] Option 2: The first MM sends the PF IDs of one or more selected PFs to the second MM via the NRF. In this option, the first MM registers with the NRF and sends the PF IDs of one or more selected PFs to the NRF. The PF IDs of the one or more selected PFs can be included in the first registration request message. In some embodiments, the first registration request message also includes a subtask ID and processing function attributes, which include at least one of the following: processing function type, supported job ID, location, capability, input data format supported by the processing function, and output data format. In Option 2, the method further includes steps 806 and 807 (steps 806 and 807 can be skipped in Option 1).

[0120] Step 805: The second MM receives a message from the UE, AF, NF, or management plane (e.g., OAM), such as a request message. This request message may be a mission data plane establishment request message, including a mission ID indicating the task the UE, AF, NF, or OAM requests the network to perform. NFs include CM, RM, etc. The second MM retrieves the mission graph or mission instance information corresponding to the mission ID from local storage or from the Missiondata Repository (MDR) (retrieving the mission graph during the mission instantiation phase and the mission instance information during the mission data plane establishment phase). The mission graph or mission instance information indicates one or more subtasks and / or one or more jobs involved in the mission, each subtask identified by a subtask ID. In some embodiments, the mission graph or mission instance information not only indicates one or more subtasks but also one or more jobs involved in the mission, each job identified by a job ID. That is, one or more jobs involved in the mission can be provided by an XaaS module directly controlled by the second MM, rather than the first MM. In this embodiment, the second MM is a global MM. For example, the second MM receives... Figure 1 The task ID of the task in the middle, the second MM calls the task graph or task instance information to get the subtask IDs of subtask 1 and subtask 2, and get the work IDs of work 4 and work 7.

[0121] Step 806: The second MM sends one or more subtask IDs and / or one or more job IDs obtained in step 805 to the NRF. The one or more subtask IDs and / or one or more job IDs may be included in the XaaS module discovery request message.

[0122] Step 807: The NRF sends a response message to the second MM. For example, the XaaS module discovers the response message. This message includes: one or more subtask IDs received in step 806, one or more domain MM IDs identifying one or more domain MMs (which support the execution of one or more subtasks identified by the one or more subtask IDs), and PF IDs of one or more selected PFs, as well as PF attributes. The PF ID can identify the PF of the subtask identified by the one or more subtask IDs, and the one or more domain MM IDs identify the one or more domain MMs where the PF resides. For example, if the first MM is a domain MM supporting subtask 1 and another domain MM supports subtask 2, then the domain MM IDs of the first MM and the other domain MM supporting subtask 2 would be included in the message.

[0123] Step 808: The second MM selects one or more boundary PFs from one or more selected PFs. Based on the attributes of the PFs under the first MM and at least one of the following: attributes of the GWs under the first MM and / or the second MM (e.g., GW load, GW location), and the attributes of the PFs under the second MM, considering communication (e.g., data forwarding) and computation (e.g., data processing) efficiency, the second MM may simultaneously select PFs under the first MM and GWs under the second MM. For example, the second MM selects in-PF1 of XaaS module 5 and e-PF2 of XaaS module 6 as boundary PFs.

[0124] Step 809: The first MM receives one or more boundary PF IDs of one or more boundary PFs from the second MM. In some embodiments, the second MM sends a message to the first MM, such as a command message, which may be a task data plane establishment command message. The message includes at least one of the following: one or more boundary PF IDs of one or more boundary PFs, a task ID, a subtask ID, and a GW ID of a selected GW issued by the second MM to the first MM.

[0125] In some embodiments, after receiving one or more boundary PF IDs, based on the boundary PF and / or GW selected by the second MM, the first MM continues to select the GW under the first MM, and selects the intermediate PF of the subtask (e.g., the exit PF of the first involved XaaS module, the ingress PF of the last involved XaaS module, and the ingress and exit PFs of the intermediate XaaS modules). For example, the first MM selects the e-PF of XaaS module 5 and the in-PF of XaaS module 6 as intermediate PFs.

[0126] Step 810: The first MM sends one or more boundary PF IDs of one or more boundary PFs to the service controller. Optionally, the first MM also sends intermediate PFs and GWs under the first MM to the service controller. For example, the first MM sends the PF IDs of in-PF1 and e-PF of XaaS module 5 to XC5, and the first MM sends the PF IDs of in-PF and e-PF2 of XaaS module 6 to XC6. In some embodiments, the first MM sends a message to the service controller, such as a request message, which may be a task data plane establishment request message, including one or more boundary PF IDs, and also including one or more subtask IDs and one or more job IDs.

[0127] In some embodiments, each XC configures the PF selected by the first MM and establishes a connection between the PF and the GW.

[0128] Figure 9Another embodiment of the workflow of the processing function selection method according to the present invention is shown. Figure 9 An embodiment describes a processing function selection method with a hierarchical MM. This processing function selection method includes: Step 901: The service controller sends a second registration request message to the first MM or network function (e.g., NRF), wherein the second registration request message includes supported job IDs, which include the IDs of jobs that the PF under the service controller can perform. Similar to step 801, the first MM can be a domain MM. When the service controller registers directly with the first MM, the service controller sends a second registration request message to the first MM, and the first MM directly obtains the supported job IDs from the service controller. The network function can be an existing 5G network function, such as a network repository function (NRF) or other existing network functions, or it can be a newly defined 6G network function. The following steps are illustrated using an NRF as an example. When the service controller registers with the NRF, the service controller sends a second registration request message to the NRF, and the first MM obtains the supported job IDs from the service controller through the NRF. The service controller can be... Figure 2 Any service controller in the system, for example, the service controller can be one or more XCs from XC1 to XC3, in which case the service controller will send... Figure 2 The leftmost domain MM sends a second registration request message; this leftmost domain MM is the first MM. The service controller can be XC5 and / or XC6, in which case the service controller will send... Figure 2 The rightmost domain MM sends a second registration request message; this rightmost domain MM is the first MM.

[0129] Step 902: The first MM invokes the subtask graph or subtask information. Details of this step can be found in step 802. In this step, the first MM can obtain the subtask ID and job ID by invoking the subtask graph. The subtask ID identifies the subtasks supported by the first MM, and the job ID identifies the jobs involved in the subtasks. For example, the first MM is... Figure 2 The leftmost MM. See also Figure 1 The first MM supports subtask 1, the subtask ID indicates subtask 1, and the job ID indicates job 1, job 2 and job 3.

[0130] Step 903: The first MM sends a message, for example, a first registration request message, to the second MM or the NRF. When the first MM registers with the second MM, the first MM sends a first registration request message to the second MM; when the first MM registers with the NRF, the first MM sends a first registration request message to the NRF, which includes the subtask ID obtained in step 902.

[0131] Step 904: The second MM receives a message from the UE, AF, NF, or management plane (e.g., OAM), such as a request message. This request message may be a task data plane establishment request message, which includes a task ID indicating the task that the UE, AF, NF, or OAM requests the network to perform. Details of this step can be found in step 805. The method further includes steps 905 and 906 when the first MM registers with the NRF; otherwise, steps 905 and 906 can be skipped.

[0132] Step 905: The second MM sends one or more subtask IDs and / or one or more job IDs obtained in step 904 to the NRF. The one or more subtask IDs and / or one or more job IDs may be included in the XaaS module discovery request message.

[0133] Step 906: The NRF sends a message to the second MM, for example, an XaaS module discovery response message, which includes: one or more subtask IDs received in step 905, and one or more domain MM IDs identifying one or more domain MMs (the one or more domain MMs support the execution of one or more subtasks identified by the one or more subtask IDs). Details of this step can be found in step 807.

[0134] After performing the above steps, the second MM obtains the supported subtask IDs of the subtasks supported by the first MM. Furthermore, the second MM can also obtain the supported subtask IDs of subtasks supported by other domain MMs. By accessing the task graph or task instance information, the second MM also obtains the task ID of the task requested by the UE, AF, NF, or OAM to be executed by the network, and the subtask IDs of the subtasks involved in the task. Based on the information of the supported subtask IDs and the subtask IDs of the subtasks involved in the task requested by the UE, AF, NF, or OAM, the second MM can determine which domain MM supports which subtasks involved in the task. For example, the second MM will know that the first MM can support subtask 1 involved in the task.

[0135] Step 907: The first MM receives a message from the second MM, such as a command message. The command message may be a task data plane establishment command message. The message includes a task ID and a subtask ID. The subtask ID identifies the subtask that the first MM needs to execute. In other words, the first MM supports the subtask and the task involves the subtask.

[0136] Step 908: The first MM retrieves the subtask graph or subtask instance information from its local memory or MDR (the subtask graph is retrieved during the subtask instantiation phase, and the subtask instance information is retrieved during the subtask data plane establishment phase), wherein the subtask graph or subtask instance information indicates the work involved in the subtasks identified by the subtask IDs received in step 907, and each work is identified by a work ID.

[0137] Step 909: The first MM sends a subtask ID and a job ID to the service controller, where the service controller supports one or more jobs identified by the job ID. The subtask ID and job ID are included in a message, such as a request message, which may be a task data plane establishment request message. The task data plane establishment request message is used by the service controller to select candidate processing functions. For example, the first MM sends the ID of subtask 1 and the ID of job 1 to XC1, the first MM sends the ID of subtask 1 and the ID of job 2 to XC2, and the first MM sends the ID of subtask 1 and the ID of job 3 to XC3.

[0138] Step 910: The service controller selects candidate PFs from those connected to it. For example, the service controller selects candidate PFs based on the subtask ID, job ID, and attributes of the PFs connected to it, received from the first MM. For example, if the service controller is XC1, and the subtask ID received in step 909 indicates subtask 1, and the job ID received in step 909 indicates job 1, then XC1 determines that in-PF1, in-PF2, and e-PF can support job 1, and then XC1 selects in-PF1, in-PF2, and e-PF as candidate PFs.

[0139] Step 911: The first MM receives the ID of the candidate PF from the service controller. The ID of the candidate PF may be included in a message, such as a response message, which may be a task data plane establishment response message. In some embodiments, the response message further includes at least one of the following: a subtask ID, a job ID, and attributes of the candidate PF. The subtask ID identifies the subtask that the service controller needs to execute; for example, when the service controller is XC1, the subtask ID is the ID of subtask 1. The job ID identifies the job involved in subtask 1; for example, the job ID of job 1. The attributes of the candidate PF include at least one of the following: the processing function type of each candidate PF (e.g., ingress PF, egress PF), the job ID supported by each candidate PF, the location of each candidate PF (e.g., cell, network, tracking area, geographic region), the capabilities of each candidate PF (e.g., data processing capabilities, computing capabilities, and communication capabilities), and the input and output data formats supported by each candidate PF.

[0140] Step 912: The first MM selects one or more selected PFs from the received candidate PFs. In some embodiments, the first MM selects one or more selected PFs and GWs simultaneously based on the attributes of the candidate PFs and the attributes of the GW. In some embodiments, when the first MM receives the PF ID of a candidate PF from a service controller (e.g., XC1, XC2, and XC3) controlled by the first MM, the first MM arranges the PFs sequentially based on the order of the jobs involved in the subtasks supported by the MM, and selects one or more selected PFs based on the order of the PFs. Specifically, the order of the jobs involved in the subtasks can be understood as the processing order of the jobs. For example, when executing subtask 1, the order of the jobs is: job 1, job 2, and job 3. In some embodiments, when arranging the PFs sequentially, all in-PFs can be arranged together, and all e-PFs can be arranged together. Based on the order of tasks 1, 2, and 3, the in-PF order is: in-PF1 of XaaS module 1, in-PF2 of XaaS module 1, in-PF1 of XaaS module 2, in-PF2 of XaaS module 2, in-PF of XaaS module 3, and i / e-PF of XaaS module 3; the e-PF order is: e-PF of XaaS module 1, e-PF of XaaS module 2, i / e-PF of XaaS module 3, and e-PF of XaaS module 3.

[0141] In some embodiments, the first MM selects all ingress PFs of the first involved XaaS module and all egress PFs of the last involved XaaS module as one or more selected PFs. For example, the first MM selects in-PF1, in-PF2 of XaaS module 1, i / e-PF of XaaS module 3, and e-PF of XaaS module 3 as one or more selected PFs.

[0142] Step 913: The first MM sends the PF IDs of one or more selected PFs to the second MM. The PF IDs of the selected PFs are included in a message, such as a task data plane establishment command confirmation message. The message may also include attributes of one or more selected PFs.

[0143] Step 914: The second MM selects one or more boundary PFs from one or more selected PFs. Based on the attributes of the PFs under the first MM and at least one of the following: attributes of the GWs under the first MM and / or the second MM (e.g., GW load, GW location), and the attributes of the PFs under the second MM, considering communication (e.g., data forwarding) and computation (e.g., data processing) efficiency, the second MM may simultaneously select PFs under the first MM and GWs under the second MM. For example, the second MM selects the in-PF2 of XaaS module 1 and the i / e-PF of XaaS module 3 as boundary PFs.

[0144] Step 915: The first MM receives the PF IDs of one or more boundary PFs from the second MM. In some embodiments, the second MM sends a message to the first MM, such as a task data plane update command message. This message includes one or more boundary PF IDs of one or more boundary PFs and a task ID. The message may also include at least one of the following: a task ID, a subtask ID, and a GW ID of a selected GW issued by the second MM to the first MM, wherein the subtask ID identifies the subtask executed by the first MM (e.g., the subtask ID of subtask 1). In some embodiments, after receiving one or more boundary PF IDs, based on the boundary PFs and / or GWs selected by the second MM, the first MM continues to select GWs under the first MM and selects intermediate PFs of the subtasks (e.g., the exit PF of the first involved XaaS module, the ingress PF of the last involved XaaS module, and the ingress and exit PFs of intermediate XaaS modules). For example, the first MM selects the e-PF of XaaS module 1, the in-PF1 of XaaS module 2, and the e-PF of XaaS module 2 as intermediate PFs.

[0145] Step 916: The first MM sends one or more boundary PF IDs to the service controller. Optionally, the first MM also sends intermediate PFs and GWs under the first MM to the service controller. In some embodiments, the first MM sends a task data plane update request message to the service controller, which includes one or more boundary PF IDs, and also includes a subtask ID and a job ID. The subtask ID indicates the subtask executed by the first MM, and the job ID indicates the job executed by the controller. For example, when the service controller is XC1, the subtask ID indicates subtask 1, and the job ID indicates job 1.

[0146] In some embodiments, each XC configures the PF selected by the first MM and establishes a connection between the PF and the GW.

[0147] Figure 10 Another embodiment of the workflow of the task instantiation selection method according to the present invention is shown. Figure 13 A corresponding possible system architecture is illustrated. In some embodiments, resources for performing a certain type of task must be instantiated so that the task can be executed later. Task instantiation can result in a task instance. A task instance is a resource pool, and a portion or all of the resource pool can be selected for later execution of the task. The resource can be computing resources, communication resources, etc. The resource can be provided by a specific network infrastructure, such as RAN, core network functions, equipment, etc. A task instance can consist of one or more sub-task instances and / or working instances. For example, the task instantiation process can be completed during the network deployment and management phase, and the task execution process can be completed during the network operation phase, such as the phase when the network provides services to customers. In some optional application scenarios, this embodiment can be combined with the above embodiments. The above embodiments describe a method for selecting a processing function, assuming that a global MM has been selected, and the UE / NF / AF sends a request to the global MM that controls the PF selection process. This embodiment describes a method for selecting a task management function for task instantiation. In this method, under the control of the initial MM, the global MM of the task is selected from multiple MMs. The method includes: Step 1001: Each of the one or more MMs sends a registration request message, wherein the registration request message indicates one or more tasks supported by each of the one or more MMs, or one or more subtasks supported by each of the one or more MMs. In some embodiments, the MM can be a RAN-MM or a CN-MM. When the MM is a RAN-MM, the RAN-MM sends a registration request message to a RAN function (e.g., a RAN node), and the RAN-MM is deployed in the RAN. When the MM is a CN-MM, the MM sends a registration message to a CN function (e.g., an NRF), and the CN-MM is deployed in the CN. The one or more MMs include an initial MM randomly selected by the network to serve the UE when the UE initially accesses the network. The initial MM can also be referred to as the first MM. The RAN function is deployed in the RAN. The RAN function can be an existing 5G RAN function, such as a RAN node or other existing RAN function, or a newly defined 6G RAN function. The CN function can be deployed in the CN. The CN function can be an existing 5G CN function, such as a network repository function (NRF) or other existing network function, or a newly defined 6G CN function. The following steps are illustrated using an NRF as an example of the CN function.

[0148] In some embodiments, the registration request message includes one or more supported task IDs and / or one or more supported subtask IDs, where the one or more supported task IDs indicate one or more tasks supported by the MM, and the one or more supported subtask IDs indicate one or more subtasks supported by the MM. The registration request message may also include at least one of the following: task context and subtask context. The task context is used to describe the tasks supported by the MM. For example, the task context may include information including at least one of the following: the task identified by the task ID is supported only in a specific area (e.g., a specific cell, tracking area, location); the task identified by the task ID is supported only in a specific network (identified by a Public Land Mobile Network (PLMN) ID or a Non-Public Network (NPN) ID); or the task identified by the task ID is supported only at a specific time or under specific conditions. Furthermore, the task context may indicate that performing the task identified by the task ID involves both the RAN and the CN; for example, when subtask instances and / or working instances exist in both the RAN and the CN, both the RAN and the CN should be involved; when subtask instances and working instances exist only in the RAN or only in the CN, only the RAN or only the CN should be involved. For example, when an instance on the RAN side is involved in the entire task instance, it indicates that the RAN should be involved. The subtask context may include some information including at least one of the following: the subtask identified by the task ID is supported only in a specific area (e.g., a specific cell, tracking area, location); the subtask identified by the subtask ID is supported only in a specific network (identified by a Public Land Mobile Network (PLMN) ID or a Non-Public Network (NPN) ID); or the subtask identified by the subtask ID is supported only at a specific time or under specific conditions.

[0149] Step 1002: The initial MM receives a message from the UE, AF, network function (NF), or management plane (e.g., OAM), such as a first request message, which may be a task instantiation request message. NFs include CM, RM, etc. This message indicates the requested task. In some embodiments, the message includes a task ID that identifies the task requested by the UE or AF. The message may also include a task context that describes the task identified by the task ID. The task context includes some or all of the following information: information indicating that the execution of the task identified by the task ID involves both the RAN and CN; for example, when sub-task instances and / or working instances exist in both the RAN and CN, both the RAN and CN should be involved; when sub-task instances and working instances exist only in the RAN or only in the CN, only the RAN or only the CN should be involved. For example, when the entire task instance involves instances on the RAN side, it indicates that the RAN should be involved; information indicating whether the task instance is available in a specific area (e.g., a specific cell, tracking area, location), in a specific network identified by the PLMN ID or NPN ID, at a specific time, and under specific conditions.

[0150] Step 1003: The initial MM determines one or more target MMs, wherein the one or more target MMs are capable of providing the requested task or one or more subtasks involved in the requested task. Specifically, the initial MM invokes a task graph and task instance information. The task graph indicates the composition of the task, for example, the composition of the task indicates one or more jobs or subtasks involved in the task, and the order of these jobs and / or subtasks. The task instance information indicates the resources used to perform these jobs and / or subtasks, which include network entities that can perform these jobs and / or subtasks. The resources can be data forwarding resources, computing resources, communication resources, data storage resources, etc. The resources can be provided by specific network infrastructure, such as RAN, core network functions, equipment, etc. The initial MM obtains the job ID identifying the job and / or the subtask ID identifying the subtask involved in the task requested by the UE, AF, NF, or OAM. Based on the job ID / subtask ID and the task instance information, the initial MM checks whether one or more required task instances already exist in the network. The required task instance is the task instance used to perform the jobs and / or subtasks involved in the task. If the initial MM determines that at least one instance of the required task already exists in the network, the MM that controls or coordinates the required task instance is considered the target MM, in which case the target MM is the global MM. If the initial MM determines that no instance of the required task exists in the network, one or more of steps 1003-a to 1003-f are executed.

[0151] Step 1003-a: The initial MM sends a discovery message to the CN function (e.g., NRF) or RAN function (e.g., RAN node). When the initial MM is a RAN-MM, it sends a discovery message to the RAN function; when the initial MM is a CN-MM, it sends a discovery message to the CN function (e.g., NRF). This discovery message includes a task ID identifying the task requested by the UE, AF, NF, or OAM. The discovery message may also include a task context describing: the task, a subtask ID identifying the subtasks involved in the task, and the subtask context.

[0152] Step 1003-b: The CN function (e.g., NRF) or RAN function checks whether the desired task instance controlled by an existing MM already exists in the network (e.g., in the RAN and CN) based on the information included in the discovery message. If the desired task instance exists in the network, the existing MM controlling the desired task instance is considered the target MM, in this case, the global MM. The CN function (e.g., NRF) or RAN function sends the global MM ID to the initial MM. The initial MM can contact the global MM based on the global MM ID and forward the information included in the message received from the UE, AF, NF, or OAM in step 1002 to the global MM. The global MM responds to the UE, AF, NF, or OAM, and the process ends. If the desired task instance does not exist in the network, the CN function (e.g., NRF) or RAN function identifies which candidate MMs can provide the subtasks identified by subtask IDs involved in the task. The NRF or RAN function (e.g., RAN node) sends the candidate MM IDs to the initial MM and also performs step 1003-c.

[0153] Step 1003-c: The initial MM sends a message to each candidate MM in the candidate MM, for example, a second request message, which may be a subtask instantiation request message. The message includes the task ID obtained from the UE, AF, NF or OAM, and also includes the subtask ID of the subtask involved in the task.

[0154] Step 1003-d: If the subtask has not yet been instantiated, or if the instantiated subtask has been released (e.g., the subtask instance has been removed or deleted), the candidate MM performs subtask instantiation (during which the candidate MM may interact with the XaaS modules it controls (e.g., with the XC of the XaaS module) to instantiate the work), and then sends a response message to the initial MM, which may be a subtask instantiation response message. This message includes the task ID and the subtask ID. The resources used to execute the subtask must be instantiated so that the subtask can be executed later. Subtask instantiation yields a subtask instance. A subtask instance is a resource pool, and a portion or all of this resource pool can be selected for later execution of the subtask. This resource can be computing resources, communication resources, etc. This resource can be provided by a specific network infrastructure, such as the RAN, core network functions, equipment, etc. A subtask instance can consist of one or more working instances. The candidate MM performing subtask instantiation can also be understood as the candidate MM finding, collecting, coordinating, and / or configuring resources for executing the subtask. If the subtask has already been instantiated and the instantiated subtask is still available, the candidate MM sends a response message directly to the initial MM.

[0155] Step 1003-e: The initial MM determines one or more target MMs from one or more candidate MMs based on the subtask instantiation response message. For example, if multiple candidate MM responses successfully instantiate the subtask identified by the subtask ID, then in the case of instantiating redundant resources, only one or some of the candidate MMs can be selected as the target MM, and the other candidate MMs can release the instantiated resources.

[0156] Step 1004: The initial MM selects a second MM from the initial MM and one or more target MMs. The second MM can be a global MM. The initial MM and target MMs negotiate and select one as the global MM based on selection principles, while the other MMs can be domain MMs. Then, the global MM sends a registration update request message to the RAN function or CN function (e.g., NRF). If the global MM is deployed on the RAN side, it sends a registration update request message to the RAN function; if it is deployed on the CN side, it sends a registration update request message to the CN function (e.g., NRF). This message includes task instance configuration information. This task instance configuration information can also be called task slice configuration information or task configuration information. The RAN function and CN function store the task instance configuration information in local memory, etc. It should be noted that in the above steps, when the required task instance is found in the network, the MM controlling the required task instance is the global MM. After selecting the global MM, the initial MM contacts the global MM and forwards the information included in the message received from the UE, AF, NF, or OAM in step 1002 to the global MM. The global MM responds to the UE, AF, NF, or OAM, and the process ends.

[0157] Task instance configuration information includes at least one of the following: The following identifiers are included: Global MM ID (identifying the global MM), Task ID (identifying the task), One or more subtask IDs (identifying one or more subtasks involved in the task), One or more domain MM IDs (identifying one or more domain MMs controlling one or more subtasks), One or more job IDs (identifying one or more jobs involved in the task), One or more XC IDs (identifying one or more XCs controlling one or more jobs), Task Slice ID (identifying a task slice), Task Instance ID (identifying a task instance), and Task Context. The Task Context can be an update of the Task Context from step 1001.

[0158] The selection criteria for a global MM can depend on: the coverage of the MM (e.g., selecting an MM located in a CN rather than an MM located in a RAN as the global MM), the number of subtasks or jobs controlled by the MM (e.g., selecting the MM that controls the largest number of subtasks or jobs as the global MM), and communication efficiency (e.g., selecting the MM that can communicate with other MMs involved in the task at the lowest communication cost as the global MM).

[0159] Each global MM can also store task instance configuration information in local storage, etc.

[0160] Subtask instance configuration information also exists, for example, stored in the local storage of each domain MM, or in the storage of CN / RAN functions (e.g., RAN nodes). Subtask instance configuration information can also be called subtask slice configuration information, or subtask configuration information.

[0161] The subtask instance configuration information includes at least one of the following: the subtask ID that identifies the subtask, the domain MM ID that identifies the domain MM that controls the subtask, one or more job IDs that identify one or more jobs involved in the task, one or more XC IDs that identify one or more XCs that control one or more jobs, the subtask slice ID that identifies the subtask slice, the subtask instance ID that identifies the subtask instance, and the subtask context.

[0162] There is also working instance configuration information, for example, stored in the local storage of each XC, or in the storage of the CN / RAN function (e.g., RAN node). Working instance configuration information can also be called working slice configuration information, or working configuration information.

[0163] The job instance configuration information includes at least one of the following: job ID that identifies the job, XC ID that identifies the XC that controls the job, PF ID that identifies one or more PFs that can perform the job, job slice ID that identifies the job slice, job instance ID that identifies the job instance, and job context.

[0164] It should be noted that prior to step 1001, each job may have been instantiated by the corresponding XaaS module. One or more job instances constitute a subtask instance or a task instance. Each subtask may also have been instantiated. The global MM of a task instance or task slice can be logically unique, but the global MM can be implemented as multiple duplicate physical MM entities. A subtask instance can consist of one or more job instances. Resources used to perform a job must be instantiated so that the job can be executed later. Job instantiation yields job instances. A job instance is a resource pool, and a portion or all of this resource pool can be selected for later execution of the job. This resource can be computing resources, communication resources, etc. This resource can be provided by a specific network infrastructure, such as RAN, core network functions, equipment, etc.

[0165] Figure 11 An embodiment of the workflow of the initial access method according to the present invention is shown. Figure 14 A corresponding possible system architecture is illustrated. In the above embodiments, the method for selecting the PF and the global MM has been described. After selection, the UE will initially access the network (e.g., register with the network) to discover and obtain the allowed task resources (e.g., task instances) provided by the network to the UE.

[0166] like Figure 11 As shown, the workflow steps of the initial access method include: Step 1101: The UE sends an access request message (e.g., an initial access request) to the RAN. The RAN receives the access message (e.g., an initial access request message), wherein the access request message includes at least one request task ID, which indicates at least one request task.

[0167] Prior to step 1101, the UE stores a configured task ID and task context locally. The configured task ID identifies the task that the UE can request the network device (RAN and / or CN) to perform, and the task context is used to describe the task.

[0168] The RAN stores supported task IDs and task contexts locally. The supported task ID identifies the task supported by the RAN MM, and the task context describes the task. This information can be communicated to the RAN by the RAN MM. The RAN MM is the MM deployed within the RAN.

[0169] Network functions (e.g., NRFs) locally store supported task IDs and task contexts. The supported task IDs identify tasks supported by the CN MM, and this information can be communicated to the network function by the CN MM. Network functions can be existing 5G network functions, such as network repository functions (NRFs) or other existing network functions, or newly defined 6G CN functions. The CN MM is the MM deployed within the CN. The RAN MM is the MM deployed within the core network (CN).

[0170] RAN functions and CN functions (e.g., CM) can interact to notify each other of the supported task IDs and task contexts. For example, the RAN sends an interface establishment request message to the CN, which includes the task ID and task context. RAN-MM supports task IDs. The CN sends an interface establishment response message to the RAN, which includes the task ID and task context. CN-MM supports task IDs. In the task context, as previously described, it can indicate that the task identified by the task ID is supported only in a specific area (e.g., a specific cell, tracking area, location), in a specific network identified by a PLMN ID or NPN ID, etc. Connectivity Management (CM) functions support reachability services and connectivity services. Reachability services perform the acquisition and maintenance of endpoint locations. Connectivity services perform the maintenance (establishment and removal) of connections between endpoints and 6G systems. CM is deployed in the CN or RAN.

[0171] The RAN can send network-supported task IDs to the UE (via broadcast or unicast messages, such as system information, RRC messages, XaaS signaling messages, or paging messages). For example, the RAN can broadcast supported task IDs to the UE (e.g., per cell, per network, or per tracking area) to assist the UE in performing cell / network selection. The RAN can send the cell ID, network ID, or tracking area ID along with the supported task IDs. After receiving the network-supported task IDs, the UE can select one or more overlapping task IDs from one or more supported task IDs of the network and one or more configured task IDs of the UE as one or more requested task IDs.

[0172] It should be noted that in this application, the following items can be used instead of the task ID: task slice ID, task slice selection ID, task instance ID, task instance selection ID, task selection auxiliary ID, task instance selection auxiliary ID, task slice selection auxiliary ID, task slice selection information, task instance selection information, task selection auxiliary information, task instance selection auxiliary information, and task slice selection auxiliary information.

[0173] After step 1101, one of steps 1102-a, 1102-b, and 1102-c will be executed.

[0174] Step 1102-a: The RAN determines the allowed tasks from at least one requested task based on the task IDs supported by the RAN MM and the CN MM. In this case, the CN side (e.g., the connection manager (CM) or CN-MM) has notified the RAN of the task IDs supported by the CN-MM. The RAN selects the task IDs that overlap between the requested task IDs and the CN-supported task IDs or the RAN-supported task IDs as the allowed task IDs sent to the UE. For example, the requested tasks are tasks 1, 2, and 3; the CN-supported tasks are tasks 2, 4, and 6; and the RAN-supported tasks are tasks 3, 4, and 5. The RAN then determines that the task overlapping between the CN-requested task and the CN-supported task is task 2, and the RAN determines that the task overlapping between the RAN-requested task and the RAN-supported task is task 3. The RAN then determines that tasks 2 and 3 are allowed tasks.

[0175] Step 1102-b: The RAN sends the requested task ID received from the UE to the CN, enabling the CN to determine the allowed task from at least one requested task. In this case, the CN already has information on RAN-supported task IDs. The CN selects the task ID that overlaps between the requested task ID and a CN-supported task ID or a RAN-supported task ID as the allowed task ID sent to the UE. Optionally, the CN checks the UE's subscription information, which includes the task IDs subscribed to by the UE. The CN compares the requested task ID with the UE's subscribed task IDs. If the requested task ID does not belong to the subscribed task IDs, the corresponding requested task will not be selected as an allowed task. For example, if the UE's subscribed tasks include tasks 3 to 10, then requested tasks 1 and 2 will not be selected as allowed tasks.

[0176] In some embodiments, the RAN sends a requested task ID via an initial UE message (also referred to as an initial terminal message). This initial UE message includes the requested task ID and at least one of the following: UE context (e.g., cell ID identifying the cell where the UE resides, tracking area identity (TAI) identifying the tracking area where the UE resides, public land mobile network (PLMN) ID or non-public network (NPN) ID identifying the network (supported by the RAN and CN) where the UE resides or requests access, UE data processing and communication capabilities), and RAN capabilities. RAN capabilities can be task IDs supported by the RAN-MM, job IDs supported by the RAN-XC, or subtask IDs supported by the RAN-MM. These supported IDs can be all IDs supported by the RAN-MM or RAN-XC, or a subset of IDs supported by the RAN-MM or RAN-XC (related to the ID requested by the UE). For example, the task requested by the UE must involve the RAN-MM supported subtask ID and the subtask identified by the subtask ID, and the task cannot be executed by the RAN side alone; the task requested by the UE must involve the RAN-XC supported work ID and the work identified by the work ID, and the task cannot be executed by the RAN side alone.

[0177] In some embodiments, the requested task ID may be received by a first CN function (e.g., the CM of the CN), which then sends a message, such as a task selection request message, to a second CN function (e.g., the NRF of the CN). This task selection request message includes the requested task ID and may further include at least one of the following: the task ID subscribed by the UE, the task context, and the UE context. The first CN function is deployed in the CN. The second CN function is deployed in the CN.

[0178] In some embodiments, the CN (e.g., a first CN function or a second CN function) performs task ID selection to determine the task ID allowed by the UE based on the following factors: The task ID requested by the UE, the task ID subscribed by the UE (stored in a third CN function (e.g., UDM) and retrieved from the third CN function by a first or second CN function deployed in a CN), the UE context (e.g., the UE location that the RAN or UE may report to the CN (e.g., the cell ID identifying the cell where the UE is located, the tracking area identity (TAI) identifying the tracking area where the UE is located, the PLMN ID or NPN ID identifying the network where the UE is located, the UE's data processing and communication capabilities), the task ID supported by the CN (e.g., when the CN deploys a task instance corresponding to the task ID, the CN is considered to support the task ID), and the task context (e.g., supporting the task ID only in a specific area (e.g., a specific cell, tracking area, location), in a specific network identified by the PLMN ID or NPN ID, at a specific time, and under specific conditions). Furthermore, the task context can indicate whether the RAN and CN should cooperate in executing the task identified by the task ID, i.e., whether sub-task instances and / or working instances exist in the RAN and CN, only in the RAN, or only in the CN. For example, whether the entire task instance involves instances on the RAN side. The UE's task context can be a subset of the following: the task context of the task (e.g., the task is available in a specific cell or TA, but it is only available to the UE in some cells or TAs, for example, depending on the UE's subscription), the workload of the entity (e.g., PF) involved in the task instance corresponding to the task ID, and RAN capabilities (e.g., RAN-MM supported task IDs, RAN-XC supported work IDs, or RAN-MM supported subtask IDs. These supported IDs can be all IDs in the RAN-MM or RAN-XC supported IDs, or a portion of the RAN-MM or RAN-XC supported IDs (related to the ID requested by the UE)).

[0179] For example, when the UE context and task context are consistent with each other and the entity's workload is low, the CN (e.g., CM, NRF) can select an overlapping task ID as the UE-allowed task ID.

[0180] If the UE context and the task context are inconsistent, or if the entity's workload is high, the CN (e.g., CM, NRF) will not select the task ID as the UE's allowed task ID.

[0181] When the RAN notifies that a certain task ID can be a task ID allowed by the RAN-side UE, but the task ID is not a task ID supported by the CN-MM, if the task should be executed when both the RAN-MM and CN-MM support the task ID, then the task ID should not be selected as the task ID allowed by the UE; if the task can be executed when either the RAN-MM or CN-MM supports the task ID, then the task ID should be selected as the task ID allowed by the UE.

[0182] When neither RAN-MM nor CN-MM supports task IDs, if RAN-MM / RAN-XC can perform part of the task's work / subtasks, and CN-MM / CN-XC can perform other parts of the task's work / subtasks, then that task ID can also be selected as the UE-allowed task ID.

[0183] In some embodiments, after a second CN function (e.g., NRF) selects an allowed task, the second CN function (e.g., NRF) sends the allowed task ID to a first CN function (e.g., CM). For example, the second CN function (e.g., NRF) sends a message to the first CN function (e.g., CM), such as a task selection response message. This message includes the allowed task ID and may also include at least one of the following: a task context (which may be an updated task context associated with the UE, e.g., the task is available in a specific cell or TA, but it is only available to the UE in some cells or TAs), and an MM ID identifying the target MM that can provide the requested task to the UE. The first CN function (e.g., CM) may use the MM ID to contact the target MM in subsequent processes. The CN may store the UE-allowed task ID in local memory.

[0184] After the CN determines one or more allowed task IDs, the CN sends the allowed task IDs to the RAN. For example, after receiving the allowed task IDs from a second CN function (e.g., NRF), a first CN function (e.g., CM) sends one or more allowed task IDs to the RAN. The first CN function (e.g., CM) sends a message to the RAN, such as an Initial UE Context Establishment Request message, which includes the allowed task IDs. This message may also include at least one of the following: an MM ID identifying the target MM that can provide the requested task to the UE. The RAN can use the MM ID to contact the target MM in subsequent processes. The RAN can store the UE-allowed task IDs in its local memory.

[0185] Step 1102-c: The RAN determines at least one allowed task from at least one requested task based on the RAN-supported task ID. The RAN performs task selection to determine the UE-allowed task based on one or more of the following factors: the task requested by the UE, the task supported by the RAN MM, the subtask supported by the RAN MM, and the work supported by the service controller. In some embodiments, the RAN compares the task ID of the task supported by the RAN MM with the task ID of at least one requested task to determine if there is overlap. If the requested task can be supported by the RAN MM, the RAN determines that there is overlap, and the requested task that can be supported by the RAN MM is the overlapping task. When all requested tasks can be supported by the RAN MM, then all requested tasks are allowed tasks. When some parts of a requested task are supported by the RAN MM, while other parts of the requested task are not supported by the RAN MM, then the RAN may send the requested task that is not supported by the RAN MM to the CN and / or send the requested task that is supported by the RAN MM to the CN.

[0186] In one optional implementation, the RAN sends the task ID of the overlapping task to the CN. For tasks allowed by the RAN, i.e., overlapping tasks, the CN can also check the UE's subscription information. If the task allowed by the RAN is not among the UE's subscribed tasks, the CN will change the allowed task to disallowed. Based on the above process, the CN determines the finally allowed tasks. The CN (e.g., CM) sends the allowed task ID of the finally allowed task to the RAN, and then step 1103 can be executed.

[0187] In one example, if the RAN MM supports Task 1, Task 2, and Task 3, and the requested tasks are Task 1, Task 2, Task 3, and Task 4, then the RAN will determine Task 1, Task 2, and Task 3 as allowed tasks and send the task IDs of Task 1, Task 2, and Task 3. The CN can also check the UE's subscription information to see if the tasks allowed by the RAN belong to the UE's subscribed tasks.

[0188] In another alternative implementation, the RAN sends the task IDs of tasks not supported by the RAN to the CN, and the CN determines whether these tasks are allowed. Details on how the CN determines allowed tasks are provided in step 1102-b. The CN (e.g., CM) sends the allowed task IDs of the allowed tasks to the RAN, and then step 1103 can be performed. In one example, the RAN MM supports tasks 1, 2, and 3, and the requested tasks are tasks 2, 3, and 4. The RAN determines tasks 2 and 3 as allowed tasks, and sends task 4 to the CN so that the CN can determine whether task 4 is allowed. The RAN sends the requested task IDs via an initial UE message, which includes the requested task IDs not supported by the RAN. Details on how the CN determines allowed tasks are provided in step 1102-b. The CN function (e.g., CM) sends the allowed task IDs to the RAN, and the RAN considers the RAN-allowed tasks and CN-allowed tasks as allowed tasks, and then step 1103 can be performed.

[0189] In another optional implementation, the RAN MM can send the CN with requests for tasks that are not supported by the RAN MM and requests for tasks that are supported by the RAN MM. RAN-supported requests can also be understood as RAN-allowed tasks. The RAN MM can send both requests in the same message, in which case the message includes two lists of task IDs: one list includes allowed task IDs, and the other list includes the requested task IDs for tasks not supported by the RAN. Alternatively, the message can include a single list of task IDs, which can separately identify allowed task IDs and requests for tasks not supported by the RAN. Alternatively, allowed task IDs and requests for tasks not supported by the RAN can be sent to the CN in separate messages. For these RAN-unsupported requests, the CN determines whether they can be allowed. For details on how the CN determines allowed tasks, see step 1102-b. For RAN-allowed tasks, the CN can also check the UE's subscription information. If a RAN-allowed task is not part of the UE's subscribed tasks, the CN will change the allowed task to disallowed. Based on the above process, the CN determines the final allowed tasks. The CN (e.g., the CN's CM) sends the allowed task ID of the finally allowed task to the RAN, and then step 1103 can be executed.

[0190] Step 1103: The RAN sends the allowed task ID to the UE. The RAN may send a message to the UE, such as an initial access response (e.g., registration request, task selection request) message. This message includes the task ID allowed by the UE. The UE stores the allowed task ID in its local memory for later use (e.g., for subsequent task data plane establishment requests).

[0191] The initial UE access procedure is described in steps 1101 to 1103. It should be noted that this embodiment may skip some steps, and the order of these steps is not limited. After the initial UE access procedure, the UE obtains its allowed task IDs. When the UE wants to participate in or perform a task, it sends a message to the network including a suitable task ID selected from one or more allowed task IDs. The network can use an existing task instance corresponding to the requested task ID to establish a task data plane, enabling the UE's task execution (i.e., data processing and data forwarding services) to be realized. (Continue to refer to...) Figure 11 Steps 1104 to 1106 illustrate the workflow of the UE's task data plane establishment request process. Steps 1104 to 1106 can be combined with... Figure 11 Separate them as separate technical solutions.

[0192] Step 1104: The RAN receives a message from the UE, which may be a Task Data Plane Establishment Request message. This message requests the establishment of a task data plane for a requested task, which is one of the tasks indicated by at least one allowed task ID. To establish the task data plane, the resources used to perform the task (e.g., data forwarding resources, data processing resources, data computation resources, data storage resources) should be prepared and established by the RAN or CN. To distinguish it from the requested task in the preceding steps, the requested task in this and subsequent steps may be referred to as the first requested task. The message may also include at least one of the following: a task session ID (or a task data plane ID). The task session ID (or task data plane ID) is used to identify the requested task data plane. When selecting the first requested task from the allowed tasks, the UE may consider the task context and / or the following information: a task selection policy (which may be pre-configured to the UE by the network): The UE maps upper-layer applications to task IDs based on the task selection policy, and the UE reports the task IDs to the network. Alternatively, the UE maps applications to task slice IDs based on the task slice selection policy, and the UE reports the task slice IDs to the network. The task selection policy indicates that data belonging to a specific application should be delivered and processed through a task identified by a task ID. The task slice selection policy indicates that data belonging to a specific application should be delivered and processed through a task slice identified by a task slice ID.

[0193] Step 1105: The RAN determines whether the RAN side (e.g., a task instance deployed in the RAN) can execute the first requested task requested by the UE on its own. For example, if there is overlap between one or more allowed task IDs of the UE stored in the RAN and one or more task IDs deployed in the RAN corresponding to one or more task instances, and the task ID of the first requested task belongs to one or more allowed task IDs of the UE stored in the RAN, and the task context and UE context are consistent, then the RAN considers that the RAN side can execute the first requested task on its own; otherwise, the RAN considers that the RAN side cannot execute the first requested task on its own. When the RAN determines that the RAN side cannot execute the first requested task on its own, step 1106 can be executed; otherwise, step 1106 is skipped. The RAN, RAN-MM, or RAN-XC selects the PF and GW on the RAN side for the task session (or task data plane), and then connects and configures the selected PF and GW for data processing and data forwarding. The RAN, RAN-MM, or RAN-XC should determine the work or one or more subtasks that the UE wants to perform. At the same time, the RAN-XC controls the RAN-PF to configure one or more XRBs for one or more UEs. The RAN sends a task data plane establishment response message to the UE. This message can be sent from RAN-XC or RAN MM, and the RAN forwards it to the UE. The message includes one or more of the following: job ID, XRB ID, configuration on the XRB, task ID, and subtask ID. The message can be sent, for example, via paging, via System Information (SI), via RRC, or via XaaS signaling bearer.

[0194] Step 1106: The RAN sends a message to the first CN function (e.g., CM), such as a mission data plane establishment request message. This message includes the mission ID of the first requested mission (the first requested mission ID). The message may also include at least one of the following: mission session ID (or mission data plane ID), UE context (e.g., cell ID identifying the cell where the UE resides, tracking area identity (TAI) identifying the tracking area where the UE resides, PLMN ID or NPN ID identifying the network where the UE resides, and the UE's data processing and communication capabilities). The first CN function is deployed in the CN.

[0195] If the first CN function (e.g., CM) stores one or more allowed task IDs and task contexts of the UE locally, the first CN function (e.g., CM) verifies whether the UE's request is allowed, i.e., whether there is overlap between the requested task ID and one or more allowed task IDs of the UE; whether there is overlap between the one or more allowed task IDs of the UE stored in the CN and one or more task IDs corresponding to one or more task instances deployed in the CN; and whether the UE context is consistent with the task context. If there is overlap and the context is consistent, the UE's request is allowed; otherwise, the first CN function (e.g., CM) rejects the request. The UE's request can be understood as the UE requesting the preparation and establishment of network resources (e.g., data forwarding resources, data processing resources, data computing resources, data storage resources) for performing the task requested in the first request.

[0196] If the first CN function (e.g., CM) has not yet locally stored the UE-allowed task ID, the first CN function (e.g., CM) retrieves the UE-allowed task ID and task context from the second CN function (e.g., UDM). The first CN function (e.g., CM) then verifies whether the UE's request is allowed. The second CN function is deployed in the CN.

[0197] After verifying and discovering that the UE's request is permitted, i.e., after the first requested task ID is permitted, a first CN function (e.g., CM) can retrieve a target MM ID identifying the target MM from other functions (e.g., NRF), which controls the task instance corresponding to the first requested task ID. Specifically, the first CN function (e.g., CM) sends a task instance discovery request message to a third CN function (e.g., NRF) that performs task instance selection. The third CN function is deployed in a CN. This message includes at least one of the following: an overlapping task ID between the task ID requested by the UE (i.e., the first requested task ID) and one or more permitted task IDs of the UE, and a task context. The third CN function (e.g., NRF) performs task instance selection to determine the target MM controlling the task instance. For example, the third CN function (e.g., NRF) invokes task instance configuration information (e.g., stored in local memory as described in step 1004) to check the target MM controlling the task instance. For example, the third CN function (e.g., NRF) maps task IDs to task slice IDs, and then maps task slices to specific task instances. Then, the third CN function (e.g., NRF) invokes the task instance configuration information to check the target MM controlling the task instance. Alternatively, the network maps task slices to specific task instances. Then, a third CN function (e.g., NRF) invokes task instance configuration information to check the target MM controlling the task instance. The third CN function (e.g., NRF) sends a task instance discovery response request message to a first CN function (e.g., CM). This message includes the first requested task ID, the target MM ID identifying the target MM, and may also include at least one of the following: task context, task slice ID, and task instance ID. This message is used to notify the first CN function (e.g., CM) of the target MM ID identifying the target MM that controls the task instance corresponding to the first requested task ID.

[0198] After checking and identifying the task ID that allows the first request and retrieving the target MM ID that identifies the target MM, the first CN function (e.g., CM) sends a task data plane establishment command message to the target MM (i.e., the global MM) to request the preparation and establishment of the corresponding resources to execute the task. This message includes the task ID requested in the first request, and may also include the task context and / or task session ID. The target MM invokes task instance configuration information and contacts one or more domain MMs and / or one or more XCs to establish a task data plane (or task session) for the UE. For example, the global MM, one or more domain MMs, and (optionally) one or more XCs perform the selection of the PF and GW involved in the task instance, for example, based on the steps in the preceding embodiments, and then connects and configures the selected PF and GW for data processing and data forwarding.

[0199] For example, if the global MM is a CN-MM, it invokes the task instance configuration information and contacts the domain MMs in the CN and (optionally) CN-XC to perform the selection of the PF and GW involved in the task instance on the CN side. Then, the CN-MM and CN-XC configure the selected PF and GW for data processing and forwarding. During this process, each domain MM can invoke the subtask instance configuration information, and each XC can invoke the working instance configuration information. The RAN sends a task data plane establishment response message to the UE. This message can be sent from the RAN-XC, and the RAN forwards the message to the UE. This message includes the task ID of the first requested task, the subtask ID identifying the subtask to be provided by the terminal device involved in the first requested task, the working ID identifying the working involved in the first requested task and to be provided by the terminal device, the task session ID identifying the task data plane, the task context including an indication of whether the terminal device should be involved in the task data plane, the radio bearer ID, and the configuration parameters on the radio bearer identified by the radio bearer ID. The message can be a broadcast message, unicast message, system information, radio resource control (RRC) message, paging message, or dedicated signaling message sent to the terminal device.

[0200] Steps 1104 to 1106 describe the process by which the UE requests the establishment of the mission data plane. In an optional scenario, the mission data plane establishment process can be requested by other mission clients, such as network functions (NFs), application functions (AFs), or application servers (ASs) deployed in the CN or RAN. See steps 1201 to 1207 as alternatives to steps 1104 to 1106. Figure 15 One possible system architecture is shown.

[0201] Step 1201: The UE reports its supported task IDs to the RAN in the reporting message. The UE-supported task IDs identify tasks that the UE can execute or participate in, meaning the UE can provide resources for executing the task. This enables the UE to provide task services to other task users (e.g., NF, other UEs, AF, AS). Allowed task IDs identify tasks that the UE has permission to request from the network to execute, and the UE receives task services corresponding to the allowed task IDs from the network. Optionally, the UE may also report at least one of the following: a subtask ID identifying a subtask supported by the terminal device, a work ID identifying a job supported by the terminal device, and the UE's computing and communication capabilities when executing the task. The RAN stores all of the above locally. The RAN also stores the RAN-MM-supported task IDs and task contexts locally. The RAN-MM-supported task IDs and task contexts can be notified to the RAN by the RAN-MM. The first CN function (e.g., NRF) stores the CN-MM-supported task IDs and task contexts locally. The CN-MM-supported task IDs and task contexts can be notified to the first CN function (e.g., NRF) by the CN-MM. The reported message can be one or more of the following: broadcast message, unicast message, radio resource control (RRC) message, and dedicated signaling message.

[0202] Step 1202: The NF / AF sends a message, such as a Task Instance Discovery Request message, to the first CN function (e.g., NRF) that performs task instance selection. This message includes a task ID and (optionally) a task context. The task ID indicates the task the NF / AF requests the network to perform. The CN function (e.g., NRF) performs task instance selection to determine the target MM controlling the task instance. For example, the first CN function (e.g., NRF) invokes task instance configuration information (e.g., stored in local memory as described in step 1004) to check the target MM controlling the task instance. The network function can be an existing 5G network function, such as a network repository function (NRF) or other existing network functions, or a newly defined 6G network function. The following steps are illustrated using an NRF as an example. For example: The first CN function (e.g., NRF) maps a task ID to a task slice ID, and then maps the task slice to a specific task instance. The CN function (e.g., NRF) then invokes the task instance configuration information to check the target MM controlling the task instance. Alternatively, the network maps task slices to specific task instances. The first CN function (e.g., NRF) then invokes the task instance configuration information to check the target MM controlling the task instance.

[0203] Step 1203: The first CN function (e.g., NRF) sends a message to the NF / AF, such as a task instance discovery response request message. This message includes the task ID, the target MM ID identifying the target MM, (optional) the task context, (optional) the task slice ID, and (optional) the task instance ID.

[0204] Step 1204: The NF / AF sends a message to the target MM (i.e., the global MM), for example, a task data plane establishment request message. This message includes the task ID, (optional) task context, and (optional) task session ID. In some embodiments, the message may be sent to the target MM by a first CN function (e.g., NRF).

[0205] Step 1205: The target MM invokes the task instance configuration information and contacts one or more domain MMs and (optionally) one or more XCs to establish the task data plane for NF / AF. For example, the global MM, one or more domain MMs, and (optionally) one or more XCs perform the selection of PF and GW involved in the task instance, for example, based on the steps in the previous embodiments, and then connects and configures the selected PF and GW for data processing and data forwarding. For example, if the global MM is a CN-MM, then this MM invokes the task instance configuration information and contacts the domain MMs in the CN and (optionally) CN-XC to perform the selection of PF and GW involved in the task instance on the CN side, for example, based on the steps in the above embodiments, and then the CN-MM and CN-XC configure the selected PF and GW for data processing and data forwarding. In this process, each domain MM can invoke subtask instance configuration information, and each XC can invoke worker instance configuration information.

[0206] Step 1206: The target MM sends a message to the second CN function (e.g., CM), such as a task data plane establishment command message. This message includes: a task ID, a subtask ID identifying the subtask to be provided by the RAN side, an (optional) task session ID, and an (optional) task context, which includes an indication of whether the task data plane should involve the RAN side and / or an indication of whether the task data plane should involve one or more UEs. The message may also include the IDs of one or more UEs.

[0207] Step 1207: The second CN function (e.g., CM) sends a task data plane establishment request message to the RAN. This message includes: a task ID, a subtask ID identifying the subtask to be provided by the RAN side, an (optional) task session ID, and an (optional) task context, which includes an indication of whether the task data plane should involve the RAN side and / or an indication of whether the task data plane should involve one or more UEs. The RAN invokes the subtask instance configuration information on the RAN side, contacts the domain RAN-MM and (optionally) XC, and forwards the task data plane establishment response message to the RAN-MM and (optionally) XC. The RAN-MM contacts the global MM in the CN (directly or through intermediate entities, e.g., RAN and CM) and the RAN-XC to perform the selection of the PF and GW involved in the RAN-side task instance, for example, based on the steps in the above embodiments. Then, the RAN-MM and RAN-XC configure the selected PF and GW for data processing and data forwarding. During this process, each RAN-MM can invoke the subtask instance configuration information, and each RAN-XC can invoke the working instance configuration information. Based on the task context, the RAN, RAN-MM, or RAN-XC can determine whether one or more UEs should be involved in the task. When the RAN determines that one or more UEs should be involved in the task, the RAN selects one or more UEs. During the process of the RAN selecting one or more UEs, the RAN, RAN-MM, or RAN-XC should determine the work to be performed by one or more UEs and select one or more UEs that have reported the supported work ID and (optionally) task ID or subtask ID in step 1201. At the same time, the RAN-XC controls the RAN-PF to configure one or more XRBs for one or more UEs. The RAN requests one or more UEs to establish a task data plane; for example, the RAN sends a task data plane establishment request message to one or more UEs. This message can be sent from the RAN-XC or RAN MM, and the RAN forwards the message to one or more UEs. The message includes one or more of the following: the task ID of the first requested task, the subtask ID identifying the subtask to be provided by the terminal device involved in the first requested task, the work ID identifying the work involved in the first requested task and to be provided by the terminal device, the task session ID identifying the task data plane, the task context including an indication of whether the terminal device should be involved in the task data plane, the radio bearer ID, and the configuration parameters on the radio bearer identified by the radio bearer ID. The RAN can send this message to one or more UEs via broadcast or unicast messages (e.g., via paging messages, via System Information (SI), via RRC messages, or via dedicated signaling messages). The work ID, XRB ID, configuration on the XRB, and (optionally) task ID or subtask ID sent to different UEs may be different.

[0208] Step 1208: The RAN sends an establishment response message to the CN indicating that the task data plane has been successfully established.

[0209] It should be noted that in some modified embodiments, one or more steps in each embodiment may be skipped, and one or more steps in each embodiment may be separated from that embodiment to become an independent technical solution. In some modified embodiments, the order of steps in each embodiment may be changed in a reasonable manner.

[0210] Based on the description of the above embodiments, the present invention can be implemented solely in hardware, or it can be implemented using software and necessary general-purpose hardware platforms. Based on this understanding, the technical solution of the present invention can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transient storage medium, such as a compact disk read-only memory (CD-ROM), a USB flash drive, or a removable hard drive. The software product includes several instructions that enable a computer device (personal computer, server, or network device) to perform the methods provided in the embodiments of the present invention. For example, such performance may correspond to the simulation of the logical operations described herein. The software product may additionally or alternatively include multiple instructions that enable a computer device to perform operations configuring or programming a digital logic device according to embodiments of the present invention. Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented using one or more chip products.

[0211] Although the invention has been described with reference to specific features and embodiments thereof, it will be apparent that various modifications and combinations thereof can be made without departing from the invention. The specification and drawings are therefore to be regarded merely as an illustration of the invention as defined in the appended claims and any and all modifications, variations, combinations, or equivalents falling within the scope of this specification are contemplated.

[0212] In various embodiments, the management and control module includes a task management module for interoperating with one or more service modules to execute a specified task, which includes a set of specified jobs or operations. The task management module can interoperate with two or more service modules to execute the specified task, and can enable the establishment of one or more interconnections between the two or more service modules to support the specified task. One or more terminals and / or application servers can be operatively coupled to one or more service modules and run to support the specified task. Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit this application. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the above embodiments, or equivalent substitutions can be made to some or all of the technical features without departing from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method of managing a selection of functions, characterized by, The method comprises: The first task management function sends a registration request message, wherein the registration request message indicates one or more tasks supported by the first task management function or one or more subtasks supported by the first task management function; The first task management function receives a first request message, wherein the first request message indicates a requested task; The first task management function determines one or more target task management functions, wherein the one or more target task functions are capable of providing the requested task or one or more subtasks involved in the requested task; The first task management function selects at least a second management function from the first task function and the one or more target task management functions.

2. The method of claim 1, wherein, The first task management function determining the one or more target task management functions comprises: The first task management function determines whether the one or more target task management functions capable of providing the requested task exist in the network.

3. The method of claim 2, wherein, The first task management function determines that the one or more target task management functions capable of providing the requested task do not exist in the network, and the method further comprises: The first management function sends a discovery message, wherein the discovery message indicates the one or more subtasks involved in the requested task.

4. The method of claim 3, wherein, The method further comprises: The first management function receives one or more target task management function IDs indicating the one or more target task management functions, wherein the one or more target management functions are capable of providing the requested task.

5. The method of claim 3, wherein, The method further comprises: The first management function receives one or more candidate task management function IDs indicating the one or more candidate task management functions, wherein the one or more candidate management functions are capable of providing the one or more subtasks involved in the requested task; The first management function sends a second request message to the one or more candidate task management functions; The first management function receives one or more response messages from the one or more candidate task management functions; The first management function determines the one or more target task management functions from the one or more candidate task management functions based on the one or more response messages.

6. The method according to any one of claims 1 to 5, characterized in that, The registration request message comprises at least one of the following: a task ID, a task context, a subtask ID, and a subtask context, wherein the task ID indicates the task supported by the first task management function, the task context is used to describe the task supported by the first task management function, the subtask ID indicates the subtask supported by the first task management function, and the subtask context is used to describe the subtask supported by the first task management function.

7. The method according to any one of claims 1 to 6, characterized in that, The second request message comprises at least one of the following: a task ID indicating the requested task, a task context describing the requested task, a subtask ID indicating a subtask involved in the requested task, and a subtask context describing the subtask not involved in the requested task.

8. An initial access method, characterized by, The method comprises: A radio access network (RAN) receives an access request message from a terminal device, wherein the access request message comprises at least one requested task ID indicating at least one requested task; The RAN determines at least one allowed task from the at least one requested task; The RAN sends a task ID of the at least one allowed task to the terminal device.

9. The method of claim 8, wherein, The RAN determining the allowed task ID from the at least one requested task ID comprises: The RAN determines whether there is an overlap between at least one supported task ID and the at least one requested task ID, wherein the at least one supported task ID indicates at least one task supported by at least one task management function of the RAN and / or a core network (CN); The RAN selects the overlapped task ID as the allowed task ID.

10. The method of claim 8, wherein, The RAN determining the allowed task ID from the at least one requested task ID comprises: The RAN sends an initial terminal message to a core network (CN), wherein the initial terminal message comprises the at least one requested task ID; The RAN receives one or more allowed task IDs of the at least one allowed task from the CN.

11. The method of claim 8, wherein, The RAN determining the allowed task ID from the at least one requested task ID comprises: The RAN determines that one or more of the at least one requested task ID does not overlap with any supported task ID indicates at least one task supported by at least one task management function of the RAN; or supported task ID indicates at least one task supported by at least one task management function of the RAN; or The RAN determines that the RAN does not support one or more requested task IDs in the at least one requested task ID in a cell, a tracking area or a network to which the terminal device requests to access; The RAN sends an initial terminal message to a core network (CN), wherein the initial terminal message comprises one or more requested task IDs in the at least one requested task ID; The RAN receives one or more allowed task IDs of the at least one allowed task from the CN.

12. The method of claim 8, wherein, The RAN determining the allowed task ID from the at least one requested task ID comprises: The RAN determines at least one overlapped task ID between the at least one requested task ID and at least one supported task ID, wherein the at least one supported task ID indicates at least one task supported by at least one task management function of the RAN; The RAN sends an initial terminal message to a core network (CN), wherein the initial terminal message comprises the at least one overlapped task ID; The RAN receives one or more allowed task IDs of the at least one allowed task from the CN.

13. The method of claim 12 The method is characterized in that, The RAN determining the at least one overlapped task ID further comprises: The RAN determines that the RAN supports the at least one overlapped task ID in a cell, a tracking area or a network to which the terminal device requests to access.

14. The method of claim 10, wherein, The RAN determining the allowed task ID from the at least one requested task ID comprises: The RAN determines at least one overlapping task ID between the at least one requested task ID and at least one supported task ID, wherein the at least one supported task ID indicates at least one task supported by at least one task management function of the RAN; The RAN determines that one or more of the at least one requested task ID does not overlap with any supported task ID, wherein the supported task ID indicates at least one task supported by at least one task management function of the RAN; or The RAN determines that the RAN does not support one or more of the at least one requested task ID in a cell, a tracking area or a network to which the terminal device requests to access; The RAN sends an initial terminal message to a core network (CN), wherein the initial terminal message comprises the at least one overlapping task ID and one or more of the at least one requested task ID; The RAN receives one or more allowed task ID of the at least one allowed task from the CN.

15. The method according to any one of claims 10 to 14, characterized in that, The initial terminal message further comprises one or more of: a terminal device context and a RAN capability.

16. The method of claim 15, wherein, The UE context comprises one or more of: a cell ID identifying the cell in which the terminal device is located, a tracking area ID identifying the tracking area in which the terminal device is located, a public land mobile network (PLMN) ID identifying the public network in which the terminal device is located or requests to access, a non-public network (NPN) ID identifying the non-public network in which the terminal device is located or requests to access, and a computing and communication capability of the terminal device when performing the task.

17. The method of claim 15, wherein, The RAN capability comprises one or more of: a task ID supported by the RAN, a work ID supported by the RAN and a sub-task ID supported by the RAN.

18. The method of claim 8, wherein, The RAN receives the access request message from the terminal device comprises: Before the RAN receives the access request message, the radio access network (RAN) sends at least one supported task ID to the terminal device.

19. The method of claim 18, wherein, The method further comprises: The RAN sends the at least one supported task ID together with one or more of: a cell ID, a network ID and a tracking area ID.

20. The method of claim 18 or 19, wherein, The RAN sends the at least one supported task ID to the terminal device comprises: The RAN sends the at least one supported task ID to the terminal device by one or more of: a broadcast message, a unicast message, system information, a radio resource control (RRC) message, a paging message and a dedicated signaling message sent to the terminal device.

21. The method of any one of claims 8 to 20, wherein, The method further comprises: The RAN receives a setup request message from the terminal device, wherein the setup request message is used to request to establish a task data plane for a first requested task, the first requested task being one of the tasks indicated by the at least one allowed task ID.

22. The method of claim 21, wherein, The method further comprises: The RAN determines that the RAN can perform the first requested task by itself; The RAN responds to the terminal device that the task data plane is successfully established.

23. The method of claim 21, wherein, The method further comprises: The RAN determines that the RAN cannot perform the first requested task by itself; The RAN sends the setup request message to a core network (CN); The RAN receives a setup response message from the CN, wherein the setup response message comprises at least one of the following: a task ID of the first requested task, a sub-task ID identifying a sub-task involved in the first requested task and to be provided by the RAN, a work ID identifying a work involved in the first requested task and to be provided by the RAN, a task session ID identifying the task data plane, and a task context comprising an indication whether the RAN should be involved in the task data plane; The RAN responds to the terminal device that the task data plane is successfully established.

24. The method of claim 22 or 23, wherein, The RAN responding to the terminal device that the task data plane is successfully established comprises the RAN responding to the terminal device with one or more of the following: a task ID of the first requested task, a sub-task ID identifying a sub-task to be provided by the terminal device involved in the first requested task, a work ID identifying a work to be provided by the terminal device involved in the first requested task, a task session ID identifying the task data plane, a task context comprising an indication whether the terminal device should be involved in the task data plane, a radio bearer ID, and configuration parameters on a radio bearer identified by the radio bearer ID.

25. The method of claim 24, wherein, The method further comprises: The RAN responds to the terminal device by one or more of the following: a broadcast message, a unicast message, system information, a radio resource control (RRC) message, a paging message, and a dedicated signaling message sent to the terminal device.

26. An initial access method, comprising: Comprise: A radio access network (RAN) receives a setup request message from a CN, wherein the setup request message is used to request to establish a task data plane for a first requested task requested by a network function (NF) or an application function (AF); The RAN responds to the CN with a setup response message that the task data plane is successfully established.

27. The method of claim 26, wherein, The setup request message comprises at least one of the following: a task ID of the first requested task, a subtask ID identifying a subtask involved in the first requested task and to be provided by the RAN side, a work ID identifying a work involved in the first requested task and to be provided by the RAN side, a task session ID identifying the task data plane, and a task context including an indication of whether the RAN should be involved in the task data plane.

28. The method of claim 26, wherein, The method further includes: The RAN requests one or more terminal devices to establish the task data plane.

29. The method of claim 28, wherein, The method further includes: The RAN determines that a terminal device is to be involved in the task; The RAN selects the one or more terminal devices.

30. The method of claim 28, wherein, The RAN requesting the one or more terminal devices to establish the task data plane includes the RAN sending to the terminal device at least one of: a task ID of the first requested task, a subtask ID identifying a subtask to be provided by the terminal device involved in the first requested task, a work ID identifying a work to be provided by the terminal device involved in the first requested task, a task session ID identifying the task data plane, a task context including an indication of whether the terminal device should be involved in the task data plane, a radio bearer ID, and configuration parameters on a radio bearer identified by the radio bearer ID.

31. The method of claim 30, wherein, The method further includes: The RAN sends to the terminal device one or more of a broadcast message, a unicast message, system information, a radio resource control (RRC) message, a paging message, and a dedicated signaling message to the terminal device.

32. The method of any one of claims 28-31, wherein, Prior to the requesting, the method further includes: The RAN receives a report message from the terminal device; The report message includes one or more of: a supported task ID identifying a task that the terminal device supports to perform, a subtask ID identifying a subtask that the terminal device supports to perform, a work ID identifying a work that the terminal device supports to perform, and a computing and communication capability of the terminal device when performing the task.

33. An apparatus, comprising: comprising a processor to execute instructions stored in a memory, the instructions, when executed by the processor, performing the method of any of claims 1-7.

34. An apparatus comprising: comprising a processor to execute instructions stored in a memory, the instructions, when executed by the processor, performing the method of any of claims 8-26.

35. An apparatus comprising: comprising a processor to execute instructions stored in a memory, the instructions, when executed by the processor, performing the method of any of claims 27-32.

36. A computer-readable storage medium including instructions, wherein: The instructions, when executed by a computer, cause the computer to perform the method of any of claims 1-7.

37. A computer-readable storage medium including instructions, wherein: The instructions, when executed by a computer, cause the computer to perform the method of any of claims 8-26.

38. A computer-readable storage medium including instructions, wherein: The instructions, when executed by a computer, cause the computer to perform the method of any of claims 27-32.

Images