Systems and methods for segment routing (SR)-based data forwarding and data processing

Abstract

The present disclosure provides systems and methods for SR-based data forwarding and data processing. According to one aspect, a method is provided. The method includes generating a plurality of module block information (MBIs) and one or more fork indications (FIs). Each MBI corresponds to one of the plurality of modules participating in the task. Each FI indicates a bifurcated module of the plurality of modules, where each bifurcated module divides the data path into a plurality of bifurcated paths. The method may also include arranging the plurality of MBIs and the one or more FIs into an ordered list based on a sequence of participation of the plurality of modules in the task. The method may also include sending the ordered list to one or more service controllers.

Description

Technical Field

[0001] This disclosure relates to the field of communication networks, and more particularly to systems and methods for SR-based data forwarding and data processing. Background Technology

[0002] Future networks may operate in part based on the concept of task management. Under this concept, data can be forwarded to perform tasks, potentially involving multiple data paths (including branching paths) and data aggregation points. However, existing technologies for data forwarding prevent loop transmissions, which may be necessary in future networks for tasks such as data processing. Furthermore, existing technologies, such as those relying on multicast distribution trees (MDTs), may require frequent configuration and updates at each involved node, leading to performance limitations. In addition to these constraints, existing technologies may have limited or weak scalability in data processing configuration, further hindering their suitability for future networks.

[0003] Therefore, there is a need for systems and methods for SR-based data forwarding and data processing that avoid or reduce one or more limitations of existing technologies.

[0004] This background information is provided to disclose information that the applicant believes may be relevant to the present invention. It is not intended to acknowledge, nor should it be interpreted, that any of the foregoing information constitutes prior art to the present invention. Summary of the Invention

[0005] This disclosure provides systems and methods for SR-based data forwarding and data processing. According to one aspect, a method for programming processing information used for data forwarding and data processing can be provided. The method can be performed by a control plane function (e.g., a task management function or mission manager (MM)). The method includes: the control plane function generating multiple module block information (MBIs) and one or more fork indications (FIs). Each MBI may correspond to one of multiple modules participating in the task. The one or more FIs may indicate one or more fork modules among the multiple modules, wherein each of the one or more fork modules divides a data path into multiple fork paths. The method may further include: the control plane function arranging the multiple MBIs and the one or more FIs into an ordered list based on the participation order of the multiple modules in the task. The method may further include: the control plane function sending the ordered list to one or more service controllers.

[0006] The control plane function, based on the task participation order of the multiple modules, arranges the multiple MBIs and one or more FIs into an ordered list, which may include: the control plane function setting the first MBI corresponding to the first module among the multiple modules in the ordered list, where the first module is the first module to participate based on the participation order.

[0007] The method may further include: the control plane function setting one or more MBIs in the ordered list and after the first MBI, the one or more MBIs corresponding to one or more modules participating in the task, the one or more modules following the first module up to and including a first fork module, the one or more MBIs being arranged according to the participation order of the corresponding one or more modules and the first fork module in the task, the first fork module dividing the data path into multiple fork paths of the first fork module.

[0008] The first module may be the first fork module, and the first MBI may be the MBI of the first fork module.

[0009] The method may further include: placing multiple sets of processing data in the ordered list after the MBI of the first fork module. Each set of processing data may correspond to a corresponding fork path among the multiple fork paths of the first fork module. Each set of processing data may include one or more MBIs, the one or more MBIs corresponding to one or more modules in the corresponding fork path. Each set of processing data may also include FI, the FI corresponding to a first module in the corresponding fork path that participates in the task after the first fork module.

[0010] The multiple branch paths of the first branch module execute the task in parallel.

[0011] Setting multiple sets of processing data in the ordered list after the MBI of the first fork module may include: for each of the multiple fork paths of the first fork module, setting a corresponding FI and a corresponding one or more MBIs in the ordered list based on the participation order of one or more modules in the corresponding fork path in the task.

[0012] The method may further include setting the FI corresponding to the first fork module in the ordered list, after the MBI of the first fork module and before the multiple sets of processed data.

[0013] At least one of the plurality of forked paths of the first forked module may include one or more forked modules. For each of the plurality of forked paths, each of the one or more forked modules may divide a corresponding data path into a corresponding plurality of forked paths. For each of the plurality of forked paths, the one or more forked modules and the first forked module may participate in the task according to the participation order. For each of the plurality of forked paths, the method may further include: for each corresponding forked module, setting first processing data in the ordered list after the MBI of the forked module preceding each forked module, as determined according to the participation order. The first processing data may include one or more MBIs corresponding to one or more modules participating in the task, the one or more modules following the forked modules preceding each forked module, up to and including each forked module. The first processing data may also include FI, the FI corresponding to a first module participating in the task after the forked modules preceding each forked module.

[0014] For each of the at least one fork in the plurality of fork paths, the method may further include: for each corresponding fork module among the one or more fork modules, the control plane function sets multiple sets of processing data in the ordered list and after the first processing data. Each set of processing data may correspond to a corresponding fork path among the corresponding plurality of fork paths for each fork module. Each set of processing data may include one or more MBIs, the one or more MBIs corresponding to one or more modules participating in the corresponding fork path. Each set of processing data may further include FI, the FI corresponding to a first module participating in the task after each fork module in the corresponding fork path.

[0015] For each set of processed data in at least one of the multiple sets of processed data, the corresponding one or more MBIs may correspond to one or more modules, which participate in the corresponding fork path up to and including the fork modules in the one or more fork modules following each fork module, as determined according to the order of participation.

[0016] The corresponding multiple forked paths of each of the multiple forked modules can execute the task in parallel.

[0017] The one or more MBIs and FIs in the first processed data can be arranged according to the participation order of their corresponding one or more modules in the task. The one or more MBIs and FIs in each group of processed data can be arranged according to the participation order of their corresponding one or more modules in the task.

[0018] For each of the one or more fork modules in at least one of the plurality of fork paths of the first fork module, the method may further include: setting the FI corresponding to the fork module preceding each fork module in the ordered list, after the MBI of the fork module preceding each fork module and before the first processed data.

[0019] For each of the one or more fork modules in at least one of the plurality of fork paths of the first fork module, the method may further include: setting the FI corresponding to each fork module in the ordered list, after the first processed data and before the plurality of sets of processed data.

[0020] The method may further include: setting the FI value to correspond to the FI of the first fork module. The method may further include: for each FI corresponding to each fork module, setting a corresponding FI value based on the FI value of the FI corresponding to the fork module preceding each fork module.

[0021] Each of the plurality of MBIs may include one or more of the following: path selection information (PSI), function indication, metric, and data aggregation indication (DAI). The PSI may indicate one or more of the following: a path identifier (ID) identifying a traffic path from the processing function (PF) corresponding to each MBI to the next-hop PF of that PF; a connection ID identifying the connection between the PF and the next-hop PF; the ID of the next-hop PF; the ID of the radio bearer; and the ID of the PF.

[0022] The function indicator may be one or more IDs of one or more functions, and one or more power processes (PFs) participating in the task process data according to the one or more functions. The one or more functions may include: data processing type, data processing algorithm, the task, branch tasks of the task, and subtasks of the task.

[0023] The metric indicates the data processing requirements of each module of the MBI, and the metric includes one or more of the following: quality of service (QoS) requirements for one or both of data processing and data forwarding, parameters for security protection, parameters for integrity protection, parameters for authentication, input data format, and output data format.

[0024] According to another approach, a different method is provided. This method can be performed by a PF entity participating in a task. The method includes: the PF entity receiving an ordered list of multiple module block information (MBIs) and one or more fork indications (FIs). Each MBI may correspond to one of the multiple modules participating in the task. The one or more FIs may indicate one or more forked modules among the multiple modules. The multiple MBIs and the FIs are arranged in the ordered list based on the participation order of the multiple modules in the task. The method may further include: the PF entity encapsulating a message header with updated processing data based on the ordered list. The method may further include: the PF entity sending the encapsulated message to a next-hop PF entity. The encapsulated message may be sent based on path selection information (PSI) of the PF entity's MBIs, which are included in the ordered list.

[0025] The PF entity may receive the ordered list from the service controller. The updated processing data may include the ordered list of the MBI and one or more FIs, but does not include the MBI of the PF entity.

[0026] The PF entity can be located in a fork module, and the next-hop PF entity can be on the first fork path among multiple fork paths starting from the PF entity. The updated processing data can include one or more MBIs from the multiple MBIs, and the one or more MBIs correspond to one or more modules from the multiple modules participating in the first fork path. The one or more MBIs can be arranged according to the task participation order of the one or more modules in the first fork path. The encapsulated message can be a unicast message.

[0027] The updated processing data may further include one or more FIs of one or more fork modules participating in the first fork path. The one or more MBIs and the one or more FIs may be arranged according to the task participation order of the one or more modules and the one or more fork modules in the first fork path.

[0028] The PF entity may be located in a fork module. Sending the encapsulated message from the PF entity to the next-hop PF entity may include: the PF entity sending the encapsulated message as a multicast message to each of the multiple next-hop PF entities. Each of the multiple next-hop PF entities may be on a corresponding fork path in a plurality of fork paths originating from the PF entity.

[0029] For each of the plurality of next-hop PF entities, the identifier (ID) of each next-hop PF entity is indicated in the MBI of each next-hop PF entity included in the ordered list, and the updated processing data may include one or more of the MBIs and FIs of a set of modules participating in the plurality of forked paths.

[0030] For each of the plurality of next-hop PF entities, the identifier (ID) of each next-hop PF entity is indicated in the MBI of the PF entity, and the updated processing data may include one or more of the MBI and FI of the PF entity and a set of modules of the plurality of modules participating in the plurality of forks.

[0031] The method may further include: the PF entity processing the data based on the data processing configuration to obtain the processing result, wherein the processing result is included in the payload of the encapsulated message.

[0032] The data processing configuration can be indicated by one of the following: a message received by the PF entity from a control plane function instructing one or more functions, according to which the PF entity processes the data; or the MBI of the PF entity.

[0033] The PF entity may be located in a user equipment, and the encapsulated message is transmitted via a radio bearer identified by the PSI of the MBI of the PF entity, wherein the MBI of the PF entity is included in the ordered list.

[0034] The method may further include: the PF entity receiving the data associated with the task from another PF entity at the user equipment.

[0035] The PF entity receives the ordered list in the header of the message from another PF entity. The method may further include: the PF entity receiving the data associated with the task in the message from the other PF entity.

[0036] One of the PF entity and the next-hop PF entity can be a core network (PF) entity and the other can be a radio access network (RAN) PF. The PF entity can be a core network (CN) PF entity and the next-hop PF entity can be a radio access network (RAN) PF.

[0037] The next-hop PF entity can be located in user equipment (UE), and the encapsulated message can be transmitted via a radio bearer identified by the path selection information (PSI) of the MBI of the PF entity. The MBI of the PF entity can be included in the ordered list. The PF entity can be a radio access network (RAN) PF entity.

[0038] Each of the plurality of MBIs may include one or more of the following: corresponding path selection information (PSI), function indication, metric, and data aggregation indication (DAI). The corresponding PSI may indicate one or more of the following: a path identifier (ID) identifying the traffic path from the processing function (PF) of each MBI to the next-hop PF; a connection ID identifying the connection between the PF of the MBI and the next-hop PF; the ID of the next-hop PF; the ID of the radio bearer; and the ID of the PF of each MBI.

[0039] The function indicator may be one or more IDs of one or more functions, and one or more power processes (PFs) participating in the task process data according to the one or more functions. The one or more functions may include: data processing type, data processing algorithm, the task, branch tasks of the task, and subtasks of the task.

[0040] The metric can indicate the data processing requirements of the module corresponding to each MBI. The metric may include one or more of the following: quality of service (QoS) requirements for one or both of data processing and data forwarding, parameters for security protection, parameters for integrity protection, parameters for authentication, input data format, and output data format.

[0041] According to another aspect, an apparatus is provided. The apparatus includes modules for performing one or more of the methods and systems described herein.

[0042] According to one aspect, an apparatus is provided, wherein the apparatus includes: a memory for storing a program; and a processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to perform one or more of the methods and systems described herein.

[0043] According to another aspect, a computer-readable medium is provided, wherein the computer-readable medium stores program code executable by a device, the program code being used to perform one or more of the methods and systems described herein.

[0044] According to one aspect, a chip is provided, wherein the chip includes a processor and a data interface, the processor reading instructions stored in a memory through the data interface to execute one or more of the methods and systems described herein.

[0045] Other aspects of this disclosure provide apparatus and systems for implementing the methods according to the first aspect disclosed herein. For example, wireless stations and access points may be configured with machine-readable storage including instructions that, when executed by a processor of these devices, cause the devices to perform one or more of the methods and systems described herein.

[0046] The embodiments described above in conjunction with various aspects of the present invention can be implemented based on these aspects. Those skilled in the art will understand that embodiments can be implemented in conjunction with the aspects described therein, but may also be implemented together with other embodiments of that aspect. It will be apparent to those skilled in the art that embodiments are mutually exclusive or incompatible. Some embodiments may be described in conjunction with one aspect, but may also be applicable to other aspects, as will be apparent to those skilled in the art. Attached Figure Description

[0047] Further features and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0048] Figure 1A The task is shown, which includes several sub-tasks.

[0049] Figure 1B It is shown in the form of a processing function (PF). Figure 1A The task.

[0050] Figure 2This illustrates segment routing multiprotocol label switching (SR-MPLS) based on adjacency segment identifiers (SIDs).

[0051] Figure 3 The packet format for segment routing over IPv6 (SRv6) is shown.

[0052] Figure 4 The information included in the segment list of an SRV6 message is shown.

[0053] Figure 5 The SRv6 spray for multicast transmission is shown.

[0054] Figure 6 The Tree-SID in SRv6 and Multiprotocol Label Switching (MPLS) is shown.

[0055] Figure 7 This illustrates one aspect of the applicable XaaS system architecture.

[0056] Figure 8 This illustrates the connection between two boundary processing functions provided by one aspect.

[0057] Figure 9 This illustrates a PF that provides one aspect for participating in multiple tasks.

[0058] Figure 10 This illustrates a task provided by one aspect, which includes multiple paths with branching and aggregation points.

[0059] Figure 11A The header provided by one aspect is shown.

[0060] Figure 11B It is provided by one aspect Figure 11A Another illustration of the message header.

[0061] Figure 12 This shows the traffic of a task without branching provided by one aspect.

[0062] Figure 13 The header of a message for a straight data path provided by one aspect is shown.

[0063] Figure 14 This illustrates one aspect of the process provided for programming data routing and processing information.

[0064] Figure 15A The programming of the MBI and FI of the first forked module provided by one aspect is shown.

[0065] Figure 15B One aspect provided is shown in Figure 15A Further programming of MBI and FI following the initial programming.

[0066] Figure 15C One aspect provided is shown in Figure 15B Further programming of MBI and FI following the initial programming.

[0067] Figure 15D One aspect provided is shown in Figure 15C Further programming of MBI and FI following the initial programming.

[0068] Figure 16 A first method for message header decapsulation provided by one aspect is shown.

[0069] Figure 17 A second method for message header decapsulation is shown as one aspect.

[0070] Figure 18 This illustrates how a source node sends data to a receiver based on one aspect.

[0071] Figure 19 One aspect provided includes corresponding Figure 10 The MBI and FI of the message header of the path segment.

[0072] Figure 20 It shows that, according to one aspect, Figure 10 M[k] and M[j] through Figure 16 The method receives the message header.

[0073] Figure 21 It shows that, according to one aspect, Figure 10 M[m] and M[a] through Figure 16 The method receives the message header.

[0074] Figure 22 It shows that, according to one aspect, Figure 10 M[a] and M[p] through Figure 16 The method receives the message header.

[0075] Figure 23 It shows that, according to one aspect, Figure 10 M[k] and M[j] through Figure 17 The method receives the message header.

[0076] Figure 24It shows that, according to one aspect, Figure 10 M[m] and M[a] through Figure 17 The method receives the message header.

[0077] Figure 25 It shows that, according to one aspect, Figure 10 M[a] and M[p] through Figure 17 The method receives the message header.

[0078] Figure 26A and Figure 26B This illustrates one aspect of the process for configuring and executing tasks based on SR.

[0079] Figure 27 This shows the path information (path table) provided by one aspect.

[0080] Figure 28 One aspect of the method provided is shown for programming processing information used for data forwarding and data processing.

[0081] Figure 29 This illustrates another approach offered by one aspect.

[0082] Figure 30 The apparatus provided by different aspects of this disclosure is shown, which can perform any or all of the methods and features described above, whether explicitly or implicitly, herein.

[0083] It should be noted that the same features are identified by the same reference numerals throughout the accompanying drawings. Detailed Implementation

[0084] This disclosure provides systems and methods for data forwarding and data processing. According to one aspect of this disclosure, a method for programming processing information used for data forwarding and data processing can be provided.

[0085] This method can be performed by a control plane function (e.g., a mission manager, MM). The method includes generating multiple module block information (MBIs) and one or more fork indications (FIs). Each MBI may correspond to one of multiple modules participating in the task. The one or more FIs may indicate one or more forked modules among the multiple modules, wherein each of the one or more forked modules divides a data path into multiple forked paths. The method may further include: the control plane function arranging the multiple MBIs and the one or more FIs into an ordered list based on the participation order of the multiple modules in the task. The method may further include: the control plane function sending the ordered list to one or more service controllers.

[0086] According to another approach, a different method is provided. This method can be performed by a PF entity participating in the task. The method includes: the PF entity receiving an ordered list of multiple module block information (MBIs) and one or more fork indications (FIs). Each MBI may correspond to one of the multiple modules participating in the task. The one or more FIs may indicate one or more forked modules among the multiple modules. The multiple MBIs and the FIs are arranged in the ordered list based on the participation order of the multiple modules in the task. The method may further include: the PF entity encapsulating a message header with updated processing data based on the ordered list. The method may further include: the PF entity sending the encapsulated message to the next-hop PF entity. The encapsulated message may be sent based on path selection information (PSI) of the PF entity's MBIs, which are included in the ordered list.

[0087] In sixth-generation (6G) wireless communication systems, the X as a Service (XaaS) network was proposed. This network operates based on the concept of task management. Figure 1AThe diagram illustrates a task comprising several subtasks. As shown, task 100 may include several subtasks (e.g., subtasks 101 to 109), and each subtask may be provided by a 6G service, such as data analytics and management (DAM) service, network for artificial intelligence (NET4AI) service, etc.

[0088] The subtasks of Task 100 can be executed in a specific order, and each subtask can be executed by a data processing function (PF) on the data plane, such as... Figure 1B As shown. Figure 1B It is shown in the form of PF Figure 1A The task 150 corresponds to task 100 in terms of data PF or PF. Therefore, subtask 101 can be executed by data PF (or PF) 111, subtask 102 can be executed by PF 112, and similarly, for each of the remaining subtasks, the corresponding PF can execute that subtask.

[0089] Data can be transmitted to the User Plane Function (PF), and the PF can perform one or more data processing functions, such as data cleaning, AI training, AI inference, data analysis, data privacy protection, and data storage. In 6G networks, both data forwarding and data processing may be required on the data plane to perform these tasks. In some respects, the PF can be an evolved user plane function (UPF).

[0090] As described above, task 100 can be executed in a specific order. For example, task 100 can first be executed according to solid arrow 120 (e.g., forwarding data and executing subtasks), and then according to dashed arrow 130. Therefore, task 100 can be executed according to a data forwarding sequence. Task 100 can first forward data according to a first data path based on solid arrow 120, and then forward data according to a second data path based on dashed arrow 130.

[0091] The traffic topology of Task 100 can be described as follows. The traffic path of the task can be a directed graph. The traffic path may include path branches, for example, a message being sent from PF 112 to both PF 113 and PF 114. That is, multicast transmission may be required. In some aspects, the path may have one or more transmission loops and is not loop-free, which is different from data forwarding in traditional networks. In traditional networks, data forwarding is performed to avoid transmission loops. However, in future 6G services, transmission loops may exist for data processing. For example, data forwarded from PF 112 to PF 113 and further forwarded to PF 115 (based on the data path associated with the solid arrow) can then be forwarded back to PF 112 from PF 117 and PF 115 (based on the data path associated with the dashed arrow). At the same time, PF 115 can receive data from two path segments PF 112-PF 114-PF 115 and PF 112-PF 113-PF 115. Traffic paths can have aggregation points, for example, at PF 115.

[0092] Source routing is a data forwarding scheme. In source routing, the source selects a path and encodes it in the packet header as an ordered list of segments. The rest of the network executes the encoded instructions. Segment routing (SR) is a technique that uses source routing to forward packets in a network. SR divides the network path into segments and assigns a segment ID (SID) to each segment. These segments are arranged sequentially in a segment list, forming a forwarding path. Based on the information carried in the packet, the packet is forwarded between segments.

[0093] Because more information can be added and carried in messages, less state needs to be maintained in the network, and it is possible to simplify the context used for data forwarding that needs to be maintained in the network.

[0094] Based on the forwarding plane, segment routing can be divided into two categories. Segment routing using multiprotocol label switching (MPLS) (SR-MPLS) is based on the MPLS forwarding plane, while segment routing over IPv6 (SRv6) is based on the IPv6 forwarding plane.

[0095] In SR-MPLS, an ordered list of segments is represented as a stack of labels. In SRv6, the ordered list of segments is encoded in the route extension header.

[0096] In SR-MPLS, segment IDs can be defined using three types: node SID, adjacency SID, and prefix SID. For example, see [reference needed]. Figure 2 Describe the adjacent SID. Figure 2 This illustrates segment routing multiprotocol label switching (SR-MPLS) based on adjacency SID. (See reference...) Figure 2 Node A 201 may need to send a message to node Z 208. To route the message, an adjacency segment (identified by a SID) can be assigned to each adjacency between the two nodes. Then, source node A201 can choose a path (e.g., A201-B 202-D 204-E 205-G 207-Z208) and encapsulate an ordered list of segments in the message header. The ordered list of segments corresponding to this path could be (1002, 2004, 4005, 5007, 7009). The segment list can include multiple adjacency segments and indicates a strict path from source node A201 to receiving node Z 208.

[0097] Starting from node A 201, each node on the path can forward the packet to the next-hop node based on the SID (Sequenced Segment List) until the packet reaches node Z 208. Each node can remove the corresponding SID before sending the packet to the next-hop node. For example, after receiving a packet from node A 201, node B 202 pops SID 2004 from the SID list and forwards the packet to node D204, as shown in the figure.

[0098] SRv6 is an implementation of segment routing (SR) in IPv6. Figure 3 The message format for SRv6 is shown. Message format 300 includes an IPv6 header 302, an SR header (SRH) 304, and a payload. SRH 304 is derived from the IPv6 routing header using the new routing type 4. SRv6 can bring centralized control and programmability to label-based switching.

[0099] The IPv6 header 302 includes several fields indicating: version, traffic class, flow label, payload length, next header = 43, hop count limit, source address, and destination address, as shown in the figure. The destination address (DA) field indicates the destination address of the IPv6 packet in traditional IPv6 packets. The DA is immutable and identifies the final destination, but in SRv6, the DA only identifies the next-hop node of the current packet and is constantly changing.

[0100] SRH 304 includes several fields indicating: next header, header extension length (hdr ext len), route type = 4, segment remainder, last entry, flags, labels, segment list [0] (128-bit IPv6 address) ... segment list [n] (128-bit IPv6 address), and an optional type-length-value (TLV) object (variable). More information about SRH can be found in the standard document "Requests for Comments (RFC)" 8754.

[0101] As shown in the figure, the segment list (e.g., segment list [0] (128-bit IPv6 address) ... segment list [n] (128-bit IPv6 address)) is carried in SRH 304. SRv6 segments are IPv6 addresses, also known as SRv6 SIDs. SRv6 may require reverse encapsulation of the SID. The first SID resolved is located in the innermost layer of the SRH. Similar to the segment list in SR-MPLS, the segment list in SRv6 is encapsulated into the packet header by the source node.

[0102] Figure 4 The diagram illustrates the information included in the segment list of an SRV6 message. The segment list indicates a list of SRv6 SIDs. An SRv6 SID 400 includes a location section 402 and a function section 404. The location section 402 is used for routing and identifying the address of the next-hop node. The function section 404 can identify any function of the device, such as forwarding behavior, service behavior, etc. The function section 404 may also include a function field 406 and an optional arguments field 408. The arguments field 408 can be used to define information such as message flow and services. Both function 406 and arguments 408 can be defined, indicating that the SRv6 SID structure is beneficial for network programming. Therefore, a segment represents an endpoint and a specific action. The segment list can express the behavior in each transmission path, including routing and actions at specific nodes. An SRv6 SID can be viewed as a network instruction. The difference between SRv6 and SR-MPLS is that an SRv6 SID is not popped after being processed by a node.

[0103] The Segments Left (SL) field in SRH 304 indicates the number of remaining route segments (SIDs) for a packet to reach its final destination. Therefore, the SL field indicates the number of intermediate nodes that still need to be traversed before reaching the final destination. The SL field can be a pointer to the position of a list of segments to be processed or activated. The Segments Left and Segments List fields together determine the IPv6 DA field. The value of the SL field is decremented by 1 each time the IPv6 DA changes after traversing an SRv6 node. If the SL value is n, the IPv6 DA value is calculated based on the value of the Segments List [n]. Optional TLV object fields can include global parameters for all SIDs in the Segments List; for example, the TLV provides metadata for segment processing.

[0104] In traditional multicast transmission technologies, such as Resource Reservation Protocol (RSVP), Multicast Label Distribution Protocol (mLDP), and Protocol Independent Multicast (PIM), transmission is based on a multicast distribution tree (MDT) (e.g., shortest-path tree (SPT) or rendezvous point tree (RPT)). The MDT can be calculated by the control plane by computing the tree from the root node to a set of leaf nodes.

[0105] In multicast networks, each node (e.g., a router) maintains a data forwarding table, which can include multiple multicast routing entries. Each multicast routing entry includes four key pieces of information: multicast source address, multicast group address, upstream interface, and downstream interface. Multicast routing entries ensure that multicast messages are transmitted along the multicast routing table (MDT). Multicast routing entries are categorized as (S,G) and (*,G). S indicates the address of the multicast source, G indicates the address of the multicast group, and * indicates any multicast source. Each multicast node can maintain different multicast routing entries for different MDTs (i.e., different multicast sources, different multicast groups). In large multicast networks (e.g., with many multicast sources and multicast groups), the memory space of multicast nodes becomes bloated with multicast routing entries, leading to weak or insufficient network performance.

[0106] In SR multicast transmission technologies, SR-MPLS and SRv6 utilize a concept similar to the multicast distribution tree (MDT) to achieve multicast transmission. The tree segment identifier (Tree-SID) is a tree construction scheme that can be applied to SR-MPLS. Tree-SID uses a single MPLS label to construct the multicast replication tree in an SR network. Tree-SID can also be applied to SRv6. SRv6 Spray can also support multicast transmission. In Spray, the network is divided into SRv6 domains and multicast domains. The SID in the SRH can specify unicast-based transmission within an SRv6 domain, or group-based transmission within each multicast domain.

[0107] Figure 5 The SRv6 spray for multicast transmission is shown. Figure 5 The SRv6 spray technology shown utilizes SRv6 for unicast transmission of multicast messages. SRv6 spray employs ingress replication technology.

[0108] As shown in the figure, the edge points are deployed between the SRv6 domain 502 and the IPv6 multicast domain 504. The source node 510 replicates the multicast message and uses SRv6 to unicast the message to the edge points (e.g., edge points 611, 612, and 613).

[0109] Multicast transmissions to receivers begin at the edge of the network (i.e., edge points). Edge points maintain multicast routing table entries (S,G) or (*,G) for the multicast domain. However, for SRv6 spray, multicast transmissions are not supported within the SRv6 domain. Multicast transmissions are still based on multicast routing table entries (S,G) or (*,G) in the multicast domain, requiring the computation of the multicast routing table (MDT).

[0110] Figure 6 The diagram illustrates the Tree-SID in SRv6 and MPLS. The MDT 600 includes nodes A 601, B 602, C 603, D 604, E 605, and F 606, as shown in the figure. The MDT 600 can be calculated by the control plane based on a specific policy. The Tree-SID (e.g., it can be used as an MPLS label or an SRv6 segment) and a replication list are configured for each node in the MDT 600. For example, the tree-SID of the MDT 600 is 100. The source node A601 encapsulates the Tree-SID into a multicast packet, replicates the packet based on the configured replication list, and forwards it to the next-hop node (e.g., B 602 and C 603). The next-hop nodes (e.g., B 602 and C 603) replicate the multicast packet based on the replication list and forward it to the receiver (e.g., leaf nodes, edge routers), as shown in the figure.

[0111] In SR, a segment list is embedded in the packet for traffic redirection. The underlying tunnel can be shared by multiple data flows, which can be seen as meeting the task management requirements of 6G networks. However, current segment routing technology has limitations or defects that may make it unsuitable for 6G networks, as segment routing may not be sufficient to achieve per-flow or per-tunnel status within the network.

[0112] One of the goals of SR (Synchronous Redirect) for data forwarding is to ensure that no loops occur in the packet forwarding path. However, in future 6G networks and the provision of XaaS, the ability to handle looped data may be required for data processing, for example, as referenced. Figure 1B Data may need to be forwarded from PF 112 to PF 113 to PF 115, and then back to PF 112 (via PF 117). In some cases, messages (e.g., raw messages, processed messages) may need to be transmitted back and forth between two nodes several times. Therefore, the ability to circumvent data flow is needed to accommodate data paths in future networks.

[0113] Current technologies related to SR (Streaming Service) for multicast are primarily based on MDT (Multi-Target Data Transmission), where each node in the MDT is configured with a Tree-SID and a replication list. In this technology, each node can maintain different multicast routing table entries for different MDTs. In a large multicast network with numerous multicast sources and groups, it may be necessary to establish an MDT for each multicast stream, and each node in the MDT may need to maintain multicast state. In such networks, the memory of multicast nodes is consumed by bloated multicast routing table entries, leading to performance degradation. Furthermore, when a new multicast user joins a multicast group, the user needs to join the multicast tree hop-by-hop from the network edge. Additionally, it may be necessary to provide a Tree-SID and replication list to each node in the MDT. Therefore, such networks may require frequent configuration and updates. Due to these limitations, flexible and dynamic data forwarding cannot be achieved. Therefore, it may be necessary to avoid pre-configuring MDTs and replication lists.

[0114] In 6G networks, both data forwarding and data processing should be natively enabled. Data processing configuration can be carried in the packet header. The data processing configuration included in a node's packet header may need to be correctly or appropriately mapped to that node. Fields indicating functions and TLV can be encapsulated in the packet header, for example, in SRv6, and can be used for unicast transmissions. However, existing technologies have limited or weak scalability in terms of data processing configuration. An existing challenge may be correctly mapping the data processing configuration of a specific node (e.g., intermediate nodes in a path) to those nodes involved in multicast packets. For example, some intermediate nodes connected to an aggregation node, or intermediate nodes in a unicast path, may have the same BIFT and FBM, and no BFR-ID has been assigned to them. How to map the data processing configuration of these intermediate nodes has not yet been determined.

[0115] Looping can be achieved in several ways. For example, when a path has forks and aggregations, traffic may follow the correct or appropriate traffic path.

[0116] Some aspects of this disclosure eliminate the need to pre-configure MDT information (e.g., Tree-SID) into network nodes for SR multicast transmission. Other aspects allow message forwarding and replication instructions to be included in the message header, enabling network nodes to flexibly and dynamically perform correct multicast transmissions.

[0117] Existing technologies related to SRs used for data forwarding have limited or weak scalability in terms of data processing configuration. According to some aspects, one or both of the data processing configuration and the data forwarding configuration (e.g., for intermediate nodes, source nodes, or terminal nodes of a path) can be included in the packet header. According to some aspects, the data processing configuration and data forwarding configuration of the same node can be appropriately or correctly bound, and are available and efficient for various situations (e.g., unicast, multicast, loop-free, or non-loop-free).

[0118] In one respect, a traffic path involves multiple nodes. A connection can be established between every two network nodes in the path. A path includes one or more connections. If the network nodes or connections involved in a first path are different from those involved in a second path, then the first path and the second path can be considered different. In some respects, a connection between two network nodes can be shared by different paths, and two paths can share one or more connections. Different paths connecting one node and some other nodes can be configured as multiple candidate paths.

[0119] In some respects, one or more of the block information (BI) and forkindication (FI) can be encapsulated in the packet header to indicate one or more traffic paths. Each BI can be read by network nodes in one or more paths. In some respects, the BI can resemble a segment list in SRv6. Nodes in one or more paths can forward packets hop-by-hop based on the BI and FI, or the processed packet result (both can be referred to as packets). For example, the current network node can forward a packet to the next-hop network node based on the BI and FI.

[0120] In some respects, path selection information (PSI) can be included in each BI to indicate which network node needs to forward the packet to the next-hop network node via the path determined by the PSI. In some respects, the PSI function can be similar to the Locator field of Segment in SRv6.

[0121] In some respects, FI can indicate that the current path has a forked path, that is, the packet should be forwarded by the current node to a next-hop network node or via a different connection to a next-hop network node.

[0122] In some respects, a PSI can be a connection ID identifying a connection between two network nodes. In some respects, a PSI can be a node ID identifying a next-hop network node, such as a node address. In some respects, a PSI can be a radio link ID (e.g., a data radio bearer (DRB) ID), an ID of a newly defined radio bearer for XaaS (e.g., a data processing radio bearer (XRB)), or a logical channel ID (LCID) identifying a radio link (e.g., between user equipment (UE) and the radio access network (RAN)). In some respects, a PSI can be a path ID identifying a traffic path.

[0123] In some respects, FI may not be needed in the packet header. For example, when there is only one fork in the path, the next-hop network node can only be determined by BI. In some respects, for example, when there is no fork in the path, FI may not be needed in the packet header. In some respects, the packet header can be an IP protocol layer header. In some respects, the network node can be a processing function (PF) of an X as a Service (XaaS) module, RAN, core network (CN), or UE, as referenced in this document. Figure 7 , Figure 8 and Figure 9 As stated above.

[0124] In some respects, the message header can be a PF protocol layer header. The PF protocol layer can be deployed on top of the transport network layer (TNL), for example, on General Packet Radio Service (GPRS) Tunneling Protocol-User Equipment (GTP-U), User Datagram Protocol (UDP), Quick UDP Internet Connection (QUIC), Internet Protocol (IP), or SRv6. In some respects, the PF protocol layer can be deployed in the PF unit of an XaaS module, for example, in the RAN, in the UE, etc. In some respects, the block information can be module block information (MBI), which can be read by the PF from one or more of the following: as referenced herein. Figure 7 , Figure 8 and Figure 9 The aforementioned XaaS module, RAN, and UE.

[0125] In some respects, the message header can be a protocol layer header, such as a PF protocol layer header, and the protocol layer can be deployed on one of the following: above the Packet Data Convergence Protocol (PDCP) sublayer; between the Service Data Adaptation Protocol (SDAP) sublayer and the PDCP sublayer; between the PDCP sublayer and the Radio Link Control (RLC) sublayer; between the RLC sublayer and the Media Access Control (MAC) sublayer; between the MAC sublayer and the Physical Layer (PHY); above the SDAP sublayer; above the Protocol Data Unit (PDU) layer; above the GTP-U layer; above the UDP layer; above the IP layer; above the QUIC layer; above the Hypertext Transfer Protocol (HTTP) layer; or above IPv6-based segment routing. Above the IPv6 (SRv6) layer, within the PDU layer, within the SDAP sublayer, within the PDCP sublayer, within the RLC sublayer, within the MAC sublayer, within the PHY layer, within the GTP-U layer, within the UDP layer, within the IP layer, within the application layer, within the HTTP layer, within the SRv6 layer, and within the QUIC layer.

[0126] In some respects, the message header may include a data aggregation indication (DAI) to indicate that some data from a particular path should be aggregated at network nodes for joint data processing rather than independent data processing.

[0127] Depending on some aspects, the control plane (e.g., mission manager (MM) and XaaS service controller (XC)) and data plane (e.g., ingress PF, egress PF) can perform one or more operations to support data forwarding and processing on forked and non-forked paths. For example, the control plane can generate and program one or more of BI, FI, and DAI to encapsulate and decapsulate packet headers accordingly. The MM can control, manage, and configure the network to perform tasks; for example, the MM can control, manage, and configure network functions (e.g., gateways, XaaS modules) to establish resources for performing one or more subtasks involved in the task. As will be understood, the MM may be named using other terms, such as mission control function (MCF).

[0128] Figure 7 An applicable XaaS system architecture is shown for one aspect. System architecture 700 illustrates an exemplary architecture to which one or more aspects of this disclosure may be applied.

[0129] In one aspect, XaaS modules 701 and 702 are deployed on the RAN side 710, and XaaS modules 703 and 704 are deployed on the CN side 730. MMs can be deployed according to a hierarchy (e.g., an MM hierarchy). In some aspects, system architecture 700 may include one or more of a global MM and a domain MM. In some aspects, the hierarchy may be due to a task hierarchy (e.g., tasks under the control of a global MM and branch tasks under the control of a domain MM), or due to a network management hierarchy (e.g., RAN and CN). A domain may refer to a management domain or a task management domain. For example, MMs may be deployed in the RAN and CN respectively, i.e., RAN-MM and CN-MM. The global MM and the domain MM may reside in the same network domain or in different network domains. For example, both MMs (global MM and domain MM) may reside in CN 730 (CN-MM), or in RAN 710 (RAN-MM), or one may reside in the RAN and the other in the CN.

[0130] Each XaaS module may include an XaaS service controller (XC) and one or more service providers (PFs). The XC may connect to the PFs via a T1 interface. Some PFs of the XaaS module may be boundary PFs (e.g., ingress PFs, egress PFs) to connect to external entities.

[0131] One or more gateways (GWs) on the data plane can be deployed in the RAN and CN. In some aspects, a RAN-GW (e.g., GW 705) can be connected to the RAN-PF via the M5 interface. In other aspects, a RAN-GW (e.g., GW 705) can be connected to another RAN-GW (e.g., GW 706) via the M4 interface. In some aspects, a RAN-GW (e.g., GW 705) can be connected to RAN node 707 via the M2 interface. In some aspects, a RAN-GW (e.g., GW 706) can be connected to the CN-GW (e.g., GW 731) via the T3 interface.

[0132] In some respects, a CN-GW (e.g., GW 732) can be connected to a CN-PF via a T5 interface. In some respects, a CN-GW (e.g., GW 732) can be connected to another CN-GW (e.g., GW 733) via a T4 interface. In some respects, a CN-GW (e.g., GW 733 and 733) can be connected to a data network (DN) via a T6 interface.

[0133] In some respects, one or more RAN nodes, either integrated or separate, can be deployed at system architecture 700.

[0134] If an integrated RAN node is deployed (e.g., without a central unit (CU) or distributed unit (DU)), the RAN node (e.g., RAN node 711) can connect to the XC via the M2-C interface. In some aspects, RAN node 711 can connect to the GW (e.g., GW 705) via the M2-U interface. In some aspects, RAN node 711 can connect to the PF via both the M2-U and M5 interfaces. In some aspects, RAN node 711 can connect to RAN-MM 712 via the T7 interface. In some aspects, RAN node 711 can connect to CN-MM 734 via the T8 interface. In some aspects, the RAN node (e.g., RAN node 707) can connect to CN-GW 731 via the T3 interface. In some aspects, RAN node 711 can connect to user equipment (UE) via a radio link.

[0135] If separate RAN nodes are deployed (e.g., CU and DU), in some aspects, the first separate portion (e.g., DU) of RAN node 711 can be connected to XC via the M2-C interface. In some aspects, the DU of RAN node 711 can be connected to GW 705 via the M2-U interface. In some aspects, the DU of RAN node 711 can be connected to PF via the M2-U and M5 interfaces. In some aspects, the DU of RAN node 711 can be connected to UE via a radio link. In some aspects, the second separate portion (e.g., CU) of RAN node 711 can be connected to XC via the M2-C interface. In some aspects, the CU of RAN node 711 can be connected to GW 705 via the M2-U interface. In some aspects, the CU of RAN node 711 can be connected to PF via the M2-U and M5 interfaces. In some aspects, the CU of RAN node 711 can be connected to RAN-MM 712 via the T7 interface. In some aspects, the CU of RAN node 711 can be connected to CN-MM 734 via the T8 interface. In some aspects, the CU of RAN node 707 can be connected to CN-GW 731 via a T3 interface. In some aspects, RAN node 711 is the DU of the RAN base station, and RAN node 707 is the CU of the RAN base station. In some aspects, RAN node 711 is the DU of the RAN base station. In some aspects, RAN node 707 is the CU of the RAN base station.

[0136] In some respects, the RAN-GW (e.g., GW 706) can be directly connected to the CN-GW (e.g., GW 731) via the T3 interface, or (e.g., GW 705) indirectly connected to the CN-GW via a RAN node (e.g., RAN node 707).

[0137] In some respects, the GW can be deployed optionally. In other respects, when no GW is deployed at the RAN, RAN nodes can connect directly to the CN-GW via the T3 interface.

[0138] In some aspects, PFs (i.e., boundary PFs and intermediate PFs) within an XaaS module are internally interconnected via the T2 interface, while 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 730, PFs deployed in different XaaS modules can be interconnected via one or more GWs. On the RAN side 710, PFs deployed in different XaaS modules can be directly interconnected via the T2 interface. In some aspects, RAN-PFs deployed in different XaaS modules can be interconnected via one or more GWs.

[0139] In some cases, the RAN-PF can connect to the CN-GW via the intermediate M5 and T3 interfaces. In other cases, the RAN-PF can connect to the CN-GW via the 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 an intermediate RAN node.

[0140] In some aspects, MMs (e.g., RAN MM 712 or CN MM 734) can be connected to the XC via the T9 interface. In some aspects, hierarchical MMs can be directly interconnected via the T10 interface or interconnected via one or more intermediate entities. For example, hierarchical MMs in the same domain (e.g., all in the CN) can be directly interconnected via the T10 interface (which may be an SBI interface). In some aspects, hierarchical MMs in the same domain (e.g., all in the RAN) can be interconnected via RAN nodes. In some aspects, hierarchical MMs in the same domain (e.g., all in the CN) can be interconnected via connectivity management (CM) functions. CM provides connectivity management capabilities by maintaining the connectivity between end-customer endpoints (e.g., devices, mobile devices, terminals) and the 6G system, for example, to maintain endpoint reachability and connectivity for mobility tracking, status updates, and 6G radio bearer establishment. In some aspects, 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 interconnected via the T10 interface.

[0141] In some respects, Figure 7 One or more entities shown can be integrated into one entity; for example, RAN nodes and XaaS modules on the RAN side can be integrated.

[0142] Figure 8 The diagram illustrates the connection between two boundary processing functions provided by one aspect. XaaS module 801 may include two boundary PFs, namely ingress PF 802 and egress PF 803. Similarly, XaaS module 811 may include two boundary PFs, namely ingress PF 812 and egress PF 813. In some aspects, the ingress PF and the egress PF may be the same PF.

[0143] The outgoing PF 803 of XaaS module 801 can be connected directly or via intermediate entities (e.g., GWs 804 and 814) to the incoming PF 812 of another XaaS module 811. The link between the outgoing PF 803 of XaaS module 801 and the incoming PF 812 of another XaaS module 811 can be referred to as connection 820. Connection 820 may include one or more GWs (e.g., GWs 804 and 814). In some aspects, connection 820 may not involve GWs (e.g., when connection 820 is directly between boundary PFs).

[0144] In some respects, the 820 connection can be an overlay layer and above the transport layer, for example, above QUIC connections, GTP-U tunnels, UDP connections, and IP connections. The transport layer is above the network layer (e.g., above the IP layer).

[0145] In one aspect, a new PF protocol layer can be deployed in the system. For example, the PF protocol layer can be deployed on top of the TNL, such as on top of GTP-U, UDP, QUIC, IP, or IPv6-based segment routing over IPv6 (SRv6) protocol layers. The PF protocol layer can be deployed in the PF unit of an XaaS module, or in the RAN, UE, etc. A connection 820 between two PF entities can be established, which can be on top of the QUIC, GTP-U, UDP, IP, or SRv6 protocol layers. The mapping relationship between connection 820 and GTP-U tunnels, UDP connections, IP connections, QUIC connections, and SRv6 connections can be configured. In some aspects, connection 820 can be identified by a connection ID.

[0146] In some respects, the message header can be a protocol layer header, such as a PF protocol layer header, and the protocol layer can be deployed on one of the following: above the Packet Data Convergence Protocol (PDCP) sublayer; between the Service Data Adaptation Protocol (SDAP) sublayer and the PDCP sublayer; between the PDCP sublayer and the Radio Link Control (RLC) sublayer; between the RLC sublayer and the Media Access Control (MAC) sublayer; between the MAC sublayer and the Physical Layer (PHY); above the SDAP sublayer; above the Protocol Data Unit (PDU) layer; above the GTP-U layer; above the UDP layer; above the IP layer; above the QUIC layer; above the Hypertext Transfer Protocol (HTTP) layer; or above IPv6-based segment routing. Above the IPv6 (SRv6) layer, within the PDU layer, within the SDAP sublayer, within the PDCP sublayer, within the RLC sublayer, within the MAC sublayer, within the PHY layer, within the GTP-U layer, within the UDP layer, within the IP layer, within the application layer, within the HTTP layer, within the SRv6 layer, and within the QUIC layer.

[0147] In some aspects, a connection 820 can be established between two CN-PFs. In some aspects, a connection 820 can be established between two RAN-PFs. In some aspects, a connection 820 can be established between a RAN node (e.g., a RAN base station, RAN-PF) and a CN-PF. In some aspects, one or more GWs can be an intermediary entity between two PFs as part of the connection 820.

[0148] In some respects, a connection can be established by configuring the PF protocol layer parameters and the corresponding transport network layer (TNL) parameters to one or more of the PF, GW, and RAN.

[0149] Figure 9A Power Provider (PF) provided by one aspect is shown, which participates in multiple tasks. The path between two or more entities (e.g., PF 901 and PF 902) may be an overlapping portion of different tasks or branch tasks. For example, the path between PF 901 and PF 902 is an overlapping segment of the first branch task (executed by PF 901, PF 902, and PF 903) and the second branch task (executed by PF 901, PF 902, and PF 904) of the same task 911 (executed by PF 901, PF 902, PF 903, PF 904, and PF 905). The path between PF 901 and PF 902 is also an overlapping segment between task 911, task 912 (executed by PF 901, PF 902, and PF 906), and task 913 (executed by PF 901, PF 902, and PF 907).

[0150] Under the control of the control plane, data plane connections between two PFs can be established on a per-task, per-branch-task, and per-UE basis, or one or more. In the prior art, for each task involved (e.g., a UE), the control plane can configure PFs along the path to establish four dedicated connections (e.g., four data plane tunnels) between PF 901 and PF 902 for branch tasks 1, 2, 911, 912, and 913 of task 911, respectively. If multiple UEs are involved, the number of connections on the data plane increases exponentially. Therefore, in the prior art, configuration complexity and latency may increase due to, for example, an increase in the number of required operations (e.g., the control plane sending messages to each PF along the path and configuring these PFs to establish the connections required to perform the task).

[0151] From one perspective, an SR-based solution can be provided that supports per-flow or per-tunnel traffic redirection in loop transmission. For example, the SR-based solution can be implemented or executed within the XaaS system architecture or framework described herein. The SR-based solution can be applied to paths with branching (as referenced). Figure 11A , Figure 11B (as described above) or a path without branches (as referenced) Figure 12 and Figure 13 The above).

[0152] According to one aspect, referring to the XaaS system architecture, the message header of the PF protocol layer may include an MBI (which may be a BI as described herein). In some aspects, the message header may be read by one or more PFs of the following: XaaS modules, network nodes that deploy the PF protocol layer (e.g., UE, RAN nodes).

[0153] Figure 10The diagram illustrates a task provided by one aspect, comprising multiple paths with branching and aggregation points. Execution of task 1000 may require, for example, several traffic paths indicated by solid lines 1020, dashed lines 1021, and dashed lines 1022. The traffic paths of task 1000 are shown as passing through multiple network nodes (i.e., PFs) of a module (XaaS module). For example, M[i]1001 may indicate one or more PFs (one or more network nodes) of XaaS module i.

[0154] In one aspect, a traffic path may include a branching point (M[i]1001, M[b]1004, and M[n]1007) and an aggregation point (M[d]1007). Traffic from network nodes (i.e., PFs) of modules M[i]1001, M[b]1004, and M[n]1007 is split into two separate flows. The traffic is aggregated at the aggregation point of module M[d]1007. In some aspects, the appearance of the same index (e.g., M[a]1003, M[a]1006) may indicate the same or different network nodes (i.e., PFs) of the same XaaS module.

[0155] In some respects, XaaS modules including PF followed by multiple paths can be called forked modules (e.g., M[i]1001, M[b]1004, M[n]1009).

[0156] In some respects, one or more power supply (PF) cells (e.g., exit PFs) of a forked module can be connected to the same next module. For example, one or more PF cells of M[i]1001 can be connected to one or more PF cells of M[k]1002. In some respects, one or more PF cells (e.g., exit PFs) of a forked module can be connected to different PF cells of the next module. For example, multiple PF cells of M[i]1001 can be connected to different PF cells of M[k]1002. In some respects, one or more PF cells (e.g., exit PFs) of a forked module can be connected to the same PF via different connections. For example, one or more PF cells of M[i]1001 can be connected to the same one or more PF cells of M[k]1002 via one or more different connections.

[0157] Figure 11A A message header provided by one aspect is shown. Message header 1100 may correspond to reference... Figure 7 , Figure 8 and Figure 9 The PF protocol layer of the XaaS system architecture is described. Message header 1100 is not limited to the PF protocol layer, but is also applied to other protocol layers, such as the IP layer.

[0158] Message header 1100 may correspond to task 1000 as described herein. In some aspects, message header 1100 may include one or more of MBI, FI, and DAI.

[0159] Each MBI may include information indicating one or more of the PSI, function, and metric. For example, MBI[m]1102 may include information indicating PSI 1104, function 1106, and metric 1108. In some aspects, each MBI may have multiple fields indicating one or more of the PSI, function, and metric. In some aspects, including each of the functions (e.g., function 1106) and metrics (e.g., metric 1108) in the header may be optional. In some aspects, the segment list field of SRv6 may contain one or more MBIs.

[0160] In some respects, the MBI can be encapsulated in the message header 1100 according to sequence 1130. This sequence can be based on rules, such as the participation sequence of XaaS modules in task 1000. Depending on the sequence, some modules may be skipped. In some respects, depending on the participation sequence, if an XaaS module participates multiple times, the MBI of a module may appear multiple times.

[0161] In some respects, a PSI can indicate that a message needs to be transmitted from the current module's PF to one or more next-hop module PFs via a path determined by the PSI. In other respects, a PSI can be a path ID that identifies a traffic path. The mapping between the path ID and the connection from the current PF (e.g., the egress PF of the current XaaS module) to the next-hop PF (e.g., the ingress PF of the next XaaS module) can be pre-configured to the current PF, as in path information (e.g., a path table).

[0162] In some aspects, the PSI can be a connection ID identifying the connection (e.g., the egress PF of the current XaaS module) to the next-hop PF (e.g., the ingress PF of the next module) (e.g., the coverage layer of the TNL). In some aspects, the PSI can be a PF ID (e.g., IP address, node ID) identifying the next-hop PF (e.g., the ingress PF of the next XaaS module). In some aspects, the PSI can be an XRB ID identifying the radio link between the UE and the RAN. In some aspects, the PSI of each MBI can include the current PF ID of the current PF (e.g., the ingress PF ID of the current module, or the current module ID (the relationship between the current module ID and the current PF ID is pre-configured to each PF)) for verifying whether the current PF is the correct receiver.

[0163] In some respects, the PSI included in the MBI of the fork module (e.g., MBI[i]1110, MBI[b]1112, MBI[n]1114) can indicate paths to multiple next-hop destinations. For example, the PSI can include multiple path IDs, multiple connection IDs, multiple XRB IDs, or a list of PFIDs (e.g., the IP address of the PF, the ID of the PF). The PSI of the MBI of the fork module can indicate that when a path branches or splits (e.g., has a fork), packets need to be forwarded to multiple destinations determined by the PSI.

[0164] Functions (e.g., function 1106) can be used for data processing configuration. A function can indicate the purpose of a PF (Power Processor) of the current module for processing data (i.e., message payload). Functions can be identified by function IDs. In some aspects, functions may include data processing types (e.g., data privacy protection, AI, data sanitization, data normalization, data cleaning, etc.). In some aspects, functions may also include data processing algorithms (e.g., federated learning (FL), generative adversarial networks (GAN), K-anonymity, etc.). In some aspects, functions may also include information about one or more of tasks, branch tasks, or subtasks. For example, a function ID identifying a function may include or map to a task ID identifying a task, a branch task ID identifying a branch task, or a subtask ID identifying a subtask. In some aspects, functions can be a list of functions, where the number of functions may correspond to or be the same as the number of PFs (e.g., one or more of ingress PFs and egress PFs) involved in the current module.

[0165] In some respects, metrics (e.g., metric 1108) can be used for data processing configuration. In some respects, metrics can indicate the current module's requirements for data processing (e.g., the processed data results). In some respects, metrics can include XaaS QoS requirements for the data processing method (e.g., computational precision level, privacy level, etc.). In some respects, metrics can also include one or more parameters for security protection, integrity protection, authentication, etc. In some respects, metrics can include formatted data, such as input data format, output data format, etc.

[0166] In some respects, for the first module after the forked module (e.g., M[a]1010 and M[p]1011 is...) Figure 10In the first module after the forked module M[n]1009), FI can be encapsulated together with the MBI of each first module (for example, FI = Fork[3] (e.g., Fork[3]1116 and Fork[3]1118) encapsulated together with M[a] (e.g., MBI[a]1117) and M[p] (e.g., MBI[p]1119) respectively), as shown in Figure 11.

[0167] In some respects, FI can be a value that gradually increases (e.g., increments by one) with each new path fork in the task data plane. For example, referring to task 1000, the FI value is incremented by 1 at the first path fork (i.e., the first fork module M[i] 1001), where each MBI of the first modules M[k] 1002 and M[j] 1008 after fork module M[i] is encapsulated with the updated FI value (e.g., Fork[1] 1120 and 1122). Similarly, the FI value is further incremented by 1 at the second path fork (i.e., the second fork module M[b] 1004), where each MBI of the first modules M[m] 1005 and M[a] 1006 after fork module M[b] is encapsulated with the updated FI value (e.g., Fork[2] 1124 and 1126). Similarly, the FI value is further increased by 1 at the third path fork (i.e., the third fork module M[n]1009), where each MBI of the first modules M[a]1010 and M[p]1011 after the fork module M[n] is encapsulated with the updated FI value (e.g., Fork[3]1116 and 1118).

[0168] It is understandable that the first module after the forked module can have the same FI value (e.g., M[a] and M[p] have the same FI value Fork[3]).

[0169] The FI following the fork module (e.g., the FI Fork[3] following MBI[n]1114 of (M[n]) can facilitate the decapsulation of the PF's message header. For example, a PF receiving message 1100 can easily understand that M[n]1009 is a fork module because there is a FI (Fork[3]) following MBI[n]1114. Therefore, the PF can retrieve the fork path by reading the FI encapsulated together with MBI[a]1117 and MBI[p]1119 (the MBIs of the first modules M[a]1010 and M[p]1011 following M[n]1009).

[0170] In some respects, XaaS modules, including PF, can be referred to as aggregation modules, where data can be aggregated from multiple paths for joint data processing.

[0171] In some respects, the DAI can be included in the MBI of an aggregation module. For an aggregation module, such as M[d]1007, the DAI can be included in the MBI. The DAI can indicate to the PF of the current module (e.g., aggregation module M[d]1007) that the PF needs to aggregate data from a specific path for joint data processing rather than independent data processing.

[0172] In some respects, a DAI can be a string indicating, for example, "aggregated data from one or more of a path ID, connection ID, PF ID, or XRB ID." In other respects, a DAI can indicate one or more IDs of the path from which its data will be aggregated (e.g., a specific path ID, connection ID, PF ID, or XRB ID).

[0173] As can be understood, the header information indicating the MBI, FI, and DAI is not limited to the PF protocol layer above the TNL, but can be applied to other protocol layers, such as the IP layer. In some respects, the SRv6 segment list field may contain one or more MBIs, or one or more FIs, or one or more DAIs. The SRv6 segment list field is referenced herein. Figure 3 As stated above.

[0174] Figure 11B It is provided by one aspect Figure 11A Another illustration of the message header. Message header 1150 is similar to message header 1100 of MBI and FI shown according to sequence 1130.

[0175] In some respects, a task may have a path without branches, or it may have one or more path segments without branches. Figure 12 The diagram illustrates the traffic flow of a task without branching, provided by one aspect. Task 1200 can be executed based on a straight data path (e.g., without branching or forking). For example, a straight data path could be... Figure 10 The path segment from M[k]1002 to M[a]1003 and then to M[b]1004 is not branched.

[0176] In some respects, since the straight data path does not include forks or aggregation points, the corresponding message (sent according to the straight data path) may not include FI and DAI. Messages sent according to the straight data path may include MBIs encapsulated according to the sequence of modules corresponding to the participating data paths (i.e., the data path sequence). For task 1200, the sequence of modules involved is: M[i]1201, M[k]1202, M[a]1203, M[b]1204, M[m]1205, and M[d]1207.

[0177] Figure 13 The header of a direct data path provided by one aspect is shown. Message header 1300 may correspond to task 1200, as indicated by the sequence of MBI.

[0178] Each MBI may include information indicating one or more of the PSI, function, and metric. For example, MBI[m]1302 may include information indicating PSI 1304, function 1306, and metric 1308. In some aspects, each MBI may have multiple fields indicating one or more of the PSI, function, and metric. In some aspects, including each of the function (e.g., function 1306) and metric (e.g., metric 1308) in the header may be optional.

[0179] In some respects, the PSI of each MBI may include a path ID, connection ID, or PF ID (e.g., PF node ID, PF IP address) as described herein. In some respects, the PSI may be a path ID that identifies the traffic path. In some respects, for straight data paths, since different MBIs may have the same path ID, the same path ID may be indicated in the header outside the MBI. In some respects, only the first MBI may include a path ID, and subsequent MBIs on the same path may not include a path ID.

[0180] In some aspects, a PSI can be a connection ID identifying the connection (e.g., the egress PF of the current XaaS module) to the next-hop PF (e.g., the ingress PF of the next module) (e.g., the overlay layer of the TNL). In some aspects, a PSI can be a PF ID (e.g., IP address, node ID) identifying the next-hop PF (e.g., the ingress PF of the next XaaS module). In some aspects, a PSI can be an XRB ID identifying the radio link between the UE and the RAN.

[0181] In some respects, the PSI of each MBI may include the current PFID of the current PF (e.g., the entry PFID of the current module, or the current module ID (the relationship between the current module ID and the current PF ID is pre-configured to each PF)) to verify whether the current PF is the correct receiver.

[0182] According to one aspect, an SR-based solution can be provided that supports per-flow or per-tunnel traffic redirection in loop transmission. For example, the SR-based solution can be implemented or executed within the XaaS system architecture or framework described herein. According to one aspect, the control plane can perform message programming, and the data plane can perform message header encapsulation and decapsulation as described herein. According to one aspect, reference can be made to Figures 15 to... Figure 25 The branching or splitting data paths (including one or more forked or branched data paths) are used to describe header information programming and header encapsulation and decapsulation. According to one aspect, this document refers to straight data paths (without forks) to describe header information programming and header encapsulation and decapsulation.

[0183] For branching or splitting data paths (e.g., paths with one or more forks), the control plane (e.g., MM) can generate data or information indicating one or more of the following: the MBI, Fi, and DAI of the modules participating in the branching or splitting data path. In some respects, the generation of the DAI can be optional. The control plane can also program the generated data (e.g., one or more of the MBI, Fi, and DAI) into an ordered list. The control plane can also configure the generated data to the first participating PF or UE.

[0184] Figure 14 A process for programming data routing and processing information is shown in one aspect. Process 1400 may include, at block 1401: applying or setting a first set of MBIs for a first group of XaaS modules participating in a task in a control plane (e.g., MM) until a first branching module appears. The first set of MBIs can be sequentially arranged or placed according to the task participation order of the first group of XaaS modules, wherein one MBI can be applied to each XaaS module in the first group of XaaS modules.

[0185] In some aspects, box 1401 may include: applying the MBI of the first participating XaaS module to the beginning of an ordered list. The ordered list includes multiple MBIs and one or more Fis, wherein the multiple MBIs correspond to multiple modules participating in the task, and the one or more FIs correspond to one or more branch modules among the multiple modules. The ordered list of multiple MBIs and one or more FIs is arranged according to the participation order of the multiple modules.

[0186] In some aspects, if the first participating XaaS module is not a forked module, process 1400 may further include: applying the MBI of subsequent XaaS modules in the order of task participation until the first forked module appears. Process 1400 may further include: setting a value to the FI corresponding to the first forked module (e.g., for the first forked module of a task, an initial value (e.g., 0 or 1) may be set to its FI). Optionally, the FI of the forked module is applied after the MBI of the forked module.

[0187] Process 1400 may also include at block 1402: a control plane (e.g., MM) programming the MBI of the first fork module. In some aspects, the control plane may apply the FI of the first fork module after the MBI of the first fork module. For example, refer to Figure 10 For task 1000, the first forking module is M[i]1001. Accordingly, the control plane can program the MBI of the first forking module (e.g., MBI[i]1110), and optionally apply the FI of the first forking module (e.g., Fork[1]1131) to a position after the MBI of the first forking module, such as Figure 11A and Figure 11B As shown, and in Figure 15A This is further illustrated in the text. Figure 15A The programming of the MBI and FI of the first forked module provided by one aspect is shown.

[0188] In some aspects, process 1400 may also include at block 1403: a control plane (e.g., MM) programming the MBI and FI of each first module in the first module (FM) following the first fork module. There may be at least two first modules following the first fork module. For example, refer to... Figure 10 Tasks 100, M[k]1002, and M[j]1008 are the first modules of the first forked module M[i]1001. The FI value of each FM (e.g., the value of Fork[1]1120 of M[k] and the value of Fork[1]1122 of M[j]) can be the same as the FI value of the first forked module (e.g., the value of Fork[1]1131). Process 1400 may also include: applying the FI and MBI of each FM sequentially after the MBI of the first forked module, such as Figure 15B As shown. Figure 15B One aspect provided is shown in Figure 15A Further programming of MBI and FI following the initial programming.

[0189] In some respects, the order of FI and MBI in different FMs can be consistent with the order of connection ID, PFID, or XRB ID in the MBI of the first fork module, such as... Figure 15B As shown.

[0190] In some aspects, process 1400 may also include at block 1404: a control plane (e.g., MM) inserts one or more MBIs of one or more subsequent XaaS modules of each FM into a position following the MBI of each FM, in the order of task participation, until the path following each FM is terminated or a new forked module appears. For example, see reference Figure 10Task 1000, following M[k]1002 (which is the FM after the first forked module M[i]1001) until the path terminates or a new forked module appears, includes one or more XaaS modules such as M[a]1003, because M[b]1004 is a forked module. Therefore, the MBI of M[a]1003 (e.g., MBI[a]1133) can be located after MBI[k]1132, as... Figure 11A , Figure 11B and Figure 15C As shown. Figure 15C One aspect provided is shown in Figure 15B Further programming of MBI and FI following the initial programming.

[0191] For another FM, M[j]1008 (which is another FM after the first forked module M[i]1001), the subsequent XaaS module is the forked module M[n]1009. Therefore, at this stage of the process, no further MBI is located after the MBI of M[j] (e.g., MBI[j]1134), as... Figure 11A , Figure 11B and Figure 15C As shown.

[0192] In some aspects, process 1400 may also include at block 1405: if a new forked module (e.g., a second forked module) appears, for example, at block 1404, the FI value of the new forked module (e.g., FI) is... [第二分叉模块] ) is set to the FI value of the previously forked module (e.g., FI) [第一分叉模块] =Fork[1]) plus 1, therefore, FI [第二分叉模块] =FI [第一分叉模块] +1. For example, referring to task 1000, M[b]1004 can be considered as a new forked module (e.g., a second forked module) that appears on the path originating from M[k]1002. Accordingly, the FI corresponding to M[b]1004 can be set to the FI value of the previous forked module (e.g., Fork[1]) plus 1: Fork[2] = Fork[1] + 1.

[0193] In some respects, process 1400 may also include at block 1406 the following: if a new forked module appears, for example at block 1404, then starting from the new forked module and continuing through one or more paths after the new forked module, repeating the operations performed at blocks 1402 to 1405.

[0194] For example, similar to the operation at box 1402, refer to... Figure 10In task 1000, the control plane (e.g., MM) can program the MBI (e.g., MBI[b]1112) of the second fork module. The control plane can also apply the FIFork[2]1135 of the second fork module to a position after MBI[b]1112, such as Figure 11A , Figure 11B and Figure 15D As shown. Figure 15D One aspect provided is shown in Figure 15C Further programming of MBI and FI following the initial programming.

[0195] Subsequently, similar to the operation at box 1403, the control plane can program the MBI and FI of each FM after the second fork module. According to Figure 10 For task 1000, the FM following the second fork module can be M[m]1005, and another FM following the second fork module can be M[a]1006. The FI value of each FM following the second fork module (e.g., Fork[2]1124 corresponding to M[m], and Fork[2]1126 corresponding to M[a]) can be the same as the FI value of the second fork module (e.g., Fork[2]1135). Thereafter, the FI and MBI of each FM can be applied sequentially to the position following the MBI of the second fork module (and the FI of the second fork module), as follows: Figure 11A , Figure 11B and Figure 15D As shown. Furthermore, similar to the operation at box 1404, the control plane (e.g., the MM) can insert one or more MBIs of one or more subsequent XaaS modules of each FM after the MBI of each FM, according to the task participation order, until the path after each FM is terminated or a new branching module appears. For M[m]1005 and M[a], the subsequent module is M[d]1007. Therefore, MBI[d]1136 and MBI[d]1138 can be positioned after the MBI of each FM (e.g., MBI[m]1102 and MBI[a]1137), as... Figure 11A , Figure 11B and Figure 15D As shown.

[0196] In some respects, for different fork paths of the forked module, the MBI, FI, and (optionally) DAI along each fork path can be programmed path by path. For example, the MBI, FI, and (optionally) DAI along the first fork path can be programmed until the first fork path is terminated. Then, the MBI, FI, and (optionally) DAI along the second fork path (of a different fork path) can be programmed until the second fork path is terminated. Similarly, the MBI, FI, and (optionally) DAI along any other fork path (of a different fork path) can be programmed until the other fork path is terminated. For example, the programming of each fork path can be accomplished according to the programming procedure 1400 described herein.

[0197] For task 1000, after the first branch path (e.g., the branch path after M[k]1002) is terminated, the control plane (e.g., MM) can begin programming one or more of the MBI, FI, and DAI of the second branch path (i.e., the branch path after M[j]1008) until the second branch path is terminated. Taking a path-by-path programming approach as an example, the programmed routing and processing data or information (indicating one or more of the MBI, FI, and DAI) can lead to... Figure 11B As shown.

[0198] Programming of branching paths is not limited to programming one by one. In some respects, programming different branching paths can be done in parallel. According to one aspect, a range of FI values ​​can be assigned to each parallel program (this range can be wide enough to accommodate the number of branching paths). Different parallel programs may have different FI value ranges. The first FI in each parallel program can be set to the minimum value of the assigned range. Subsequent FIs in each corresponding parallel program can be increased incrementally. In parallel programming, if the increased FI value exceeds the assigned range (the probability is small, but not impossible), the parallel program will issue an alert requesting an additional range of FI values.

[0199] In some respects, during process 1400, if the module is an aggregate module, such as M[d]1007, then the DAI should be included in the module's MBI.

[0200] In some respects, if a node is shared by different paths and the shared node is not a data aggregation node (i.e., traffic from different paths passes through the shared node independently), then the MBI (e.g., PSI) along the path following the shared node can be replicated in different paths.

[0201] In some respects, if a node is shared by different paths and the shared node is a data aggregation node (i.e., when traffic from different paths passes through the shared node, it is aggregated by the shared node, e.g., M[d]1007), then the MBI (e.g., PSI) along the path after the shared node can be preserved in the different paths.

[0202] In some respects, to generate an MBI, the control plane (e.g., the MM) can interact with the XC. For example, the control plane (e.g., the MM) can interact with the XC to obtain one or more of the PF ID, connection ID, path ID, and XRB ID, to be included in the PSI of the MBI.

[0203] In some respects, each PF of the current module can perform data processing and data forwarding based on the corresponding MBI indicated in the received message header.

[0204] In some respects, when the DAI is included in the MBI, the entry PF of the current module (e.g., M[d]1007) can buffer received data from a first path (one of multiple paths indicated by the DAI) to await data from other paths indicated by the DAI. After receiving all relevant data from the multiple paths indicated by the DAI, the entry PF of the current module can perform joint processing on the received data.

[0205] In some respects, the egress PF of the current fork module (e.g., M[i]1001) can forward data (including the retained header and payload) to each of the different destinations in the next hop (e.g., M[k]1002 and M[j]1008).

[0206] In some respects, the first participating PF or UE (e.g., the first participating PF or UE for downlink traffic or the first participating PF for uplink traffic) can encapsulate the MBI, FI (and DAI, if necessary) into the header under the control of one or both of XC and MM. The first participating PF can be the entry PF of an XaaS module.

[0207] In some cases, when a message is being forwarded by the current module to the next module (where the current module is not branched), the current module's exit PF can remove the current module's MBI. The current module's ingress PF and intermediate PF do not need to remove the MBI.

[0208] In some respects, when a message is being forwarded by the current module to the next module, where the current module is a forked module (i.e., a forked module): the output PF of the forked module can decapsulate the message header according to different methods.

[0209] The output PF of the branch module can be based on, for example... Figure 16 The first method shown performs message header decapsulation. Figure 16 A first method for message header decapsulation is shown, provided by one aspect. Method 1600 can be applied to a current module that is a forked module that forwards messages to the next module.

[0210] In some aspects, according to the first method 1600, the exit PF of the current module (which is a forked module) can remove useless MBIs and FIs and retain useful MBIs and FIs. That is, at block 1601, the exit PF of the current module can remove the FIs and MBIs of the current module. In some aspects, according to the first method 1600, at block 1602, the exit PF of the current module can also select one of the first modules (FMs) following the forked module (current module) and retain the FIs and MBIs of the selected first module. In some aspects, according to the first method, at block 1603, the exit PF of the current module can further retain one or more of the MBIs (and FIs, if present) of the participating modules and remove the FIs and MBIs of other modules that are following the selected first module (FM) along the current forked path. In some aspects, according to the first method, at block 1604, the exit PF of the current module can send a unicast message to the ingress PF of the selected FM. In some respects, according to the first method, for each next-hop PF of each forked path (i.e., there may be multiple next-hop PFs of one or more XaaS modules), the egress PF of the current forked module can also perform a similar corresponding operation as described above, and forward the unicast message corresponding to the reserved message header to each next-hop PF respectively.

[0211] For example, according to the first method, referring to block 1601, the exit PF of the current fork module can retrieve the MBI and FI of the first module by reading FI, wherein the value of FI of FM is the same as the value of the current fork module. For example, referring to... Figure 15B and Figure 10 For task 1000, the exit PF of the current forked module (e.g., M[i]1001) can retrieve the MBI and FI of the first module (e.g., MBI[k]1132, Fork[1]1120, and MBI[j]1134 and Fork[1]1122).

[0212] In some aspects, according to the first method, after retrieving the MBI and FI of the first module, in reference boxes 1602 and 1603, the egress PF can select one of the first modules and retain the FI and MBI of the selected first module and its subsequent modules. In some aspects, there may be multiple next-hop destinations (i.e., multiple next-hop PFs for one or more XaaS modules). In some aspects, according to the first method, the egress PF can decide which destination the retained MBI and FI should be sent to. In some aspects, according to the first method, for example, the destination can be determined based on the PSI of the current forked module and the sequence of the FI and MBI of the first module in the header. For example, the sequence of multiple path IDs, connection IDs, or PFIDs in the PSI of the current forked module may be the same as the sequence of the FI and MBI of the first module in the header.

[0213] In some respects, according to the first method, reference box 1603, the MBI (and FI, if present) of a participating module following the selected first module along the current fork path can be retrieved, for example, based on the value FI. For example, all those MBIs (and FIs, if present) following the MBI and FI of the selected first module can include the MBIs (and FIs, if present) of participating modules following the selected first module along the current fork path, until a FI exists whose value is equal to the FI value of the current fork module.

[0214] For example, refer to Figure 15D and Figure 10 For task 1000, the output PF of the current forked module M[i]1001 can choose M[k]1002 as the first selected module, and retain the MBI and FI of the first selected module and its subsequent modules until FI exists, see Fork[1]1122, whose value is equal to the FI value of the current forked module, see Fork[1]1131, such as Figure 15D As shown.

[0215] In some respects, according to the first method, the current module's egress PF should or may send multiple unicast messages (with different message headers but duplicate payloads) to multiple ingress PFs of one or more next-hop modules respectively.

[0216] In some aspects, when a message is being forwarded by the current module to the next module, where the current module is a forked module (i.e., a forked module): the forked module's exit PF can decapsulate the message header according to the second method, such as... Figure 17 As shown.

[0217] Figure 17A second method for message header decapsulation is shown in one aspect. In some aspects, according to the second method 1700, if the ID (e.g., address, node ID) of the ingress PF of the next-hop module is included in the MBI of the next-hop module, then at block 1701, the egress PF of the current module (which is a forked module) can remove one or both of the MBI and FI of the current module. In some aspects, according to the second method 1700, at block 1702, the egress PF of the current module can further retain the MBI and FI of other modules (including different first modules following the forked module). In some aspects, according to the second method 1700, at block 1703, the egress PF of the current module can also send multicast messages to all first modules following the forked module. In some aspects, according to the second method 1700, at block 1704, the ingress PF of each first module can retrieve and retain its associated MBI and FI. In some aspects, according to the second method 1700, at block 1705, the entry PF of each first module may further retain the module's MBI (and FI, if present), and may remove the MBI and FI of other modules following the retrieved first module along the corresponding current fork path. In some aspects, according to the second method 1700, at block 1706, the entry PF of each first module may send the retained header along the current fork path (corresponding to the current fork path) to the intermediate PF of the XaaS module (the corresponding first module of the entry PF), and then to the exit PF of the XaaS module.

[0218] In some aspects, according to the second method, if the PF ID (e.g., address, node ID) of the ingress PF of the next-hop module is included in the PSI of the MBI of the forked module, or if the PF ID can be inferred from the PSI of the forked module (e.g., connection ID), at block 1707, the egress PF of the current module (for the forked module) may not remove one or both of the MBI and FI of the current module. In some aspects, according to the second method 1700, at block 1702, the egress PF of the current module may further retain the MBI and FI of other modules (including different first modules following the forked module). In some aspects, according to the second method 1700, retaining the MBI and FI of other modules may be done simultaneously with removing one or both of the MBI and FI of the current module. In some aspects, according to the second method 1700, at block 1703, the egress PF of the current module may also send multicast messages to all first modules following the forked module. In some aspects, according to the second method 1700, at block 1704, the entry PF of each first module can retrieve and retain its associated MBI and FI. In some aspects, according to the second method 1700, at block 1704, the entry PF of each first module can further retain the module's MBI (and FI, if present) and remove the MBI and FI of other modules following the retrieved first module along the corresponding current fork path. In some aspects, according to the second method 1700, at block 1707, the entry PF of each first module can also send the retained header along the current fork path (corresponding to the current fork path) to the intermediate PF of the XaaS module (the corresponding first module of the entry PF), and then to the exit PF of the XaaS module.

[0219] In some respects, according to the second method 1700, if the ID (e.g., address, node ID) of the ingress PF of the next-hop module is included in the MBI of the next-hop module, as referenced in box 1704, the ingress PF of each first module can retrieve the MBI and FI of that first module, for example, by reading the FI and the ingress PF ID (e.g., address, node ID) included in the MBI.

[0220] In some aspects, according to the second method, if the PF ID (e.g., address, node ID) of the ingress PF of the next-hop module is included in the PSI of the MBI of the forked module, or if the PF ID can be inferred from the PSI (e.g., connection ID), referring to box 1704, the ingress PF of each first module can retrieve the MBI and FI of that first module, for example, based on the PSI of the current forked module and the sequence of the FI and MBI of the first module in the header. For example, the sequence of multiple PF IDs included in the PSI of the forked module (or multiple PF IDs inferred from the PSI of the forked module) can be the same as the sequence of the FI and MBI of the first module in the header.

[0221] In some respects, according to the second method, after the MBI and FI of each first module are retrieved by the ingress PF, reference box 1705, the ingress PF should retain the MBI and FI, as well as one or more MBIs (and one or more FIs (if present)) of each first module and subsequent modules along the current fork path, and remove one or more FIs and one or more MBIs of other modules.

[0222] In some respects, according to the second method, one or more MBIs and (optionally) FIs of subsequent modules along the current fork path can be retrieved, for example, based on the FI value. For example, all those MBIs (and FIs, if present) following the retrieved FI and MBI of the first module should be one or more MBIs (and one or more FIs, if present) of subsequent modules along the current fork path of the first module, until there is an FI whose value is equal to the retrieved FI value of the first module.

[0223] In some respects, according to the second method 1700, reference box 1703, the current module's exit PF can send multicast messages to multiple ingress PFs of one or more next-hop modules.

[0224] The operations described with reference to the first method 1600 and the second method 1700 can be applied not only to the PF protocol layer (e.g., above the TNL) but also to the traditional IP protocol layer (e.g., when one or more of MBI, FI and DAI are encapsulated in the IP header).

[0225] Figure 18The diagram illustrates how a source node sends data to a receiver according to one aspect. Source node 1801 can send data (e.g., datagrams) to one or both of receivers 1821 and 1822 via one or both of a unicast method (according to first method 1600) and a multicast method (e.g., according to second method 1700). Source node 1801 may be an egress PF of an XaaS module, receiver nodes 1821 and 1822 may be ingress PFs of two other XaaS modules, and GWs 1811, 1812, 1813, and 1814 may be routers.

[0226] According to the first method 1600, source node 1801 (and GWs 1811, 1812) can send two unicast messages (with different headers but duplicate payloads) to two receivers 1821 and 1822 respectively. In some aspects, according to the first method, source node 1801 can perform header decapsulation (e.g., perform one or more operations performed by the egress PF of the current fork module, as described herein with reference to the first method 1600) before sending the unicast message.

[0227] According to the second method 1700, source node 1801 and GW 1811 may need to send multicast messages to two receivers 1821 and 1822 (based on one or more operations performed by the egress PF of the current fork module). That is, source node 1801 and GW 1811 may send the message once. In some aspects, GW 1812 may need to replicate the message to edge GW 1813 and GW 1814 respectively. Edge GW 1813 and GW 1814 may forward the message to the two receivers 1821 and 1822 respectively. After the two receivers receive the message, the receivers may perform message header decapsulation (e.g., perform one or more operations performed by the ingress PF of the first module, as described herein with reference to the second method 1700), as described herein with reference to the second method 1700.

[0228] In some respects, the first method 1600 and the second method 1700 can be performed independently. In some respects, when the MBI, FI (and optional DAI) are encapsulated in the IP header by the source node 1801, the first method 1600 and the second method 1700 can be performed jointly (or independently). For example, source node 1801 and GW 1811 can send multicast messages to GW 1812 according to the second method 1700. In some respects, GW 1812 can forward unicast messages to receiver 1821 via GW 1813 and forward second unicast messages to receiver 1822 via GW 1814 according to the first method 1600. Source 1801 and GW 1811 can perform header decapsulation and message forwarding as described herein with reference to the second method 1700. GW 1812, GW 1813, and GW 1814 can perform header decapsulation and message forwarding as described herein with reference to the second method 1600. Jointly forwarding messages using the first method 1600 and the second method 1700 can reduce the traffic load between source nodes 1801, GW 1811, and GW 1812. In some respects, GW 1813 and 1814 or the two receivers 1821 and 1822 can perform message decapsulation.

[0229] It is understood that by using the second method 1700, the packet payload transmission from source node 1801 to GW 1811 and further to GW 1812 can be reduced; however, additional packet header information may be transmitted. In some respects, if the packet header size is smaller, the traffic load between participating network entities can be reduced under the second method 1700; however, compared to the first method 1600, the next-hop ingress PF can perform additional actions (e.g., one or more of the operations described in reference boxes 1704, 1705, and 1706).

[0230] Figure 19 One aspect provided includes corresponding Figure 10 The path segment of the message header contains the MBI and FI. In one respect, message header 1950 can be similar to message header 1150. Message header 1950 shows... Figure 10 The corresponding path segment's MBI and FI. Figure 10 The MBI and FI of path segment 1020 are shown via solid line 1920. Similarly, Figure 10 The MBI and FI of path segment 1021 are shown via dashed line 1921. Figure 10 The MBI and FI of path segment 1022 are shown via dashed line 1922.

[0231] According to one aspect, the transmission of messages in Task 1000 is described. In one aspect, the transmission of messages including a message header is described with reference to a first method 1600, said message header including data indicating MBI and FI. In one aspect, a node participating in Task 1000 (e.g., a PF) can transmit messages according to the first method 1600, as described with reference to... Figure 20 , Figure 21 and Figure 22 As stated above.

[0232] Figure 20 It shows that, according to one aspect, Figure 10 M[k] and M[j] through Figure 16 The method receives the message header. In one aspect, according to the first method 1600, the egress PF of M[i]1000 can send a unicast message including message header 2010 to M[k]1002. The egress PF of M[i]1000 can also send a unicast message including message header 2020 to M[j]1008 according to the first method 1600. It is understood that message headers 1950, 1150 and 1100 may include MBI and FI information similar to the combination of message headers 2010 and 2020.

[0233] Figure 21 It shows that, according to one aspect, Figure 10 M[m] and M[a] through Figure 16 The method of receiving the message header. In one aspect, after receiving message header 2010, M[k]1002 and M[a]1003 can forward the message header according to the described method of transmitting messages along a straight path (a path without branching). For example, each of M[k]1002 and M[a]1003 can remove its MBI (and FI, if present) from message header 2010, retain the MBI (and FI, if present) of the subsequent module, and send a unicast message to its next hop until it reaches M[b]1004. Similarly, M[j] can remove its MBI and FI from message header 2020, retain the MBI (and FI, if present) of the subsequent module, and send a unicast message to M[n]1009.

[0234] In one aspect, according to the first method 1600, M[b]1004 can send a unicast message including a message header 2110 to M[m]1005. According to the first method 1600, M[b]1004 can also send a unicast message including a message header 2120 to M[a]1006.

[0235] Figure 22 It shows that, according to one aspect, Figure 10 M[a] and M[p] through Figure 16The method receives the message header. In one aspect, after receiving the message header from M[j]1008, according to the first method 1600, M[n]1009 may send a unicast message including message header 2210 to M[a]1010. According to the first method 1600, M[n]1009 may also send a unicast message including message header 2220 to M[p]1011.

[0236] According to one aspect, the transmission of messages according to the second method 1700 is described. In one aspect, a node participating in task 1000 (e.g., a PF) can transmit messages according to the second method 1700, as described in reference... Figure 23 , Figure 24 and Figure 25 As stated above.

[0237] As described with reference to the second method 1700, in some aspects, such as reference box 1707, the PF ID (e.g., address, node ID) of the entry PF of the next-hop module may be included in the PSI of the MBI of the fork module, or the PF ID may be inferred from the PSI (e.g., connection ID). Reference Figure 23 , Figure 24 and Figure 25 The aforementioned aspect can be based on the scenario of box 1707, wherein the egress PF of the current module (which is a fork module) can retain the PSI (or MBI) and FI of the current module in the header of the message sent to the first module after the fork module.

[0238] If the ID (e.g., address, node ID) of the ingress PF of the next-hop module is included in the MBI of the next-hop module, for example, as described in reference block 1701, the egress PF of the current module (fork module) may remove one or both of the FI and MBI of the current module from the header sent to the first module after the fork module.

[0239] Figure 23 It shows that, according to one aspect, Figure 10 M[k] and M[j] through Figure 17 The method receives the message header. In one aspect, according to the second method 1700, the egress PF of M[i]1000 can send multicast messages including message header 2310 to M[k]1002 and M[j]1008. Message header 2310 may include MBI and FI information similar to message headers 1950, 1150 and 1100.

[0240] Figure 24 It shows that, according to one aspect, Figure 10 M[m] and M[a] through Figure 17 The method receives the message header.

[0241] In one aspect, after receiving message header 2310, M[k]1002 and M[a]1003 can forward the message header according to the described method of transmitting messages along a straight path (a path without branching). For example, each of M[k]1002 and M[a]1003 can remove its MBI (and FI, if present) from message header 2310, retain the MBI (and FI, if present) of the subsequent module, and send a unicast message to its next hop until it reaches M[b]1004. Similarly, M[j] can remove its MBI and FI from message header 2310, retain the MBI (and FI, if present) of the subsequent module, and send a unicast message to M[n]1009.

[0242] In one aspect, according to the second method 1700, M[b]1004 can send a multicast message including message header 2410 to M[m]1005 and M[a]1006.

[0243] Figure 25 It shows that, according to one aspect, Figure 10 M[a] and M[p] through Figure 17 The method receives the message header. In one aspect, after receiving the message header from M[j]1008, according to the second method 1700, M[n]1009 may send a multicast message including message header 2510 to M[a]1010 and M[p]1011.

[0244] For a linear data path (a path without branching) of a task, the control plane (e.g., MM) can generate data indicating one or more MBIs of one or more modules participating in the linear data path. In some aspects, the control plane (e.g., MM) can, for example, program the generated MBIs into an ordered list based on the sequence of XaaS modules participating in the execution of subtasks within the task. The control plane can also configure the ordered list of MBIs to the first participating PF or UE.

[0245] In one aspect, the first participating PF or UE on a straight data path (e.g., the first participating PF for downlink traffic, the UE, or the first participating PF for uplink traffic) can be encapsulated in a header. Header encapsulation may include encapsulating the MBI into the header under the control of the XC and / or MM. In some aspects, the first participating PF may be the entry PF of an XaaS module.

[0246] In some respects, when a message is being forwarded from the current module to the next module, on a straight data path, the current module's exit PF can remove the current module's MBI and retain the MBI of the subsequent module.

[0247] In some respects, for straight data paths, the ingress PF of an XaaS module does not remove the MBI. In other respects, the egress PF of the current module may not remove the MBI of the current module, and the ingress PF of the next-hop module may remove the MBI of the previous module (i.e., the MBI of the current module).

[0248] In a straight data path, each PF of the current module can perform one or both of data forwarding and data processing based on the current module's MBI. In some respects, each PF can include processed data in the payload of the message to be forwarded.

[0249] According to one aspect, process 2600 is provided for the control plane to configure one or more of MBI, FI, and DAI at one or more PFs. In some aspects, process 2600 may also support data plane execution tasks. According to one aspect, one or more PFs of XaaS modules participating in process 2600 may include one or more of ingress PFs and egress PFs. For example, in some aspects, the ingress PF and egress PF of an XaaS module may be integrated into the PFs participating in process 2600.

[0250] Figure 26A and Figure 26B One aspect of the procedure provided for SR-based configuration and task execution is illustrated. According to procedure 2600, MM 2670 and XC 2661 and 2662 can coordinate to select PF 2651 and 2652 to participate in the task. In some aspects, the selection can be performed when the task is instantiated or the task data plane is established.

[0251] In one aspect, the operations described with reference to references 2602 to 2612 can be performed to configure a connection between a first PF 2651 and a second PF 2652 of two different XaaS modules. In other aspects, the configuration can be performed when a task is instantiated or a task data plane is established.

[0252] In some aspects, process 2600 may further include: MM 2670 sending a task data plane establishment request message 2602 to first XC 2661. In some aspects, message 2602 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, and PF node ID1. Message 2602 may indicate that first XC 2661 should control the PF identified by PF node ID1 (e.g., PF 2651) to establish a connection identified by the connection ID. Message 2602 may also indicate that first XC 2661 should control the network to establish resources for executing the task identified by the task ID, the subtask identified by the subtask ID, or the branch task identified by the branch task ID.

[0253] In some aspects, process 2600 may further include, after receiving message 2602, the first XC 2661 sending a task data plane establishment request message 2603 to the first PF 2651. Message 2603 may include one or more of a task ID, a subtask ID, a branch task ID, a connection ID, and PF node ID1. Message 2603 may indicate that the first PF 2651, identified by PF node ID1, should establish a connection identified by the connection ID. Message 2603 may also indicate that the first PF 2651 should establish resources for executing the task identified by the task ID, the subtask identified by the subtask ID, or the branch task identified by the branch task ID.

[0254] In some aspects, process 2600 may further include: the first PF 2651 establishing a PF entity (e.g., a PF entity at the PF protocol layer) and allocating TNL information (e.g., a GTP-U tunnel endpoint identifier (TEID), IP address, or QUIC ID) to establish a TNL tunnel (e.g., a GTP-U tunnel, a QUIC connection). In some aspects, the TNL tunnel can be identified by the TNL information. In some aspects, the connection between the PF entity and another PF entity (which may be on the second PF 2652 side) may be over the TNL tunnel.

[0255] In some aspects, process 2600 may further include: the first PF 2651 sending a task data plane establishment response message 2604 to the first XC 2661. Message 2604 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, TNL information on the first PF side, and a mapping between the connection and the TNL tunnel. In some aspects, the mapping between the connection and the TNL tunnel may indicate to the peer node (i.e., the second PF 2652) which TNL tunnel (TNL tunnel) should be used to transmit data belonging to the connection to the first PF 2651. In some aspects, a connection may be mapped to one or more TNL tunnels. In some aspects, one or more connections may be mapped to a single TNL tunnel. The mapping between the connection and the TNL tunnel may be indicated by a mapping between the connection ID and the TNL information. In some aspects, message 2604 may also indicate that the first PF 2651 has successfully established resources for executing the task identified by the task ID, the subtask identified by the subtask ID, or the branch task identified by the branch task ID.

[0256] In some aspects, process 2600 may further include: the first XC 2661 sending a task data plane establishment response message 2605 to the MM 2670. Message 2605 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, TNL information on the first PF side, and mapping between the connection and the TNL tunnel.

[0257] In some aspects, process 2600 may further include: MM 2670 sending a task data plane establishment request message 2606 to the second XC 2662. Message 2606 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, PF node ID2, TNL information on the first PF side, and mapping between the connection and the TNL tunnel. Message 2606 may indicate that the second XC 2662 should control the PF identified by PF node ID2 to establish a connection identified by the connection ID. Message 2606 may also indicate that the second XC 2662 should control the network to establish resources for executing the task identified by the task ID, the subtask identified by the subtask ID, or the branch task identified by the branch task ID.

[0258] In some aspects, process 2600 may further include, upon receiving message 2606, the second XC 2662 sending a task data plane establishment request message 2607 to the second PF 2652. Message 2607 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, PF node ID2, TNL information on the first PF side, and a mapping between the connection and the TNL tunnel. Message 2607 may indicate that the second PF 2652, identified by PF node ID2, should establish a connection identified by the connection ID. The TNL information may inform the second PF 2652 of the TNL information on the first PF side, based on which the second PF 2652 can transmit data on subsequent tunnels. The mapping between the connection and the TNL tunnel may inform the second PF 2652 which TNL tunnel (TNL tunnel) the data belonging to the connection should be transmitted to PF1 through. Message 2607 may also instruct that the second PF 2652 should establish resources for executing tasks identified by task IDs, subtasks identified by subtask IDs, or branch tasks identified by branch task IDs.

[0259] In some aspects, process 2600 may further include: the second PF 2652 establishing a PF entity (e.g., a PF entity at the PF protocol layer) and allocating TNL information (e.g., a GTP-U tunnel endpoint identifier (TEID), IP address, QUIC ID) to establish a TNL tunnel (e.g., a GTP-U tunnel, a QUIC connection). The TNL tunnel can be identified by the TNL information. The connection between the PF entity and the PF entity on the first PF side can be over the TNL tunnel.

[0260] In some aspects, process 2600 may further include: the second PF 2652 sending a task data plane establishment response message 2608 to the second XC 2662. Message 2608 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, TNL information on the second PF side, and a mapping between the connection and the TNL tunnel. The mapping between the connection and the TNL tunnel may be indicated by the mapping between the connection ID and the TNL information. In some aspects, message 2608 may also indicate that the second PF 2652 has successfully established resources for executing the task identified by the task ID, the subtask identified by the subtask ID, or the branch task identified by the branch task ID.

[0261] In some aspects, process 2600 may further include: the second XC 2662 sending a task data plane establishment response message 2609 to the MM 2670. Message 2609 may include one or more of the following: task ID, subtask ID, branch task ID, TNL information on the second PF side, and a mapping between the connection and the TNL layer tunnel. The mapping between the connection and the TNL layer tunnel may indicate to the peer node (i.e., the first FP) which TNL tunnel (TNL tunnel) the data belonging to the connection should be transmitted to the second PF 2652 through. In some aspects, a connection may be mapped to one or more TNL layer tunnels. In some aspects, one or more connections may be mapped to a single TNL layer tunnel.

[0262] In some aspects, process 2600 may further include: MM 2670 sending a task data plane update request message 2610 to the first XC 2661. Message 2610 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, TNL information on the second PF side, and mapping between the connection and the TNL tunnel.

[0263] In some aspects, process 2600 may further include: the first XC 2661 sending a task data plane establishment response message 2611 to the first PF 2651. Message 2611 may include one or more of the following: task ID, subtask ID, branch task ID, connection ID, TNL information on the second PF side, and mapping between the connection and the TNL tunnel.

[0264] In some aspects, the operations described with reference to 2602 to 2611 may be based on the assumption that there is no GW to connect the two PFs of the two XaaS modules (e.g., the first PF 2651 and the second PF 2652 are directly connected). In some aspects, there may be one or more GWs to connect the two PFs. If there are one or more GWs 2654, process 2600 may include: MM 2670 controlling one or more GWs 2654 to connect to (2612) the first PF 2651 and the second PF 2652. Connecting one or more GWs to connect to the two PFs may include: configuring IP layer information to one or more GWs. For example, MM 2670 may control one or more GWs 2654 to establish TNL tunnels with the first PF 2651 and the second PF 2652 respectively. In some aspects, MM 2670 may also control one or more GWs 2654 to bind the TNL tunnel to the connection between the two first PFs 2651 and the second PF 2652. In some aspects, MM 2670 can notify one or more GWs of TNL information on the first PF side and the second PF side. MM 2670 can also notify one or more GW-side TNL information on the first PF 2651 and the second PF 2652.

[0265] exist Figure 26A In the example shown, MM 2670 interacts with two XCs (first XC 2661 and second XC 2662) to establish connections between two PFs controlled by the two XCs in two different XaaS modules, respectively. In some aspects, MM 2670 can interact with more than two XCs in more than two different XaaS modules to establish connections between more than two PFs along the task data plane. In some aspects, process 2600 can be extended to scenarios that may involve more than two PFs; that is, MM 2670 may need to interact with each of a plurality of XCs, and each XC can interact with the PFs it controls to enable the PFs to establish connections between them.

[0266] In some respects, one or both of the two PFs (first PF 2651 and second PF 2652) can reside in the same network domain or different network domains. For example, both PFs can reside in the CN, i.e., these two PFs are CN-PFs. In some respects, both PFs can reside in the RAN, i.e., these two PFs are RAN-PFs. In some respects, one PF can reside in the RAN, while the other PF can reside in the CN. In some respects, one or more GWs between the two PFs can be optional. In some respects, the XC controlling the PF can reside in the same domain as the PF. In some respects, the deployment of the MM can be centralized or distributed; for example, the MM can include two different domain MMs, which can reside in the same domain as the PF and XC, respectively.

[0267] In some respects, one or more of the operations described with references 2613 to 2614 can be performed to configure the radio link between the UE 2650 and the RAN for the mission data plane. This configuration can be performed when the mission data plane is established.

[0268] In some respects, when a UE requests network access to participate in a mission, the XC can configure the radio link (e.g., XaaS radio bearer, XRB) between the UE and the RAN-PF (i.e., the PF on the RAN side). The XRB ID identifies the radio link between the UE and the RAN-PF.

[0269] In some aspects, process 2600 may further include: an XC (e.g., a second XC 2662) sending a task data plane establishment request message 2613 to the RAN-PF (e.g., a second PF 2652). Message 2613 may include one or more of the XRB ID and configuration parameters on the PF protocol layer of the RAN-PF. In some aspects, if the SDAP, PDCP, RLC, MAC sublayers and PHY layer of the XaaS radio bearer are also deployed on the RAN-PF, message 2613 may further include configuration parameters on the SDAP, PDCP, RLC, MAC sublayers and PHY layer. In some aspects, if one or more of the sublayers (SDAP, PDCP, RLC, MAC) and the layer (PHY) are deployed on other RAN nodes (e.g., RAN base stations) instead of the RAN-PF, the XC may interact with the RAN node and configure the corresponding parameters on one or more of these sublayers and layers to the RAN node.

[0270] In some aspects, process 2600 may further include: an XC (e.g., a second XC 2662) sending a task data plane establishment request message 2614 to the UE 2650. Message 2614 may include one or more of the XRB ID, configuration parameters on the UE's PF protocol layer, SDAP, PDCP, RLC, MAC sublayer, and PHY layer. In some aspects, the XC (e.g., a second XC 2662) and RAN-PF (e.g., a second PF 2652) may exchange messages between themselves after message 2613. The exchange messages are used to align PF 2652 and XC 2662 to successfully configure the XRB identified by the XRB ID and associated configuration parameters. Similarly, in some aspects, XC 2662 and UE 2650 may exchange messages between themselves after message 2614. The exchange messages are used to align UE 2650 and XC 2662 to successfully configure the XRB identified by the XRB ID and associated configuration parameters.

[0271] In some aspects, it can be implemented in Figure 26B The references to 2615 to 2619 describe one or more operations to configure path information (e.g., a path table) to the PF (first PF 2651 and second PF 2652) and UE 2650. Configuration can be performed when the task is instantiated or when the task data plane is established, for example, alone or with connection configuration.

[0272] In some aspects, process 2600 may further include: MM 2670 sending path information to two XCs (first XC 2661 and second XC 2662, respectively), and each XC may send path information to one or more of its controlled PF and UE. For example, process 2600 may include: MM 2670 sending a path information message (e.g., path table) 2615 to first XC 2661. Process 2600 may further include: first XC 2661 sending a path information message (e.g., path table) 2616 to its controlled PF (e.g., first PF 2651). Process 2600 may further include: MM 2670 sending a path information message (e.g., path table) 2617 to second XC 2662. The process 2600 may further include: the second XC 2662 sending a path information message (e.g., a path table) 2618 to its controlled PF (e.g., the second PF 2652) and sending a path information message (e.g., a path table) 2619 to the UE 2650.

[0273] In some aspects, path information 2615 to 2619 may include one or more of a path ID, next-hop information, and a metric. The path ID may identify a path that includes one or more of a connection and an XRB. The next-hop information may indicate a connection or XRB used to forward data to the next-hop node. For example, data may be forwarded to the next-hop node via an XRB in a radio link (e.g., from UE to RAN-PF, or from RAN-PF to UE). In some aspects, data may be forwarded to the next-hop node via a connection in a wired link (e.g., from RAN-PF to CN-PF, from CN-PF to RAN-PF, or from one CN-PF to another CN-PF). If data is transmitted to the next hop via a path, the metric may indicate one or both of a data forwarding guarantee and a data processing guarantee.

[0274] From one perspective, the path information configured at each PF can be... Figure 27 The path table shown. Figure 27 The diagram illustrates path information (path table) provided by one aspect. In one aspect, path table 2700 may include one or more of the following: a path ID identifying the path, next-hop information, and a metric about the path. Accordingly, for each path identified by the path ID, the path table may include next-hop information and metric information.

[0275] In some aspects, the mapping between path IDs and next-hop information, as well as (optionally) metrics, may also be indicated by path table 2700. A path ID may identify a path that includes one or more connections. Next-hop information may indicate the connection used to forward data to the next-hop node. For example, data may be forwarded to the next-hop node via an XRB in a radio link (e.g., from UE to RAN-PF, or from RAN-PF to UE). In some aspects, data may be forwarded to the next-hop node via a connection in a wired link (e.g., from RAN-PF to CN-PF, from CN-PF to RAN-PF, or from one CN-PF to another CN-PF). In some aspects, if data is transmitted to the next hop via the corresponding path, the metric may indicate one or both of a data forwarding guarantee and a data processing guarantee.

[0276] In some respects, next-hop information can be indicated by a connection ID (identifying the connection between the current PF and the next-hop PF (e.g., the coverage layer of the TNL)). In some respects, next-hop information can be a PF ID (identifying the next-hop PF, e.g., the PF address). In some respects, next-hop information can be an XRB ID (identifying the radio link between the UE and the RAN).

[0277] In some aspects, metrics can indicate costs (e.g., bandwidth, computing resources). In other aspects, costs can indicate the communication and computation costs of data being transmitted via the path (identified by the corresponding path ID in the path table) to the next hop, such as communication bandwidth and computing resource costs. In some aspects, metrics can indicate QoS guarantees. QoS guarantees can indicate the QoS (e.g., one or both of data forwarding QoS and data processing QoS) that can be guaranteed if data is transmitted via the path (identified by the corresponding path ID in the path table) to the next hop, such as latency, rate, and accuracy.

[0278] In some respects, metrics can also indicate priority. Priority can indicate the order in which a path (identified by the corresponding path ID in the path table) forwards data compared to other paths.

[0279] In some respects, the path selection decision can be left to the current PF itself, and the path table can store multiple next-hop entries for the next-hop PF (e.g., multiple candidate path IDs). In this case, the current PF can select the next hop based on cost metrics.

[0280] In some respects, path information may also include one or more factors, such as data source information, and the data processing capabilities that can be provided along the path if one is selected.

[0281] In some respects, a common connection can be established between two PFs (first PF 2651 and second PF 2652) for different paths. In some respects, different paths connecting a PF and some other PFs can be configured as multiple candidate paths for subtasks or branch tasks. In some respects, a private connection can be established between two PFs for different paths.

[0282] In some aspects, if traffic path information is configured, traffic can be forwarded and carried based on the following schemes: The control plane (e.g., one or both of MM and XC) can configure traffic path information to one or both of PF and UE, such as configuring a path table. The mapping between paths (e.g., identified by path IDs) and connections (e.g., overlay connections over QUIC, GTP-U tunnels, XRBs) can be indicated by the configured traffic path information. In some aspects, when performing a task, one or both of PF and UE can encapsulate path selection information into a message header (e.g., a message header at the PF protocol layer) under the control of the control plane (e.g., one or both of MM and XC). In some aspects, data can be forwarded based on pre-configured path information and path selection information.

[0283] In some respects, one or more operations described with reference to 2620 can perform data processing configuration on all participating PFs or UEs of a task (not just the first PF or UE to participate in the task). Data processing configuration can be performed when the task is instantiated or when the task data plane is established.

[0284] In some aspects, process 2600 may also include: 2620, the control plane (i.e., the MM and XC) configuring data processing mode parameters to one or more PFs and UEs. The MM may invoke a task graph or task instance to view the subtasks involved in the task. The MM may also send a subtask ID or branch task ID to each corresponding XC. The XC can then configure the data processing mode parameters to one or more PFs and UEs.

[0285] For example, XC can configure PF entities (e.g., entities of the PF protocol layer above TNL (e.g., QUIC, GTP-U)), and the PF protocol layer can be deployed on PF units (e.g., RAN-PF unit, CN-PF unit, UE, and RAN) regarding data processing methods. Data processing configurations can include functions, according to which the PF entity can process data as described herein. The configured functions can be indicated by function IDs. In some aspects, the configured function can be a data processing type (e.g., data privacy protection, AI, data sanitization, data normalization, data cleaning, etc.), which can be indicated by one or more of a task ID and a subtask ID. In some aspects, the configured function can be a data processing algorithm (e.g., FL, GAN, K-anonymization, etc.). In some aspects, the configured function can be information about one or more of the following: a task, branch task, or subtask to be performed by the PF (e.g., task ID, branch task ID, or subtask ID). In some aspects, the function ID identifying the function can include or map to a task ID identifying the task. A branch task ID can identify a branch task, and a subtask ID can identify a subtask.

[0286] In some aspects, the data processing configuration may also include metrics as described herein. In some aspects, metrics may include XaaS QoS requirements for the data processing method (e.g., computational accuracy level, privacy level). In some aspects, metrics may include one or more parameters for security protection, integrity protection, authentication, etc. In some aspects, metrics may include one or more of the input data format and output data format.

[0287] In some respects, the operations described with reference to 2621 can configure one or more of the MBI, FI, and DAI at one or more of the first PF 2651, the second PF 2652, and the UE 2650. The configuration can be performed when the mission data plane is established or during mission execution.

[0288] In some aspects, process 2600 may also include: 2621, the control plane (i.e., MM and XC) generating and programming one or more of MBI, FI, and DAI. The generation and programming operations can be performed according to the branch paths and straight paths referenced herein (see reference...). Figure 14 , Figures 15A to 15D To perform the action in accordance with one or more aspects described herein.

[0289] In one aspect, the control plane (i.e., MM and XC) can configure (2621) one or more of MBI, FI and DAI to one or both of the following: the PF and UE that participate in the task first (e.g., the PF, UE that participates first in the downlink or the PF that participates first in the uplink).

[0290] In one aspect, MM 2670 can collaborate with XC 2661 and 2662 to generate one or more of the following: MBI, FI (if one or more path branches exist in the task), and DAI (if one or more aggregation points exist in the task). In some aspects, each MBI may include one or more of PSI, features, and metrics. For example, if the operations described in reference 2620 have been performed (which may be optional), each MBI may include PSI. In some aspects, if the operations described in reference 2620 have not been performed, each MBI may include one or more of PSI, features, and metrics.

[0291] As described in this article, MM can be based on the referenced branch paths (paths with one or more branches and convergences) and straight paths (paths without branches) (reference). Figure 14 , Figures 15A to 15D ( ) describes one or more aspects for generating and programming one or more of MBI, FI, and DAI.

[0292] Then, the MM 2670 can send one or more of the following generated items to each corresponding XC: MBI, FI, DAI, subtask ID, and branch task ID. The corresponding XC can then configure one or more of the MBI, FI, DAI, subtask ID, and branch task ID to one or both of the first participating PF and UE. The information (one or more of MBI, FI, DAI, subtask ID, and branch task ID) can instruct the first participating PF or UE to encapsulate one or more of the MBI, FI, and DAI into the header (i.e., the header of the PF protocol layer) of the data of the task identified by the task ID or the branch task identified by the branch task ID.

[0293] In some respects, process 2600 may include one or more operations relating to task execution in the uplink as described with reference to 2622 to 2624.

[0294] According to one aspect, in 2622, for uplink data, when performing a task, branch task, or subtask, the PF entity deployed at the UE (e.g., the PF entity at the PF protocol layer in the UE) can process the data based on a data processing configuration (e.g., the configuration information described in 2620, or the configuration information in the MBI described in 2621). In some aspects, in 2622, the PF entity deployed at the UE can further perform header decapsulation as described herein, referring to paths with or without forks, for example... Figures 16 to 25 For example, the PF entity deployed at the UE can remove useless information (one or more of MBI, FI, and DAI) from the packet header. For example, useless information may include one or more of the following: the MBI configured for the current PF, and the MBIs of one or more non-forwarding data paths (e.g., paths different from the path followed by the data to be forwarded). In 2622, the PF entity deployed at the UE can also encapsulate one or more of other configured MBI, FI, and DAI into the packet header. In 2622, the PF entity deployed at the UE can also include the processed data result in the packet payload. In 2623, the PF entity can also forward packets to the first participating PF on the network side (e.g., RAN-PF or CN-PF) via XRB (established according to the operations described in references 2613 and 2614) based on the PSI configured in the MBI (based on the operational configuration described in reference 2621) and (optionally) path information (based on the operational configuration described in references 2615 to 2619).

[0295] In some respects, if one or more of the MBI, FI, and DAI are not encapsulated into a header by the UE based on the operation described in reference 2622, process 2600 may further include: 2624, the network-side first participating PF (e.g., RAN-PF, CN-PF) processes the data received from the XRB based on a data processing configuration (e.g., based on the operation configuration described in reference 2620, or configured in the MBI based on the operation described in reference 2621). In 2624, the network-side first participating PF (e.g., RAN-PF, CN-PF) may also perform header decapsulation as described herein, referring to paths with or without forks, for example... Figures 16 to 25For example, the first participating PF can remove useless information (e.g., one or more of MBI, FI, and DAI) from the packet header. Useless information may include, for example, one or more of the following: the MBI configured for the current PF, and the MBIs of one or more non-forwarding data paths (e.g., paths different from the path followed by the data to be forwarded). In 2624, the first participating PF can also encapsulate one or more of other configured MBI, FI, and DAI into the packet header. The first participating PF can also include the processed data result in the packet payload. The first participating PF can also forward packets to a second participating PF via a connection and lower-layer TNL tunnel based on the PSI configured in the MBI (e.g., based on the operational configuration described in reference 2621) and (optionally) path information (e.g., based on the operational configuration described in references 2615 to 2619). The connection and lower-layer TNL tunnel can be established based on the operations described in references 2602 to 2612. The mapping between the connection and the lower-level TNL tunnel can also be configured to the first and second participating PFs based on the operations described in references 2602 to 2612.

[0296] In some respects, if one or more of the MBI, FI, and DAI have been encapsulated into a header by the UE based on the operations described in reference 2622, the network-side first-involved PF (e.g., RAN-PF, CN-PF) can process the data received from the XRB based on a data processing configuration (based on the MBI encapsulated in the header, which is received according to the operations described in references 2622 and 2623, or based on a configuration performed according to reference 2620). The network-side first-involved PF can also perform header decapsulation as described herein, referring to paths with or without forks, for example, referring to... Figures 16 to 25 In some aspects, the ingress PF and egress PF can be deployed independently or integrated into a PF. Depending on the situation (e.g., integrated PF, ingress PF, and egress PF), header decapsulation can be performed based on one or more aspects described herein, referring to paths with forks (e.g., first method 1600). Figure 16 Method 1700 Figure 17 and further reference Figures 18 to 22 )) or a path without branches (as referenced in this article) Figures 23 to 25 (As described).

[0297] For example, the first participating PF on the network side can remove useless information (e.g., one or more of MBI, FI, and DAI). Useless information may include, for example, one or more of the following: the MBI configured for the current PF, and the MBI of one or more non-forwarding data paths (e.g., paths different from the path followed by the data to be forwarded). The first participating PF on the network side can also encapsulate one or more of other configured MBI, FI, and DAI into the packet header. The first participating PF on the network side can also include the processed data result in the packet payload. The first participating PF entity on the network side can forward the packet to the second participating PF via a connection and lower-layer TNL tunnel based on the PSI of the MBI (encapsulated in the packet header, which is received according to the operations described in references 2622 and 2623) and (optionally) path information (configured based on the operations described in references 2615 to 2619). The connection and lower-layer TNL tunnel can be established based on the operations described in references 2602 to 2612. The mapping between the connection and the lower-level TNL tunnel can also be configured to the first and second participating PFs based on the operations described in references 2602 to 2612.

[0298] In some aspects, process 2600 may further include: a second participating PF (e.g., RAN-PF, CN-PF) processing data received from the connection based on a data processing configuration (based on an MBI encapsulated in a header received according to the operations described in references 2622 and 2623, or based on a configuration performed according to reference 2620). The second participating PF may perform header decapsulation as described herein, referring to paths with or without forks, for example, referring to... Figures 16 to 25 In some aspects, the ingress PF and egress PF can be deployed independently or integrated into a PF. Depending on the situation (e.g., integrated PF, ingress PF, and egress PF), header decapsulation can be performed based on one or more aspects described herein, referring to a forked path (e.g., first method 11600). Figure 16 Method 1700 Figure 17 and further reference Figures 18 to 22 )) or a path without branches (as referenced in this article) Figures 23 to 25 The above).

[0299] For example, the second participating PF can remove useless information (e.g., one or more of MBI, FI, and DAI). Useless information may include, for example, one or more of the following: the MBI configured for the current PF, and the MBIs of one or more non-forwarding data paths (e.g., paths different from the path followed by the data to be forwarded). The second participating PF can also encapsulate one or more of other configured MBIs, FIs, and DAIs into the packet header. The second participating PF can also include the processed data result in the packet payload. The second participating PF can then forward data to the third participating PF via a connection and lower-layer TNL tunnel based on the PSI of the MBI (encapsulated in the packet header, which is received according to the operations described in references 2622 and 2623) and path information (configured based on the operations described in references 2615 to 2619). The connection and lower-layer TNL tunnel can be established based on the operations described in references 2602 to 2612. The mapping between the connection and the lower-layer TNL tunnel can also be configured for the second and third participating PFs based on the operations described in references 2602 to 2612.

[0300] Data can be processed and forwarded until the last participating PF receives the data. The last participating PF can then further process the data accordingly. Afterward, the execution of tasks, branch tasks, or subtasks in the uplink can be completed.

[0301] This article references Figures 16 to 25 One or more aspects of the document describe one or more operations performed for message encapsulation and decapsulation for paths with or without forks.

[0302] In some respects, process 2600 may also include one or more operations relating to task execution in the downlink, as described with reference to 2625 to 2627.

[0303] According to one aspect, in 2625, for downlink data, when executing tasks, branch tasks, or subtasks, the first participating PF on the network side (e.g., CN-PF) can process the data based on the data processing configuration (e.g., the configuration information described in 2620, or the configuration information in the MBI described in 2621). In 2625, the first participating PF on the network side can execute as described in reference... Figures 16 to 25 The aforementioned message header encapsulation and decapsulation. As mentioned above, in some aspects, the ingress PF and egress PF can be deployed independently or integrated into a PF, depending on the situation (e.g., integrated PF, ingress PF, and egress PF), and can be based on paths with branching (e.g., first method 1600). Figure 16 Method 1700 Figure 17 ), and further references Figures 18 to 22)) or a path without branches (as referenced in this article) Figures 23 to 25 The packet header decapsulation is performed using one or more methods described above. The first participating PF can remove useless information (e.g., one or more of MBI, FI, and DAI). For example, useless information may include one or more of the following: the MBI configured for the current PF, and the MBIs of one or more non-forwarding data paths (e.g., paths different from the path followed by the data to be forwarded). The first participating PF can also encapsulate one or more of other configured MBIs, FI, and DAIs into the packet header. The first participating PF can also include the processed data result in the payload. The first participating PF can forward (2626) data to the second participating PF (e.g., RAN-PF) via a connection and lower-layer TNL tunnel based on the PSI configured in the MBI (e.g., based on the operation configuration described in reference 2621) and path information (e.g., based on the operation configuration described in references 2615 to 2619). The connection and lower-layer TNL tunnel can be established based on the operation described in references 2602 to 2612. The mapping between the connection and the lower-level TNL tunnel can also be configured to the first and second participating PFs based on the operations described in references 2602 to 2612.

[0304] In some aspects, process 2600 may further include: a second participating PF (e.g., RAN-PF) processing data received from the connection based on a data processing configuration (based on an MBI encapsulated in a header received according to the operations described in references 2622 and 2623, or based on a configuration performed according to reference 2620). The second participating PF may perform header decapsulation as described herein, referring to paths with or without forks, for example, referring to... Figures 16 to 25 As described herein, in some aspects, the ingress PF and egress PF can be deployed independently or integrated into a PF. Depending on the situation (e.g., integrated PF, ingress PF, and egress PF), header decapsulation can be performed based on one or more aspects described herein, referring to a forked path (e.g., first method 11600). Figure 16 Method 1700 Figure 17 and further reference Figures 18 to 22 ) or a path without branches (as referenced in this article) Figures 23 to 25 The above).

[0305] For example, the second participating PF can remove useless information (e.g., one or more of MBI, FI, and DAI). Useless information may include, for example, one or more of the following: the MBI configured for the current PF, and the MBI of one or more non-forwarding data paths (e.g., paths different from the path followed by the data to be forwarded). The second participating PF can also encapsulate one or more of other configured MBI, FI, and DAI into the header. The second participating PF can also include the processed data result in the payload. In 2626, the second involved PF can further forward data to the PF entity of UE 2650 (e.g., the PF entity of the PF protocol layer in the UE) via XRB based on the PSI of the MBI (encapsulated in the header with reference to the operations described in 2622 and 2623) and path information (based on the operation configuration described with reference to 2615 to 2619). The connection and XRB can be established based on the operations described with reference to 2602 to 2612. The mapping between the connection and the XRB can also be configured to the second participating PF and UE based on the operation described in references 2602 to 2612.

[0306] After receiving the data, process 2600 may further include: 2627, UE-PF processes the data. Then, the execution of downlink tasks, branch tasks, or subtasks can be completed.

[0307] As described herein, information indicating one or more of MBI, FI, and DAI can be encapsulated in the message header. MBI may include information indicating one or more of PSI, function, and metric. In some aspects, information indicating PSI may indicate a path ID, connection ID, XRB ID, or PF ID. In some aspects, information indicating a function may be a function ID. A function ID may include or map to one or more of task ID and subtask ID. Information indicating a function may indicate the process type (data normalization, cleansing, AI, etc.). Information indicating a function may also indicate the data processing algorithm.

[0308] In some respects, the information in an indicator metric can indicate XaaS QoS (e.g., accuracy level, privacy level, etc.). In some respects, the information in an indicator metric can also indicate parameters used for security protection, integrity protection, authentication, etc. In some respects, the information in an indicator metric can include formatted data, such as input data format and output formatted data.

[0309] In some respects, FI (Fork Indication Information) can be embedded after the fork module, as described in this article. In some respects, FI can be embedded before the first fork module, as described in this article. In some respects, data aggregation information (DAI) can indicate that data from multiple paths should be aggregated.

[0310] As described herein, according to, for example, method 1400 ( Figure 14 The control plane (e.g., MM and XC) can program one or more of the MBI (including PSI), FI, and DAI. In some respects, the control plane (e.g., MM and XC) can configure programmed information to the first PF to participate.

[0311] In some respects, on the data plane, the first PF or UE to participate in the task can perform header encapsulation. All other PFs and UEs can perform header decapsulation. During header decapsulation, the PF can determine one or more of the MBI, FI, and DAI of the current PF. During header decapsulation, the PF can also determine one or more of the MBI, FI, and DAI of its subsequent PFs. During header decapsulation, the PF can also remove useless information (one or more of the MBI, FI, and DAI) as described herein. One or more PFs (e.g., ingress PF and egress PF) can be referenced herein, for example, as described herein. Figures 16 to 25 The message header is decapsulated from one or more of the aforementioned aspects.

[0312] According to the first method 1600 for header decapsulation, the current PF can copy multiple unicast messages (with different headers and the same payload) and send them to the next-hop PF. According to the second method 1600 for header decapsulation, the current PF can send multicast messages to the next-hop PF.

[0313] According to one aspect, information to be encapsulated in the header of a PF protocol layer when source routing is applied is described. For example, the information to be encapsulated can be applied to traffic paths (in the task data plane) that have no branching or aggregation, or one or both. The information can indicate one or more of the MBI, features, and metrics, including PSI. In some aspects, FI can be indicated for traffic paths with branching, and DAI can be indicated for paths with aggregation. It is understood that the information to be encapsulated can be applied to the header of the PF protocol layer above the TNL, or it can be applied to the IP protocol layer.

[0314] Several aspects can support making the data plane reusable and shareable. Accordingly, for example, when a task's traffic path has one or more of branching and aggregation, traffic can be routed through the correct or appropriate workflow (traffic path).

[0315] As described herein, control planes (e.g., MM and XC) can perform operations to generate one or more of MBIs (including PSIs), FIs, and DAIs. Based on one or more aspects described herein, control planes (e.g., MM and XC) can generate and program one or more of MBIs (including PSIs), FIs, and DAIs with or without branching paths.

[0316] According to some aspects, the control plane (e.g., MM and XC) can also configure one or more of MBI (including PSI), FI, and DAI at one or more PFs. According to some aspects, the control plane (e.g., MM and XC) can also configure path information (e.g., path tables) to one or more PFs.

[0317] Some aspects allow for per-flow / tunneling statelessness within the network. Other aspects enable traffic redirection. In some cases, packets may have an embedded list of segments for traffic redirection. Finally, the underlying tunnel can be shared by multiple data flows.

[0318] As described herein, one or more operations can be performed at the data plane (i.e., the PF). The first PF or UE involved in the task can perform header encapsulation. All other PFs and UEs can perform header decapsulation. Header decapsulation can include: removing useless information encapsulated in the header (e.g., one or more of MBI, FI, and DAI) and forwarding one or more additional MBI, FI, and DAI encapsulated in the header to the next hop. Removing useless information can include: removing the MBI of the current PF and the MBI of one or more non-forwarding data paths (e.g., paths different from the path to be forwarded).

[0319] As described herein, a data plane (e.g., a PF) can decapsulate packet headers for paths with branching (and optionally paths with aggregation) according to a first method 1600 and a second method 1700. In some aspects, according to the first method 1600, a preceding PF can copy multiple unicast packets (with different packet headers and the same packet payload) and send them to the next-hop PF. According to the second method 1700, a preceding PF can send multicast packets to the next-hop PF.

[0320] Several aspects can improve scalability in data processing configuration for multicast transmissions. According to some aspects, the pre-configuration of MDTs and replication lists (stateless) can be avoided, and more flexible and dynamic data forwarding can be achieved. Furthermore, the aspects of this disclosure are available and efficient for various scenarios (e.g., unicast, multicast, loop-free, non-loop-free).

[0321] Figure 28 A method for programming processing information used for data forwarding and data processing is illustrated in one aspect. Method 2800 can be performed by a control plane function (e.g., MM). Method 2800 includes: 2801, generating multiple module block information (MBIs) and one or more fork indications (FIs), each MBI corresponding to one of multiple modules participating in the task, the one or more FIs indicating one or more fork modules among the multiple modules. Each fork module among the one or more fork modules can divide a data path into multiple fork paths. Method 2800 may further include: 2802, arranging the multiple MBIs and one or more FIs into an ordered list based on the participation order of the multiple modules in the task. Method 2800 may further include: 2803, sending the ordered list to one or more service controllers.

[0322] In some respects, arranging multiple MBIs and one or more FIs into an ordered list based on the task participation order of multiple modules may also include: setting the first MBI corresponding to the first module among the multiple MBIs in the ordered list, wherein the first module is the first module to participate based on the participation order.

[0323] In some aspects, the method may further include: placing one or more MBIs in an ordered list and after a first MBI, the one or more MBIs corresponding to one or more modules participating in the task, the one or more modules following the first module up to and including a first fork module. The one or more MBIs can be arranged according to the participation order of the corresponding one or more modules and the first fork module in the task. The first fork module can divide the data path into multiple fork paths of the first fork module.

[0324] In some respects, the first module is the first fork module, and the first MBI is the MBI of the first fork module. The first fork module can divide the data path into multiple fork paths of the first fork module.

[0325] In some aspects, the method may further include: placing multiple sets of processing data in an ordered list following the MBI of the first forked module. Each set of processing data may correspond to a corresponding fork path among multiple forked paths of the first forked module. Each set of processing data may include one or more MBIs, the one or more MBIs corresponding to one or more modules in the corresponding forked path. Each set of processing data may also include FIs, the FIs corresponding to a first module in the corresponding forked path that participates in the task after the first forked module.

[0326] In some respects, the multiple forked paths of the first forked module execute tasks in parallel.

[0327] In some aspects, setting multiple sets of processing data in the ordered list after the MBI of the first fork module includes: for each of the multiple fork paths of the first fork module, setting the corresponding FI and the corresponding one or more MBIs in the ordered list based on the participation order of the corresponding one or more modules in the corresponding fork path in the task.

[0328] In some aspects, method 2800 may further include setting the FI corresponding to the first fork module in the ordered list, after the MBI of the first fork module and before the plurality of processed data.

[0329] In some aspects, at least one of the plurality of forked paths of the first forked module includes one or more forked modules. For each of the at least one forked path of the plurality of forked paths, each of the one or more forked modules can divide a corresponding data path into a corresponding plurality of forked paths for each forked module. For each of the at least one forked path of the plurality of forked paths, the one or more forked modules and the first forked module can participate in the task according to the participation order. For each of the at least one forked path of the plurality of forked paths, the method may further include: for each corresponding forked module of the one or more forked modules, setting first processing data in the ordered list and after the MBI of the forked module preceding each forked module, as determined according to the participation order. The first processing data may include one or more MBIs corresponding to one or more modules participating in the task, the one or more modules following the forked modules preceding each forked module, up to and including each forked module. The first processed data may further include FI, which corresponds to the first module participating in the task after the forked module preceding each forked module.

[0330] For each of the at least one fork in the plurality of fork paths, the method may further include: for each corresponding fork module among the one or more fork modules, the control plane function sets multiple sets of processing data in the ordered list and after the first processing data. Each set of processing data may correspond to a corresponding fork path among the corresponding plurality of fork paths for each fork module. Each set of processing data may include one or more MBIs, the one or more MBIs corresponding to one or more modules participating in the corresponding fork path. Each set of processing data may further include FI, the FI corresponding to a first module participating in the task after each fork module in the corresponding fork path.

[0331] In some respects, for each of at least one set of processed data in the plurality of sets of processed data, the corresponding one or more MBIs correspond to one or more modules, the one or more modules participating in the corresponding fork path up to and including the fork modules in the one or more fork modules following each fork module, as determined according to the order of participation.

[0332] In some respects, the respective multiple forking paths of each of the multiple forking modules can execute the task in parallel.

[0333] In some aspects, the one or more MBIs and FIs in the first processed data can be arranged according to the participation order of their corresponding one or more modules in the task. In some aspects, the one or more MBIs and FIs in each set of processed data can be arranged according to the participation order of their corresponding one or more modules in the task.

[0334] In some aspects, for each of the one or more fork modules in at least one of the plurality of fork paths of the first fork module, the method may further include: setting the FI corresponding to the fork module preceding each fork module in the ordered list, after the MBI of the fork module preceding each fork module and before the first processed data.

[0335] In some aspects, for each of the one or more fork modules in at least one of the plurality of fork paths of the first fork module, the method may further include: setting the FI corresponding to each fork module in the ordered list, after the first processed data and before the plurality of sets of processed data.

[0336] In some aspects, method 2800 may further include: setting the FI value to correspond to the FI of the first fork module. In some aspects, method 2800 may further include: for each FI corresponding to each fork module, setting a corresponding FI value based on the FI value of the FI corresponding to the fork module preceding each fork module.

[0337] In some aspects, each of the plurality of MBIs includes one or more of the following: path selection information (PSI), function indication, metric, and data aggregation indication (DAI). In some aspects, the PSI indicates one or more of the following: a path identifier (ID) identifying a traffic path from the processing function (PF) corresponding to each MBI to the next-hop PF of that PF; a connection ID identifying the connection between the PF and the next-hop PF; the ID of the next-hop PF; the ID of the radio bearer; and the ID of the PF.

[0338] In some respects, the function indication is one or more IDs of one or more functions, and one or more PFs participating in the task process data according to the one or more functions, the one or more functions including: data processing type, data processing algorithm, the task, branch tasks of the task, and subtasks of the task.

[0339] In some respects, the metric indicates the data processing requirements of each module of the MBI, and the metric includes one or more of the following: quality of service (QoS) requirements for one or both of data processing and data forwarding, parameters for security protection, parameters for integrity protection, parameters for authentication, input data format, and output data format.

[0340] Figure 29Another method provided by one aspect is illustrated. Method 2900 can be performed by a PF entity participating in the task. Method 2900 includes: 2901, the PF entity participating in the task receiving an ordered list of multiple module block information (MBIs) and one or more fork indications (FIs), each MBI corresponding to one of the multiple modules participating in the task, the one or more FIs indicating one or more forked modules among the multiple modules; the multiple MBIs and the FIs are arranged in the ordered list based on the participation order of the multiple modules in the task. Method 2900 may further include: 2902, the PF entity encapsulating a message header with updated processing data based on the ordered list. Method 2900 may further include: 2903, the PF entity sending the encapsulated message to the next-hop PF entity. In some aspects, the encapsulated message may be sent based on path selection information (PSI) of the PF entity's MBIs, which are included in the ordered list.

[0341] In some aspects, the PF entity receives the ordered list from the service controller. In some aspects, the updated processing data may include the ordered list of the MBI and the one or more FIs, but not the MBI of the PF entity.

[0342] In some aspects, the PF entity is located in a fork module, and the next-hop PF entity is on a first fork path among multiple fork paths originating from the PF entity. In some aspects, the updated processing data includes one or more MBIs from the plurality of MBIs, the one or more MBIs corresponding to one or more modules from the plurality of modules participating in the first fork path. The one or more MBIs can be arranged according to the task participation order of the one or more modules in the first fork path. In some aspects, the encapsulated message is a unicast message.

[0343] In some aspects, the updated processing data may also include one or more FIs of one or more fork modules participating in the first fork path. In some aspects, the one or more MBIs and the one or more FIs may be arranged according to the task participation order of the one or more modules and the one or more fork modules in the first fork path.

[0344] In some aspects, the PF entity is located in a fork module, and the PF entity sending the encapsulated message to the next-hop PF entity may include: the PF entity sending the encapsulated message as a multicast message to each of the multiple next-hop PF entities, each of the multiple next-hop PF entities being on a corresponding fork path in a multiple fork path starting from the PF entity.

[0345] In some aspects, for each of the plurality of next-hop PF entities, the identifier (ID) of each next-hop PF entity is indicated in the MBI of each next-hop PF entity included in the ordered list, and the updated processing data includes one or more of the MBIs and FIs of a set of modules participating in the plurality of forked paths.

[0346] In some aspects, for each of the plurality of next-hop PF entities, the identifier (ID) of each next-hop PF entity is indicated in the MBI of the PF entity, and the updated processing data may include one or more of the MBIs and FIs of the PF entity and a set of modules of the plurality of modules participating in the plurality of forked paths.

[0347] In some aspects, method 2900 may further include: the PF entity processing the data based on a data processing configuration to obtain a processing result, wherein the processing result is included in the payload of the encapsulated message.

[0348] In some respects, the data processing configuration is indicated by one of the following: a message received by the PF entity from a control plane function instructing one or more functions, according to which the PF entity processes the data; the MBI of the PF entity.

[0349] In some respects, the PF entity is located in the user equipment, and the encapsulated message is transmitted via a radio bearer identified by the PSI of the MBI of the PF entity, the MBI of the PF entity being included in the ordered list.

[0350] In some aspects, method 2900 may further include: the PF entity receiving the data associated with the task from another PF entity at the user equipment.

[0351] In some aspects, the PF entity receives the ordered list in the header of the message from another PF entity. In some aspects, method 2900 may further include: the PF entity receiving the data in the message associated with the task from the other PF entity.

[0352] In some respects, one of the PF entity and the next-hop PF entity is a core network (PF) entity and the other is a radio access network (RAN) PF. In some respects, the PF entity is a core network (CN) PF entity and the next-hop PF entity is a radio access network (RAN) PF.

[0353] In some aspects, the next-hop PF entity is located in user equipment (UE); the encapsulated message is transmitted via a radio bearer identified by the path selection information (PSI) of the MBI of the PF entity, the MBI of the PF entity being included in the ordered list. In some aspects, the PF entity is a radio access network (RAN) PF entity.

[0354] In some aspects, each of the plurality of MBIs may include one or more of the following: corresponding path selection information (PSI), function indication, metric, and data aggregation indication (DAI). In some aspects, the corresponding PSI may indicate one or more of the following: a path identifier (ID) identifying a traffic path from the processing function (PF) of each MBI to the next-hop PF; a connection ID identifying the connection between the PF of the MBI and the next-hop PF; the ID of the next-hop PF; the ID of the radio bearer; and the ID of the PF of each MBI.

[0355] In some respects, the function indication is one or more IDs of one or more functions, and one or more PFs participating in the task process data according to the one or more functions, the one or more functions including: data processing type, data processing algorithm, the task, branch tasks of the task, and subtasks of the task.

[0356] In some respects, the metric indicates the data processing requirements of each module of the MBI, and the metric includes one or more of the following: quality of service (QoS) requirements for one or both of data processing and data forwarding, parameters for security protection, parameters for integrity protection, parameters for authentication, input data format, and output data format.

[0357] Figure 30 A device 3000 is illustrated, provided by different aspects of this disclosure, which can perform any or all of the operations of the methods and features described herein, whether explicitly or implicitly. For example, a computer equipped with network capabilities may be configured as device 3000. In some aspects, device 3000 may be a network function, RAN function, control plane function, network node, gateway, service controller, device, processing function, or any entity described herein that can be used to perform one or more of the operations described herein. In some aspects, device 3000 may be a device connected to network infrastructure via a wireless interface, such as a mobile phone, smartphone, or other device that can be classified as user equipment (UE). In some aspects, device 3000 may be a machine-type communications (MTC) device (also known as a machine-to-machine (m2m) device), or other such device that, although not providing direct service to a user, can be classified as a UE. In some aspects, device 3000 may be used to implement one or more aspects described herein. For example, device 3000 may be used to perform operations performed by one or more entities and functions described herein.

[0358] As shown in the figure, device 3000 may include a processor 3010, such as a central processing unit (CPU) or a dedicated processor, such as a graphics processing unit (GPU) or other such processing unit; memory 3020; non-transient mass storage 3030; an input-output interface 3040; a network interface 3050; and a transceiver 3060, all of which are communicatively coupled via a bidirectional bus 3070. Depending on certain aspects, any or all of the described elements may be used, or only a subset thereof. Furthermore, device 3000 may contain multiple instances of certain elements, such as multiple processors, memories, or transceivers. Additionally, elements of the hardware device may be directly coupled to other elements without a bidirectional bus. Other electronic components, such as integrated circuits, may be used to perform the required logical operations in addition to or in place of processors and memory.

[0359] Memory 3020 may include any type of non-transitory memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination thereof. Mass storage element 3030 may include any type of non-transitory storage device, such as a solid-state drive, hard disk drive, disk drive, optical disk drive, USB drive, or any computer program product for storing data and machine-executable program code. Depending on some aspects, memory 3020 or mass storage 3030 may record statements and instructions executable by processor 3010 thereon for performing any of the above-described methods.

[0360] The aspects of this disclosure can be implemented using electronic hardware, software, or a combination thereof. In some aspects, this disclosure can be implemented by one or more computer processors executing program instructions stored in memory. In some aspects, the invention is implemented in part or in whole in hardware, for example using one or more field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs) to perform processing operations rapidly.

[0361] It should be understood that although specific aspects of the technology have been described herein for illustrative purposes, various modifications can be made without departing from the scope of the technology. Therefore, the specification and drawings are to be considered merely as a description of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations, or equivalents within the scope of the invention. Specifically, within the scope of this technology, a computer program product or program element, or a program storage device or memory device (e.g., magnetic or optical wires, magnetic tape or disk, etc.) is provided for storing machine-readable signals, controlling the operation of a computer according to the method of this technology, and / or constructing some or all of its components according to the system of this technology.

[0362] The actions associated with the methods described herein can be implemented as coded instructions in a computer program product. In other words, a computer program product is a computer-readable medium on which software code is recorded, which executes the method when the computer program product is loaded into memory and executed on the microprocessor of a wireless communication device.

[0363] Furthermore, each operation of this method can be executed on any computing device, such as a personal computer, server, PDA, etc., based on one or more program elements, modules, or objects generated from any programming language, such as C++, Java, or a portion thereof. Additionally, each operation or the file or object implementing each operation can be performed by dedicated hardware or a circuit module designed for this purpose.

[0364] Based on the foregoing description, this invention can be implemented using only hardware, or using software and necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this 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), USB, flash drive, or portable hard drive. The software product includes numerous instructions that enable a computer device (personal computer, server, or network device) to perform the methods provided in various aspects of this invention. For example, such performance may correspond to the simulation of the logical operations described herein. According to various aspects of this invention, additionally or alternatively, the software product may include multiple instructions that enable a computer device to perform operations configuring or programming digital logic devices.

[0365] 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. Therefore, the specification and drawings are to be regarded merely as a description of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations, or equivalents within the scope of the invention.

Claims

1. A method, characterized in that, include: The control plane function generates multiple Module Block Information (MBI) and one or more Fork Indicators (FI). Each MBI corresponds to one of the multiple modules participating in the task. The one or more FIs indicate one or more fork modules among the multiple modules. Each fork module among the one or more fork modules divides the data path into multiple fork paths. The control plane function arranges the multiple MBIs and one or more FIs into an ordered list based on the order in which the multiple modules participate in the task. The control plane function sends the ordered list to one or more service controllers.

2. The method according to claim 1, characterized in that, The control plane function arranges the multiple MBIs and one or more FIs into an ordered list based on the task participation order of the multiple modules, including: The control plane function sets the first MBI corresponding to the first module among the multiple MBIs in the first position of the ordered list, where the first module is the first module to participate based on the participation order.

3. The method according to claim 2, characterized in that, Also includes: The control plane function sets one or more MBIs in the ordered list and after the first MBI. The one or more MBIs correspond to one or more modules participating in the task. The one or more modules are after the first module, up to and including the first fork module. The one or more MBIs are arranged according to the participation order of the corresponding one or more modules and the first fork module in the task. The first fork module divides the data path into multiple fork paths of the first fork module.

4. The method according to claim 2, characterized in that, The first module is the first fork module, the first MBI is the MBI of the first fork module, and the first fork module divides the data path into multiple fork paths of the first fork module.

5. The method according to claim 3 or 4, characterized in that, Also includes: The control plane function sets multiple sets of processed data in the ordered list after the MBI of the first branching module. Each set of processed data is as follows: Corresponding to the corresponding branch path among the plurality of branch paths of the first branching module; and include: One or more corresponding MBIs, wherein the one or more corresponding MBIs correspond to one or more modules in the corresponding fork path; The corresponding FI corresponds to the first module in the corresponding fork path that participates in the task after the first fork module.

6. The method according to claim 5, characterized in that, The multiple branch paths of the first branch module execute the task in parallel.

7. The method according to claim 5 or 6, characterized in that, The control plane function sets multiple sets of processed data in the ordered list after the MBI of the first fork module, including: For each of the plurality of forking paths in the first forking module: The control plane function sets a corresponding first FI and one or more corresponding MBIs in the ordered list based on the participation order of one or more modules in the corresponding branch path in the task.

8. The method according to any one of claims 5 to 7, characterized in that, Also includes: The control plane function sets the FI corresponding to the first fork module in the ordered list, after the MBI of the first fork module and before the multiple sets of processed data.

9. The method according to claim 3 or 4, characterized in that, At least one of the multiple forking paths of the first forking module includes one or more forking modules, and for each of the at least one forking path in the multiple forking paths: Each of the one or more forking modules divides the corresponding data path into multiple forking paths of that forking module. The one or more forked modules and the first forked module participate in the task according to the participation order. For each of the one or more forked modules, the method further includes: The control plane function sets the first processing data in the ordered list and after the MBI of the forked module preceding each forked module, as determined according to the participation order. The first processing data includes: One or more MBIs, the one or more MBIs corresponding to one or more modules participating in the task, the one or more modules following the forked module before each forked module, up to and including each forked module; FI, wherein the FI corresponds to the first module participating in the task after the forked module preceding each forked module; The control plane function sets multiple sets of processing data in the ordered list and places them after the first set of processing data. Each set of processing data: Corresponding to the corresponding branch path among the corresponding plurality of branch paths of each branch module; and include: One or more MBIs, the one or more MBIs corresponding to one or more modules participating in the corresponding fork path; FI, where FI corresponds to the first module in the corresponding forked path that participates in the task after each forked module.

10. The method according to claim 9, characterized in that, For each set of processed data in at least one of the multiple sets of processed data, the corresponding one or more MBIs correspond to one or more modules, which participate in the corresponding fork path up to and including the fork modules in the one or more fork modules following each fork module, as determined according to the order of participation.

11. The method according to claim 9 or 10, characterized in that, The tasks are executed in parallel by the corresponding multiple forking paths of each of the multiple forking modules.

12. The method according to any one of claims 9 to 11, characterized in that: The one or more MBIs and the FI in the first processed data are arranged according to the participation order of the corresponding one or more modules in the task; The one or more MBIs and the FI in each group of processed data are arranged according to the participation order of the corresponding one or more modules in the task.

13. The method according to any one of claims 9 to 12, characterized in that, For each of the one or more forked modules, the method further includes: The control plane function sets the FI corresponding to the fork module preceding each fork module in the ordered list, after the MBI of the fork module preceding each fork module and before the first processed data; The control plane function sets the FI corresponding to each branch module in the ordered list, after the first processed data and before the multiple sets of processed data.

14. The method according to claim 13, characterized in that, Also includes: The control plane function sets the FI value to correspond to the FI of the first fork module; For each FI corresponding to each fork module, the control plane function sets the corresponding FI value based on the FI value of the FI corresponding to the fork module preceding each fork module.

15. The method according to any one of claims 1 to 14, characterized in that, Each of the plurality of MBIs includes one or more of the following: Path Selection Information (PSI), Function Indicator, Metric, and Data Aggregation Indicator (DAI).

16. The method according to claim 15, characterized in that, The PSI indicates one or more of the following: Path Identifier ID, which identifies the traffic path from the processing function PF corresponding to each MBI to the next-hop PF of the PF; Connection ID identifies the connection between the PF and the next-hop PF; The ID of the next-hop PF; the ID of the radio bearer; the ID of the PF.

17. The method according to claim 15 or 16, characterized in that, The function indicator is one or more IDs of one or more functions. One or more power processes (PFs) participating in the task process data according to the one or more functions. The one or more functions include: data processing type, data processing algorithm, the task, branch tasks of the task, and subtasks of the task.

18. The method according to any one of claims 15 to 17, characterized in that, The metric indicates the data processing requirements of each module of the MBI, and the metric includes one or more of the following: QoS requirements for one or both of data processing and data forwarding, parameters for security protection, parameters for integrity protection, parameters for authentication, input data format, and output data format.

19. A method, characterized in that, include: The Processing Function (PF) entity receives an ordered list of multiple Module Block Information (MBI) and one or more Fork Indicators (FI), where each MBI corresponds to one of the multiple modules participating in the task, and the one or more FIs indicate one or more forked modules among the multiple modules; the multiple MBIs and the FIs are arranged in the ordered list based on the participation order of the multiple modules in the task. The PF entity encapsulates a message header containing updated processing data based on the ordered list; The PF entity sends the encapsulated message to the next hop PF entity.

20. The method according to claim 19, characterized in that, The encapsulated message is sent based on the path selection information PSI of the MBI of the PF entity, and the MBI of the PF entity is included in the ordered list.

21. The method according to claim 19 or 20, characterized in that, The PF entity receives the ordered list from the service controller.

22. The method according to any one of claims 19 to 21, characterized in that, The updated processing data includes the MBI and the ordered list of one or more FIs, but does not include the MBI of the PF entity.

23. The method according to any one of claims 19 to 21, characterized in that: The PF entity is located in the fork module; The next-hop PF entity is on the first branch path of a plurality of branch paths starting from the PF entity; The updated processing data includes one or more MBIs among the plurality of MBIs, the one or more MBIs corresponding to one or more modules among the plurality of modules participating in the first fork path, and the one or more MBIs arranged according to the task participation order of the one or more modules in the first fork path; The encapsulated message is a unicast message.

24. The method according to claim 23, characterized in that, The updated processing data also includes one or more FIs of one or more fork modules participating in the first fork path, wherein the one or more MBIs and the one or more FIs are arranged according to the task participation order of the one or more modules and the one or more fork modules in the first fork path.

25. The method according to any one of claims 19 to 21, characterized in that: The PF entity is located in the fork module; The PF entity sends the encapsulated data to the next hop PF entity, including: The PF entity sends the encapsulated message as a multicast message to each of the multiple next-hop PF entities, where each of the multiple next-hop PF entities is on a corresponding branch path in a plurality of branch paths starting from the PF entity.

26. The method according to claim 25, characterized in that, For each of the plurality of next-hop PF entities, the identifier ID of each next-hop PF entity is indicated in the MBI of each next-hop PF entity included in the ordered list, and the updated processing data includes one or more of the MBIs and FIs of a set of modules participating in the plurality of forked paths.

27. The method according to claim 25, characterized in that, For each of the plurality of next-hop PF entities, the identifier ID of each next-hop PF entity is indicated in the MBI of the PF entity, and the updated processing data includes one or more of the MBI and FI of the PF entity and a set of modules of the plurality of modules participating in the plurality of forks.

28. The method according to any one of claims 19 to 27, characterized in that, Also includes: The PF entity processes the data based on the data processing configuration to obtain the processing result, wherein the processing result is included in the payload of the encapsulated message.

29. The method according to claim 28, characterized in that, The data processing configuration is indicated by one of the following: The PF entity receives messages from control plane functions instructing one or more functions, and processes the data according to the one or more functions; The MBI of the PF entity.

30. The method according to any one of claims 19 to 29, characterized in that: The PF entity is located in the user equipment; The encapsulated message is transmitted via a radio bearer identified by the path selection information PSI of the MBI of the PF entity, the MBI of the PF entity being included in the ordered list.

31. The method according to any one of claims 19 to 29, characterized in that, Also includes: The PF entity receives the data associated with the task from another PF entity at the user equipment.

32. The method according to any one of claims 19 to 29, characterized in that, The PF entity receives the ordered list in the header of the message from another PF entity.

33. The method according to claim 32, characterized in that, Also includes: The PF entity receives the data associated with the task in the message from the other PF entities.

34. The method according to any one of claims 19 to 29, characterized in that: One of the PF entity and the next-hop PF entity is a core network (PF) entity, and the other is a radio access network (RAN) PF.

35. The method according to any one of claims 19 to 29, characterized in that: The PF entity is the core network CN PF entity; The next-hop PF entity is RAN PF.

36. The method according to any one of claims 19 to 29, characterized in that: The next-hop PF entity is located in the user equipment (UE); The encapsulated message is transmitted via a radio bearer identified by the path selection information PSI of the MBI of the PF entity, the MBI of the PF entity being included in the ordered list.

37. The method according to claim 37, characterized in that, The PF entity is the Radio Access Network (RAN) PF entity.

38. The method according to any one of claims 19 to 37, characterized in that, Each of the plurality of MBIs includes one or more of the following: corresponding path selection information (PSI), function indication, metric, and data aggregation indication (DAI).

39. The method according to claim 38, characterized in that, The corresponding PSI indicates one or more of the following: Path Identifier ID, which identifies the traffic path from the processing function PF of each MBI to the next-hop PF; Connection ID, which identifies the connection between the PF of the MBI and the next-hop PF; The ID of the next-hop PF; the ID of the radio bearer; And the ID of the PF for each MBI.

40. The method according to claim 38 or 39, characterized in that, The function indicator is one or more IDs of one or more functions. One or more power processes (PFs) participating in the task process data according to the one or more functions. The one or more functions include: data processing type, data processing algorithm, the task, branch tasks of the task, and subtasks of the task.

41. The method according to any one of claims 38 to 40, characterized in that, The metric indicates the data processing requirements of each module of the MBI, and the metric includes one or more of the following: QoS requirements for one or both of data processing and data forwarding, parameters for security protection, parameters for integrity protection, parameters for authentication, input data format, and output data format.

42. An apparatus, characterized in that, include: At least one processor; At least one machine-readable medium storing executable instructions that, when executed by the at least one processor, cause the apparatus to perform the method according to any one of claims 1 to 41.

43. A computer device, characterized in that, It includes a non-transitory computer-readable medium storing instructions that, when executed by a computer processor, cause the computer to perform the method according to any one of claims 1 to 41.

44. A method, characterized in that, include: The first processing function (PF) receives a message from the second PF, including a message header. The message header includes: multiple Module Block Information (MBI) and one or more fork indicators, and an ordered list of FIs. Each MBI corresponds to one of the multiple modules participating in the task, and the one or more FIs indicate one or more forked modules among the multiple modules. The multiple MBIs and the FIs are arranged in the ordered list based on the participation order of the multiple modules in the task.

Images