System and method for RAN protocols for future X-centric service networks

Abstract

The present disclosure provides systems and methods for radio access network (RAN) protocols for future X-centric service networks. According to one aspect, a method for providing a network service is provided. The method includes receiving, by a first device, from a second device at least one protocol data unit (PDU) including at least one service data unit (SDU) associated with the network service. The method further includes extracting, by the first device, at least one SDU from the at least one PDU. The method further includes processing, by the first device, the at least one SDU to obtain a processed version of the at least one SDU. The method further includes constructing, by the first device, at least one additional PDU including the processed version of the at least one SDU. The method further includes transmitting, by the first device, the at least one additional PDU to the second device.

Description

[Technical Field]

[0001] The present disclosure relates to the field of communication networks, and more particularly to a system and method for RAN protocols in an X-centric services network. [Background technology]

[0002] In addition to traditional connectivity-oriented communication services, sixth-generation (6G) wireless networks may include new types of services for network-native data processing. Such new services may require data parsing and processing within the network that may not be supported by current 5G wireless networks. For example, current 5G wireless networks may have limitations on what operations can be performed within the network, which may reduce the availability and delivery of new types of services that may be included in 6G wireless networks. Some limitations of 5G wireless networks may include limitations on operations that can be performed by the radio access network (RAN) and at different layers of the user plane (UP) protocol stack.

[0003] Therefore, there is a need for a system and method for a RAN protocol for future X-centric services networks that obviates or mitigates one or more limitations of the prior art.

[0004] This background information is provided to identify information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should it be construed, that any of the preceding information constitutes prior art against the present invention. Summary of the Invention

[0005] The present disclosure provides systems and methods for RAN protocols for future X-centric service networks. According to one aspect, a method for providing a network service is provided. The method includes receiving, by a first device, from a second device at least one protocol data unit (PDU) including at least one service data unit (SDU) associated with the network service. The method further includes extracting, by the first device, at least one SDU from the at least one PDU. The method further includes processing, by the first device, the at least one SDU to obtain a processed version of the at least one SDU. The method further includes constructing, by the first device, at least one additional PDU including the processed version of the at least one SDU. The method further includes transmitting, by the first device, the at least one additional PDU to the second device.

[0006] The first device may be a Radio Access Network (RAN) node and the second device may be a User Equipment (UE), or the first device may be a UE and the second device may be a RAN node.

[0007] The first device may be a Radio Access Network (RAN) node, and the second device may be a Core Network Function (CNF).

[0008] The first device may be a CNF and the second device may be a RAN node.

[0009] The first device may be a CNF and the second device may be a UE.

[0010] The first device may be a UE and the second device may be a CNF.

[0011] Extracting the at least one SDU, processing the at least one SDU, and constructing the at least one additional PDU may be performed at the first device by a processing function (PF) in the first device.

[0012] Receiving the at least one PDU at the first device may include receiving the at least one PDU over at least one network service data bearer (XDB) established between the first device and the second device, the at least one XDB being configured for the network service.

[0013] The method may be performed within a communication network in which the first device and the second device are deployed, the communication network may include a PF protocol sublayer, and the retrieval of the at least one SDU, the processing of the at least one SDU, and the construction of the at least one additional PDU at the first device may be performed at the PF protocol sublayer by a PF at the first device.

[0014] The UE may include a UE PF deployed in the UE at a PF protocol sublayer, and receiving the at least one PDU from the UE may include receiving the at least one PDU from the UE PF via at least one network service data bearer (XDB) established between the first device and the second device, wherein the at least one XDB may be supported by the PF protocol sublayer.

[0015] The network services may include one or more of data analysis, artificial intelligence (AI) training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

[0016] The communication network may further include a Packet Data Convergence Protocol (PDCP) sublayer, with the PF protocol sublayer deployed above the PDCP sublayer.

[0017] The communication network may further include a Service Data Adaptation Protocol (SDAP) sublayer, and the PF protocol sublayer is deployed below the SDAP sublayer.

[0018] The PDCP sublayer may provide at least one data radio bearer (DRB) to the PF protocol sublayer between the first device and the second device.

[0019] The PF protocol sublayer may provide at least one network service data bearer (XDB) to the SDAP sublayer.

[0020] The communication network may include a radio link control (RLC) sublayer, a medium access control (MAC) sublayer, and a physical (PHY) layer, with the PDCP sublayer overlying the RLC sublayer, the MAC sublayer, and the PHY layer.

[0021] Each of the at least one XDB may have a respective PF entity in the PF protocol sublayer, each PF entity configured for the respective XDB.

[0022] The PDCP sublayer may include, for each of at least one DRB, a respective PDCP entity in the PDCP sublayer.

[0023] The SDAP sublayer may have an SDAP entity configured for at least one session of a network service, any of which may be established between the UE and a Core Network Function (CNF). The method may further include establishing a CN session tunnel between the RAN node and the CNF.

[0024] Any of the at least one session of the network service can include at least one Quality of Service (QoS) flow of the network service, where one QoS flow of the at least one QoS flow of the network service is the finest granularity of QoS differentiation in a session of the at least one session of the network service, and traffic in the same QoS flow of the at least one QoS flow of the network service receives the same data forwarding and data processing treatments.

[0025] The parameters of the data processing process may include one or more of a data processing scheduling policy, a data calculation accuracy, a data calculation latency, an artificial intelligence (AI) model type, an AI model privacy level, an AI model accuracy level, an AI training method, an AI inference method, a privacy protection method, a data management policy, a data sanitization policy, a data compression policy, a data embedding policy, a data representation learning policy, a data feature extraction policy, a data preprocessing policy, a privacy level, a data storage period, a data processing policy, a data cleaning policy, a data normalization policy, a data quality level, and a data processing priority.

[0026] The parameters of the data transfer processing parameters may include one or more of a data transfer resource scheduling policy, a data queue management policy, a data transfer priority level, a link layer protocol configuration, an admission threshold, a data loss rate, a data transfer latency, a data transfer security protection method, and a security level.

[0027] At least one XDB may be configured to serve only UEs. At least one XDB may be further configured to deliver and receive PF protocol sublayer PDUs to and from UEs over the air interface.

[0028] The UE is configured with at least one XDB, one or more PF entities of which are connected to one or more PDCP entities dedicated to the UE.

[0029] At least one XDB of a UE may be mapped to one or more DRBs of the same UE. At least one session of a network service may be mapped by an SDAP entity to at least one XDB dedicated to the UE.

[0030] At least one QoS flow of at least one session of a network service may be mapped by an SDAP entity to at least one XDB dedicated to the UE.

[0031] At least one XDB may be configured for a group of UEs to deliver PF protocol sublayer PDUs to the group of UEs including the UE, and may deliver at least one PF protocol sublayer PDU to the group of UEs and receive at least one PF protocol sublayer PDU from the group of UEs.

[0032] The at least one XDB may distribute copies of the at least one PF protocol sublayer PDU over the air interface to a group of UEs using one of a broadcast method and a multicast method, and a UE in the group of UEs may be configured with at least one XDB.

[0033] At least one PF entity of at least one XDB for a group of UEs may be connected with at least one PDCP entity for the group of UEs, where at least one PDCP entity may be configured for one Multimedia Broadcast Multicast Service (MBMS) point-to-multipoint radio bearer (MRB), and at least one PDCP entity may be configured for one point-to-multipoint radio bearer (NRB).

[0034] At least one session of a network service may be mapped by an SDAP entity to at least one XDB of a group of UEs.

[0035] At least one QoS flow of at least one session of the network service may be mapped by the SDAP entity to at least one XDB of a group of UEs including the UE.

[0036] The at least one XDB may deliver different PF protocol sublayer PDUs, or separate copies of PF protocol sublayer PDUs, to different UEs of the group of UEs over the air interface. The group of UEs may be configured with at least one XDB.

[0037] At least one PF entity of at least one XDB for a group of UEs may be connected to at least one PDCP entity. Any of the at least one PDCP entity may be configured for at least one UE in the group of UEs. Any of the at least one PDCP entity may be connected to at least one Radio Link Control (RLC) entity. Any of the at least one PDCP entity may be configured for one or more of a DRB, a multicast / broadcast service radio bearer (MRB), and a point-to-multipoint radio bearer (NRB).

[0038] At least one session of a network service may be mapped by an SDAP entity to at least one XDB of a group of UEs, and at least one QoS flow of at least one session of a network service may be mapped by an SDAP entity in the SDAP sublayer to at least one XDB of a group of UEs.

[0039] The PF protocol sublayer may include a PF entity, which may include one or more of a data buffer component, a data processing component, a routing component, and a data forwarding component.

[0040] The data buffer component may be configured to perform one or more of storing data, buffering data, and accumulating data for the data processing component to perform data processing.

[0041] The data processing component may be configured to perform data processing using one or more of the following methods: data analysis, artificial intelligence (AI) training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

[0042] The routing component of the PF entity may be configured to add routing information to a header of the PF PDU to help another PF entity determine a routing action, and the routing component may be further configured to determine a routing action of the PF entity based on the routing information included in the header of the PF PDU.

[0043] The routing action of the PF entity or the routing action of another entity may include one or more of stopping the data forwarding, forwarding the data to a PF entity residing in the same node as the PF entity, forwarding the data to a PF entity residing in the same node as another PF entity, forwarding the data to a PF entity in a peer node, forwarding the data to an entity in a higher layer, or forwarding the data to an entity in a lower layer, and the data includes one or more of a PF SDU contained in the PF PDU, a processed version of the PF SDU contained in the PF PDU, a constructed PF PDU having the PF SDU contained in the PF PDU, or a constructed PF PDU having a processed version of the PF SDU contained in the PF PDU.

[0044] The data forwarding component may be configured to perform one or more of the following with respect to the data: mapping or delivering the data to a corresponding transmission tunnel or channel; performing sequence numbering of the data; and sequentially delivering the data to a PF protocol sublayer, upper layer, or lower layer.

[0045] The PF entity may perform one or more of receiving at least one PF SDU from a higher layer or delivering it to a higher layer. The PF entity may perform one or more of receiving at least one PF SDU from a lower layer or delivering it to a lower layer. The PF entity may perform one or more of receiving at least one PF SDU from another PF entity or delivering it to another PF entity. The PF entity may perform one or more of submitting at least one PF PDU to a lower layer or receiving it from a lower layer. The PF entity may perform one or more of submitting at least one PF PDU to another PF entity or receiving it from another PF entity. The at least one PF PDU may include one or more of a packet header and a PF SDU.

[0046] One of the at least one PF PDUs may include a packet header indicating one or more of a type of network service to which the one PF PDU belongs, a sequence number of the one PF PDU, an instruction for further processing the one PF SDU included in the one PF PDU, a type of data processing for the one PF SDU included in the one PF PDU, an instruction for directly forwarding the PF SDU included in the one PF PDU, routing information, and a network service QFI identifying a QoS flow to which the one PF PDU belongs.

[0047] The type of data processing may include one or more of the following methods: data analysis, AI training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction. The method of claim 51.

[0048] The routing information may indicate a destination to which the PF entity receiving the PF PDU should forward the data, and the data may include one or more of the PF SDU contained in the PF PDU, a processed version of the PF SDU contained in the PF PDU, a constructed PF PDU containing the PF SDU contained in the PF PDU, or a constructed PF PDU with a processed version of the PF SDU contained in the PF PDU.

[0049] The destination can be one or more of the following: a PF entity, another PF entity residing in the same node as the PF entity, another PF entity in a peer node, an entity in a higher layer, or an entity in a lower layer.

[0050] Extracting the at least one SDU from the at least one PDU may include extracting the at least one PF SDU from the at least one PF PDU by the PF entity. Extracting the at least one PF SDU from the at least one PF PDU may further include removing one or more packet headers included in the at least one PF PDU.

[0051] Constructing the at least one additional PF PDU may be performed by the PF entity after extracting the at least one PF SDU from the at least one PF PDU. Constructing the at least one additional PDU may include one or more of parsing and processing the raw data encapsulated in the one or more payloads of the at least one PF SDU using one or more methods of data analysis, AI training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

[0052] For at least one XDB of a network service, dedicated types of associated DRBs, RLC channels, logical channels, transport channels, and / or physical channels may be defined, provided, or configured. Similarly, dedicated physical radio resources may be allocated to at least one XDB of a network service.

[0053] At least one XDB and the associated DRB are configured to multiplex associated radio resources using the same MAC entity of the associated MAC sublayer.

[0054] The at least one XDB may be configured via a dedicated signaling message for the network service or a Radio Resource Control (RRC) message for the network service, which may be sent via a signaling radio bearer between the RAN node and the UE by a control entity of a control protocol layer above the associated PDCP sublayer.

[0055] The PF entity may include one or more of a transmitter and a receiver, each of which performs one or more functions of the PF entity.

[0056] The PF protocol sublayer may be configured in one or more of the RAN node and the UE node, and may operate in a transparent mode when the RAN node is to perform data forwarding.

[0057] The PF protocol sublayer can be configured in the RAN node and the UE without configuring a session tunnel between the RAN node and the CNF, and network services can involve the RAN node and the UE without involving the CNF.

[0058] The PF protocol sublayer may be configured in the RAN node without configuring the SDAP sublayer, the wireless L2 sublayer, and the PHY layer in the RAN node. Network services may involve the RAN node and the CNF without involving the UE.

[0059] Sublayers including an SDAP sublayer, a PF protocol sublayer, an associated PDCP sublayer, an associated RLC sublayer, an associated MAC sublayer, and an associated PHY layer may be configured in the RAN node and the UE. When a network service involves the RAN node, the UE, and the CNF, a session tunnel between the CNF and the RAN node may be configured.

[0060] The RAN node, UE, and CNF may be configured without an SDAP sublayer. The traffic granularity of the QoS flows of the network service may be the same as the traffic granularity of at least one XDB.

[0061] A CNF PF entity may be configured within an associated PF protocol layer in a CNF node, and the CNF PF entity may perform the functions of at least one of a RAN PF entity in a RAN node and a UE PF entity in a UE.

[0062] The PF sublayer may be deployed in one of: above the PDCP sublayer, between the SDAP sublayer and the PDCP sublayer, between the PDCP sublayer and the RLC sublayer, between the RLC sublayer and the MAC sublayer, between the MAC sublayer and the PHY layer, above the SDAP sublayer, above the 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, above the Segment Routing over 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.

[0063] Traffic in the same XDB of the at least one SDB may receive the same data transfer operation and data processing operation, and one or more data processing operation parameters and data transfer operation parameters are configured for each XDB of the at least one XDB.

[0064] According to another aspect, another method is provided. The method includes receiving, by a Radio Access Network (RAN) node, from a user equipment (UE) a first message including a service data unit (SDU) associated with a network service. The method further includes extracting, by the RAN node, the SDU from the first message. The method further includes transmitting, by the RAN node, a second message to the UE based on the SDU.

[0065] The first message may include a quality of service flow identifier (QFI). The method may further include sending, by the RAN node, a third message including the SDU to a Core Network (CN) Function (CNF) over the session established between the UE and the CNF. The method may further include receiving, by the RAN node over the session from the CNF, a fourth message having a processed version of the SDU obtained based on the processing indicated by the QFI.

[0066] The QFI may indicate a processing procedure, and the method may further include processing, by the RAN node, the SDU according to the processing procedure to obtain a processed version of the SDU.

[0067] The method may further include constructing, by the RAN node, a set of packet data units (PDUs) comprising the processed versions of the SDUs, wherein the second message comprises the set of PDUs.

[0068] At least one PDU of the set of PDUs may include a header indicating one or more of the type of network service, a sequence number, an indication for determining if further processing is required, an indication for direct forwarding of the PDU, routing information, and the QFI to which the PDU belongs.

[0069] Receiving the message, extracting the SDUs, and building the set of PDUs may be performed by a processing function in the RAN node.

[0070] The first message may be received via a data bearer established between the RAN node and the UE, the data bearer being configured for the network service. The data bearer may be configured via an RRC message or a signaling message received from a control plane function.

[0071] The data bearer may be a dedicated data bearer for the UE. The UE may be part of a UE group, and a data bearer may be configured for the UE group. The data bearer may be mapped to one or more Multicast / Broadcast Service (MBS) Radio Bearers (MRBs).

[0072] Sending, by the RAN node, the second message to the UE may include sending, by the RAN node, the second message to each UE in the UE group via the MRB.

[0073] The network service may be a NET4AI service, and the first message may indicate local model parameters of the UE. If the network service is NET4AI, extracting the SDU from the message includes extracting, by the RAN node, the local model parameters.

[0074] If the first message includes a QFI, the method may further include aggregating, by the RAN node, local model parameters of a plurality of UEs including the UE based on a processing operation indicated by the QFI. The method may further include obtaining, by the RAN node, global model parameters based on the aggregation and processing operation.

[0075] The method may further include sending, by the RAN node to a Core Network (CN) Function (CNF) over a session established between the UE and the CNF, a third message having the local model parameters. The method may further include receiving, by the RAN node from the CNF, a fourth message having global local parameters determined based on the local model parameters of a plurality of UEs including the UE.

[0076] The method may further include constructing, by the RAN node, a set of PDUs comprising the global local parameters, wherein the second message comprises the set of PDUs.

[0077] The network service may be a DAM service, and the first message may indicate an output of an adversarial model based on training the adversarial model. If the network service may be a DAM service, extracting the SDU from the first message may include extracting, by the RAN node, the output of the adversarial model.

[0078] If the network service may be a DAM service and the first message may include a QFI, the method may further include training, by the RAN node, a generative model using an output of the adversarial model based on a processing operation indicated by the QFI. The method may further include obtaining, by the RAN node, an output of the generative model based on the training and processing operation.

[0079] If the network service may be a DAM service, the method may further include sending, by the RAN node to a Core Network (CN) Function (CNF) via a session established between the UE and the CNF, a third message having an output of the adversarial model. The method may further include receiving, by the RAN node from the CNF, a fourth message having an output of a generative model trained based at least in part on the output of the adversarial model.

[0080] If the network service may be a DAM service, the method may further include constructing, by the RAN node, a set of PDUs having an output of the generative model, wherein the second message comprises the set of PDUs.

[0081] According to another aspect, another method is provided. The method includes receiving, by a Radio Access Network (RAN) node, from a network node (NN) a first message having data associated with a network service. The method may further include processing, by the RAN node, the data in accordance with the network service to obtain a processed version of the data. The method may further include transmitting, by the RAN node, a message having the processed version of the data to a second NN.

[0082] The NN may be one of a Core Network (CN) Function (CNF), a second RAN node, and a user equipment (UE). The second NN may be one of a CNF, a second CNF, a second RAN node, a third RAN node, a UE, and a second UE.

[0083] The method can further include retrieving, by the RAN node, data comprising a first set of service data units (SDUs), and processing the data includes processing the first set of SDUs.

[0084] According to another aspect, another method is provided. The method includes receiving, by a receive processing function (PF) in a network node (NN), one or more protocol data units (PDUs) associated with a network service from a transmit PF in a second NN. The method may further include extracting, by the receive PF in the NN, one or more service data units (SDUs) from the PDUs. The method may further include transmitting, by the receive PF in the NN, the one or more SDUs to one of the transmit PF in the NN and an upper layer of the NN.

[0085] The method can further include processing, by a receiving PF at the NN, the one or more SDUs to obtain processed SDUs, the processing being performed according to a data processing operation associated with a quality of service (QoS) requirement. Transmitting the one or more SDUs includes transmitting the processed SDUs.

[0086] The method may further include buffering, by a receiving PF at the NN, the retrieved one or more PDUs.

[0087] The method may further include sequence numbering the one or more SDUs by the receiving PF at the NN. Transmitting the one or more SDUs includes transmitting the one or more SDUs according to the sequence numbering.

[0088] One or more SDUs can be transmitted according to routing information, which is determined by one of the configuration in the receiving PF in the NN, the header of one or more PDUs, and the receiving PF in the NN by generating the routing information.

[0089] The NN may be a Radio Access Network (RAN) node, and the second NN may be one of a User Equipment (UE) and a second (RAN) node.

[0090] The receiving PF at the NN may be configured by one of RRC signaling or signaling messages, and at least one of the one or more PDUs may include a header indicating one or more of the following: a type of service, a sequence number, an indication for determining if further processing is required, an indication for direct forwarding of the PDU, routing information, and a quality of service (QoS) flow identifier (ID) to which the PDU belongs.

[0091] The second NN may be a UE, and the one or more PDUs may be received via a data bearer established between the RAN node and the UE.

[0092] The data bearer may be configured via an RRC message or a signaling message received from a control plane function. The data bearer may be a dedicated data bearer for the UE. The UE may be part of a UE group and the data bearer may be configured for the UE group.

[0093] The data bearer may be mapped to one or more Multicast / Broadcast Service (MBS) Radio Bearers (MRBs). One or more PDUs may be received via one or more MRBs.

[0094] According to another aspect, another method is provided. The method includes receiving, by a transmit processing function (PF) in a network node (NN), one or more SDUs associated with a network service. The method may further include constructing, by the transmit PF in the NN, one or more protocol data units (PDUs) corresponding to the one or more SDUs. The method may further include transmitting, by the transmit PF in the NN, the one or more PDUs to a receive PF in a second NN.

[0095] The method may further include buffering, by a transmitting PF in the NN, the one or more SDUs for further processing. The method may further include processing, by a transmitting PF in the NN, the one or more SDUs to obtain processed SDUs, the processing being performed according to a data processing operation associated with a quality of service (QoS) requirement. The one or more PDUs may include the processed SDUs.

[0096] The method may further include sequence numbering the one or more PDUs by the transmitting PF at the NN. Transmitting the one or more PDUs may include transmitting the one or more PDUs according to the sequence numbers.

[0097] The method may further include adding routing information to a header of the one or more PDUs, where the routing information may be determined by one of a configuration in the transmitting PF in the NN and the transmitting PF in the NN by generating the routing information.

[0098] The NN may be a Radio Access Network (RAN) node. The one or more SDUs may be received from one of a receiving PF at the NN and an upper layer of the NN.

[0099] The transmission PF at the NN may be configured by either RRC signaling or a signaling message.

[0100] At least one of the one or more PDUs has a header that indicates one or more of the following: a type of service, a sequence number, an indication for determining if further processing is required, an indication for direct forwarding of the PDU, routing information, and a quality of service (QoS) flow identifier (ID) to which the PDU belongs.

[0101] The second NN may be a user equipment (UE), and the one or more PDUs may be transmitted over a data bearer established between the RAN node and the UE.

[0102] The data bearer may be configured via an RRC message or a signaling message received from a control plane function. The data bearer may be a dedicated data bearer for the UE. The UE is part of a UE group and the data bearer is configured for the UE group.

[0103] A data bearer is mapped to one or more Multicast / Broadcast Service (MBS) Radio Bearers (MRBs). One or more PDUs can be transmitted over one or more MRBs.

[0104] According to another aspect, another method for providing a network service in a network is provided. The network may include a first network element and a second network element. The method may be performed by the first network element. The method includes obtaining a service data unit (SDU). The method further includes generating a protocol data unit (PDU) including the SDU. The method further includes providing the PDU to the second element. The first element may be one of a user equipment (UE) and a radio access network (RAN) node. The second element may be the other of the UE and the RAN node.

[0105] According to another aspect, an apparatus is provided, the apparatus including modules configured to perform one or more of the methods and systems described herein.

[0106] According to another aspect, an apparatus is provided, the apparatus including: a memory configured to store a program; and a processor configured to execute 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.

[0107] According to another aspect, a computer-readable medium is provided, the computer-readable medium storing program code for execution by a device, the program code being used to implement one or more of the methods and systems described herein.

[0108] According to one aspect, a chip is provided, the chip including a processor and a data interface, wherein the processor uses the data interface to read instructions stored in a memory to perform one or more of the methods and systems described herein.

[0109] Another aspect of the present disclosure provides apparatus and systems configured to implement methods according to the first aspect disclosed herein. For example, wireless stations and access points may be configured with machine-readable memories that include instructions that, when executed by a processor of the device, configure the device to perform one or more of the methods and systems described herein.

[0110] The embodiments have been described above in conjunction with aspects of the invention in which they may be implemented. Those skilled in the art will understand that the embodiments may be implemented with the aspect for which they are described, but may also be implemented with other embodiments of that aspect. Where embodiments are mutually exclusive or incompatible, this will be apparent to those skilled in the art. While some embodiments may be described in relation to one aspect, they may also be applicable to other aspects, as will be apparent to those skilled in the art. [Brief explanation of the drawings]

[0111] Further features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings. [Figure 1] 1 shows the user plane protocol stack between the user equipment (UE) and the user plane function (UPF). [Figure 2] 1 illustrates a user plane protocol stack between a UE and a radio access network (RAN). [Figure 3] 1 illustrates an enhanced UP protocol stack between a UE and a RAN, according to one aspect. [Figure 4] 1 illustrates an XaaS bearer in 6G according to one embodiment. [Figure 5] 1 illustrates 6G data processing according to one embodiment. [Figure 6] 1 illustrates dynamic configuration for different cases according to one aspect. [Figure 7] 1 illustrates a functional diagram of the PF sublayer, according to one aspect. [Figure 8]1 illustrates another functional diagram of the PF sublayer, according to one aspect. [Figure 9] 1 illustrates a data path in the PF sublayer according to one aspect. [Figure 10] 1 illustrates a procedure for XaaS tasks of the PF sublayer involved, according to one embodiment. [Figure 11] 1 illustrates a block diagram of a PF sublayer according to one aspect. [Figure 12] 1 illustrates a data flow according to one aspect. [Figure 13] 1 illustrates a format of a PF PDU according to one embodiment. [Figure 14] 1 shows a table illustrating a description of the Xs field, according to one embodiment. [Figure 15] 1 shows a table illustrating a description of the P / F field, according to one aspect. [Figure 16] 1 illustrates a DL Layer 2 architecture for XaaS and PDU connection services, according to one aspect. [Figure 17] 1 illustrates a model of a PF entity having a transmitter (Tx unit) and a receiver (Rx unit), according to one embodiment. [Figure 18] 1 illustrates another PF entity having a Tx section and an Rx section, according to an embodiment. [Figure 19] 1 illustrates a Service Data Adaptation Protocol (SDAP) Protocol Data Unit (PDU) format with an XaaS Quality of Service Flow Identifier (XQFI) field in the SDAP header, according to one aspect. [Figure 20] 2 illustrates another DL Layer 2 architecture 2060 for PDU connection services, according to an aspect. [Figure 21] 1 illustrates an apparatus capable of performing any or all of the operations of the above-described methods and mechanisms explicitly or implicitly described herein, according to different aspects of the present disclosure.

[0112] It should be noted that throughout the accompanying drawings, like features are identified by like reference numerals. DETAILED DESCRIPTION OF THE INVENTION

[0113] The present disclosure provides systems and methods for RAN protocols for future X-centric service networks. According to one aspect, an enhanced RAN node is provided having one or more processing functions that may enable processing to be performed at the RAN node in addition to existing data forwarding functions. For example, the RAN node may analyze and process data, among other functions, as described in one or more aspects herein, via the one or more processing functions. According to one aspect, an enhanced user plane protocol stack may be provided to support the enhanced RAN node and one or more processing functions therein. According to another aspect, an enhanced bearer may be provided to further support the functionality of the enhanced RAN node.

[0114] According to one aspect, a method is provided. The method includes receiving, by a Radio Access Network (RAN) node, data traffic from a user equipment (UE) associated with a network service and having a Quality of Service Flow Identifier (QFI). The QFI can indicate a processing action for the associated traffic. The method further includes extracting, by the RAN node, a first set of service data units (SDUs) from the data traffic. The method further includes transmitting, by the RAN node, second data traffic to the UE based at least in part on the first set of SDUs. The method can further include constructing, by the RAN node, a set of PDUs having processed versions of the first set of SDUs, the second data traffic comprising the set of PDUs.

[0115] The method may further include processing, by the RAN node, the first set of SDUs according to a processing procedure to obtain processed versions of the first set of SDUs. The method may further include constructing, by the RAN node, a set of PDUs having the processed versions of the first set of SDUs, wherein the second data traffic comprises the set of PDUs. The method may enhance functionality of the RAN node, thereby improving the availability and delivery of 6G services.

[0116] In addition to traditional connection-oriented communication services, 6G will include new types of services for network-native data processing, such as data analysis, artificial intelligence (AI) training, AI inference, data privacy protection, data storage, data cleaning, data normalization, useless data filtering, and data feature engineering.

[0117] X-centric networks may be proposed for 6G to provide X as a service (XaaS). In some aspects, XaaS may be Data Analytics and Management (DAM) as a service, NET4AI as a service, NET4Data data as a service, NET4meta as a service, etc. In some aspects, these services may be provided by one or more service providers. The one or more service providers may include one or more of an operator, a vendor, a network function, a network equipment, and a third party.

[0118] In one aspect, a DAM service may include collecting data from data sources (by one or more service providers) and providing the collected data in a privacy-preserving form (e.g., de-identified data, anonymized data, or the like) to a data consumer, who may use the collected data to perform tasks such as data analysis, AI training, and AI inference.

[0119] In some embodiments, NET4AI services may include providing connectivity and intelligent computing services, e.g., for AI training and AI inference. In some embodiments, NET4Data services may include providing data storage services and performing data access control. In some embodiments, two or more of these services may be combined and offered to a customer. In a composite service, one or more service providers may collaborate with each other in offering the composite service.

[0120] Each XaaS may involve one or more functions in providing the service. In some aspects, each XaaS may involve a service controller (XC). The XaaS XC (or XCs) may control and manage the service. For example, the XC may control and configure the XaaS processing function (PF) to perform the specific tasks involved in the XaaS.

[0121] In some embodiments, each XaaS may further involve one or more PFs. The XaaS PF (or PFs) can execute one or more XaaS tasks under the control of the XC. Some examples of XaaS tasks may include data preprocessing and data privacy protection tasks in the DAM service, AI training and AI inference tasks in the NET4AI service, and data storage and access control tasks in the NET4Data service.

[0122] In some aspects, each XaaS may be provided by an XaaS module, and each module may be associated with an XC and one or more PFs.

[0123] In some aspects, one or more XaaS functions (e.g., XC, PF) can be deployed in one or more of a radio access network (RAN), a core network (CN), and a user equipment (UE) side. For example, the XC can be located in a network control plane, and the PF can be deployed in a network user plane or data plane. Some aspects of the present disclosure may provide for the deployment of a PF in a network, for example, on the RAN and UE side.

[0124] 1 illustrates a user plane protocol stack between a user equipment (UE) and a user plane function (UPF). As shown, the protocol stack at a UE 102 may include an application layer 104, a PDU layer 106, and a 5G access network (AN) protocol layer 108. The UE 102 may interface with a 5G-AN node 110 as shown. The protocol stack at the 5G-AN node 110 may include a 5G-AN protocol layer 112, a GTP-U layer 114, a UDP / IP layer 116, an L2 layer 117, and an L1 layer 118.

[0125] The 5G-AN node 110 may connect to the UPF 120 via an N3 interface 140. The protocol stack of the UPF 120 interfacing with the 5G-AN node 110 may include a GTP-U layer 121, a UDP / IP layer 122, an L2 layer 123, and an L1 layer 124. The UPF 120 may connect to the UPF PDU session anchor 130 using an N9 interface 142. The protocol stack of the UPF 120 interfacing with the UPF PDU session anchor 130 may include a GTP-U layer 125, a UDP / IP layer 126, an L2 layer 127, and an L1 layer 128, as shown. The UPF PDU session anchor 130 may connect to the data network via an N6 interface 144. The protocol stack in the UPF PDU session anchor 130 may include a PDU layer 131 , a GTP-U layer 132 , a UDP / IP layer 133 , an L2 layer 134 , and an L1 layer 135 .

[0126] Referring to FIG. 1, considering an example of downlink data traffic (which may be similar to uplink data traffic originating from an application layer on the UE side), the data traffic flow and data mapping between different protocol layers in a traditional connection-oriented communication network may be as follows:

[0127] Application data (e.g., service data flow (SDF)) may be encapsulated into protocol data unit (PDU) layer data or packets (e.g., TCP or IP packets) and transmitted to one or more core network (CN) functions (e.g., user plane functions (UPF)).

[0128] The one or more CN functions (e.g., UPF) may classify PDU layer data for quality of service (QoS) flow marking (e.g., based on packet detection rules) and further map QoS flows to GTP-U tunnels. The one or more CN functions may map PDU layer data to GTP-U layer data. If PDU session resources are set up under the control of one or more of the AMF, SMF, and RAN, the mapping between GTP-U tunnels and PDU sessions / QoS flows on the N3 interface may be aligned between the UPFs 130 and 120 and the RAN (e.g., 5G-AN node 110).

[0129] The RAN may map a QoS flow received via a specific GTU-U tunnel to an access network resource (e.g., a DRB). The UE 102 may then map the QoS flow to a DRB based on its local configuration or signaling information from the RAN or CN (e.g., mapping information between QoS flows and DRBs). For example, the UE 102 may map downlink data of a specific DRB to a PDU session (QoS flow) and submit it to the PDU layer and application layer. In some circumstances, the UE 102 may map uplink application data and PDU layer data to a PDU session / QoS flow, which may then be mapped to a specific DRB for transmission to the peer RAN.

[0130] In order for the RAN (e.g., 5G-AN node 110) to perform mapping between QoS flows and DRBs, referring to Figure 2, a DRB may be configured to include a Service Data Adaptation Protocol (SDAP) sublayer, a Packet Data Convergence Protocol (PDCP) sublayer, a Radio Link Control (RLC) sublayer, a Medium Access Control (MAC) sublayer, and a Physical Layer (PHY). One PDU session may be configured to include one SDAP entity. One DRB may be configured to include one PDCP entity. Data of a PDU session including one or more QoS flows may be mapped to one or more DRBs by the SDAP sublayer.

[0131] 2 illustrates a user plane protocol stack between a UE and a radio access network (RAN). As shown, the 5G-AN protocol layer 108 in the UE 102 may include an SDAP sublayer 202, a PDCP sublayer 203, an RLC sublayer 204, a MAC sublayer 205, and a PHY layer 206. The 5G-AN protocol layer 112 in the RAN may include an SDAP sublayer 212, a PDCP sublayer 213, an RLC sublayer 214, a MAC sublayer 215, and a PHY layer 216.

[0132] In downlink transmission, a UE SDAP entity may receive SDAP SDUs from higher layers and submit SDAP PDUs to its peer SDAP entity via lower layers. In uplink transmission, a UE SDAP entity in a UE may deliver SDAP SDUs to higher layers and receive SDAP PDUs from its peer SDAP entity via lower layers.

[0133] As will be understood by those skilled in the art, the procedures or operations described with reference to Figures 1 and 2 are designed for the purpose of data transfer. In these procedures, data is processed transparently at each layer without analyzing and understanding the payload (except that the UE application layer may analyze the data). For example, a service data unit (SDU) can be processed (e.g., encrypted, segmented, ordered) by each layer without analyzing and understanding the SDU payload. The processed data (e.g., PDU) can then be transmitted to the next layer based on a data mapping scheme.

[0134] Data processing (e.g., encryption, segmentation, ordering) and data mapping procedures may be understood as connection-oriented. However, in 6G, parsing and processing of data within the network (e.g., by the RAN) may be desirable instead of within the application layer. Such functionality (e.g., data parsing and processing) may be required when the network (e.g., the RAN) natively provides XaaS.

[0135] Additionally, analyzing and processing data through XaaS functionality may be desirable in procedures related to, for example, AI training, AI inference, data privacy protection, etc. However, one or more sublayers and layers in current 5G RANs shown in Figures 1 and 2 may lack the functionality required to support and perform one or more tasks in XaaS.

[0136] It can also be said that in 5G, the RAN is not a source or destination of user plane (UP) data. With respect to data source, the RAN does not generate UP data; rather, in 5G RAN, UP data is received from either the CN (e.g., UPF) or the UE. With respect to data destination, upon receiving UP data, the RAN does not intercept, retain, and use the received UP data; rather, the RAN forwards the received UP data to either the CN (in the case of uplink) or the UE (in the case of downlink) as soon as possible.

[0137] 1 and 2, each sublayer or layer above the UP in the current 5G RAN may not be the source or destination of UP data. Upon receiving UP data, each sublayer or layer above the UP in the current 5G RAN may forward the received UP data to its lower or upper layer (without intercepting, retaining, and using the received UP data).

[0138] However, in 6G, the RAN can be a source or destination of UP data. In some aspects, the RAN itself can generate entirely new data (e.g., the RAN as a sensor can sense and generate sensing data, and the RAN can generate a trained AI model by transforming training data). In some aspects, the RAN can be a destination for uplink data received from a UE. For example, uplink data (e.g., intermediate AI parameters) received from a UE can be aggregated, terminated, and used by the RAN (e.g., for the RAN to obtain a final AI model that can be used by the RAN to optimize the network) instead of being forwarded to the CN.

[0139] As one skilled in the art can appreciate, current RAN protocol stacks may not support new 6G demands, such as XaaS. Aspects of the present disclosure may provide improved RAN functionality other than data forwarding. According to one aspect, the RAN may support the provision of XaaS, e.g., the RAN may analyze and process data, and the RAN may act as a source or destination of 6G data.

[0140] Over the air link for current 5G air interfaces, there are two types of radio bearers: signaling radio bearers (SRBs) that carry radio resource control (RRC) signaling on the control plane, and data radio bearers (DRBs) that carry data traffic on user plans. However, these radio bearers may be limited to transporting PDU layer data, so it can be said that SRBs and DRBs do not carry XaaS data. According to one aspect, an improved bearer is provided that can support XaaS data (e.g., AI data, DAM data, private data, blockchain data, etc.).

[0141] According to one aspect, a data PF for XaaS on the RAN side may be provided. Figure 3 illustrates one embodiment of an extended UP protocol stack between a UE and a RAN in accordance with one aspect of the present disclosure. According to one aspect, the PF in the RAN may be deployed as a RAN radio Layer 2 protocol sublayer, e.g., PF sublayer 314, between the SDAP sublayer 313 and the PDCP sublayer 315, as shown.

[0142] In some aspects, the protocol stack in the UE 300 may include an application layer 301, a PDU layer 302, an SDAP sublayer 303, a PF sublayer 304, a PDCP sublayer 305, an RLC sublayer 306, a MAC sublayer 307, and a PHY layer 308. In some aspects, the protocol stack in the RAN 310 may include an SDAP sublayer 313, a PF sublayer 314, a PDCP sublayer 315, an RLC sublayer 316, a MAC sublayer 317, and a PHY layer 318.

[0143] In some aspects, based on the PF sublayers 304 and 314, one or more enhanced bearers supporting 6G services may be provided.

[0144] 4 illustrates an embodiment of an XaaS bearer in 6G in accordance with an aspect of the present disclosure. In one aspect, protocol layers in the RAN 310 and the UE 300 may be extended to support an XaaS data bearer 450 and an XaaS signaling bearer 452 in 6G. To support the XaaS data bearer 450, the protocol stacks in the RAN 310 and the UE 300 may each include a PF sublayer 314 and 304, respectively, as described herein. To support the XaaS signaling bearer 452, the protocol stacks in the RAN 310 and the UE 300 may each include an XC sublayer 414 and 404, respectively.

[0145] Data transfer in 5G may involve an SRB 440 and a DRB 442 between the RAN 310 and the UE 300, as shown.

[0146] Data transfer services in 5G may also involve PDU connection services, such as may be defined and provided by a 5G network, which may refer to services that provide for the exchange of PDUs between a UE and a data network.

[0147] Data transfer services in 5G may further involve one or more PDU sessions, such as PDU session 446, as may be defined in the 5G network. A PDU session may refer to an association between a UE and a data network that provides a PDU connection service.

[0148] According to one aspect, 6G may involve XaaS, which may be a service that provides data processing between a UE and a CN XaaS function or data network, for example a PF deployed in the CN.

[0149] In some aspects, XaaS may be a service that provides data processing between an XaaS customer and an XaaS network function, such as between a UE and a CN XaaS function, between a third-party server and a CN XaaS function, between a UE and a DN, between a DN and a CN PF, and between a server and a RAN node.

[0150] In some aspects, XaaS in 6G may further involve an XaaS session 420. An XaaS session may refer to an association between an XaaS network function providing the XaaS and an XaaS customer. In some aspects, the XaaS session 420 may be an association between the UE 300 and a CN XaaS function (e.g., a PF deployed in the CN, or a data network) providing the XaaS. In some aspects, the XaaS session 420 may be established between the UE and a CN PF unit or between the UE and a DN.

[0151] In some aspects, 6G XaaS may be implemented on top of 5G PDU connectivity services. In some aspects, establishing an XaaS session may include establishing related resources (e.g., connectivity resources, computing resources, and storage resources) used to complete an XaaS task. In some aspects, an XaaS session may be considered an improved PDU session for purposes of data processing in addition to data transfer.

[0152] In some aspects, throughout an XaaS session, data may be flexibly processed in different nodes, such as in the CN PF unit, in the RAN PF sublayer 314, and in the UE PF sublayer 304. The number of participating nodes (e.g., RAN, UE, and CN functions) in an XaaS session may be unlimited. Thus, an XaaS session may traverse several RAN nodes, which may cooperate to process the XaaS data sequentially or in parallel.

[0153] In some aspects, XaaS in 6G may further involve an XaaS bearer (510 in FIG. 5 , which may include an XaaS data bearer 450 and an XaaS signaling bearer 452). An XaaS bearer may refer to a service provided by the RAN Radio Layer 2, including the PF sublayer and the XC sublayer, for both data transfer and data processing between the UE 300 and the RAN 310. In some aspects, an XaaS bearer may refer to a channel provided by the RAN Radio Layer 2, including the PF and XC sublayers, to higher layers for both data transfer and data processing. Thus, the PF and XC sublayers may provide services for data transfer and data processing between the UE and the RAN to higher layers via the XaaS bearer. A service access point between the PF sublayer and higher layers (or between the XC sublayer and higher layers) may be the XaaS bearer.

[0154] In some aspects, an XaaS bearer may include multiple XaaS data bearers (XDBs) 450 for user plane data. In some aspects, each XDB may be comprised of a PF sublayer 314 in the RAN and a PF sublayer 304 in the UE, a PDCP sublayer 315 in the RAN and a PDCP sublayer 305 in the UE, an RLC sublayer 316 in the RAN and an RLC sublayer 306 in the UE, a MAC sublayer 317 in the RAN and a MAC sublayer 307 in the UE, and a PHY layer 318 in the RAN and a PHY layer 308 in the UE.

[0155] In some aspects, an XaaS bearer may include multiple XaaS signaling bearers (XSBs) 452 for control plane data. In some aspects, each XSB 452 may be comprised of an XC sublayer at RAN 414 and an XC sublayer at UE 404 (rather than a PF sublayer), a PDCP sublayer at RAN 415 and a PDCP sublayer at UE 405, an RLC sublayer at RAN 416 and an RLC sublayer at UE 406, a MAC sublayer at RAN 417 and a MAC sublayer at UE 407, and a PHY layer at RAN 418 and a PHY layer at UE 408, as shown (rather than a PF sublayer). In some aspects, the XC sublayer at RAN 414 and the XC sublayer at UE 404 may reside above the PDCP sublayer at RAN 415 and the PDCP sublayer at UE 405 to transport signaling messages between the RAN and the UE, e.g., to configure and control the PF sublayer.

[0156] In some aspects, XaaS in 6G may further involve XaaS QoS flows. According to one aspect, XaaS QoS flows may be the finest granularity of QoS differentiation in an XaaS session 420. In some aspects, traffic mapped to the same XaaS QoS flow may receive the same data forwarding and data processing treatments.

[0157] Providing different XaaS QoS data processing and data forwarding treatments may require separate XaaS QoS flows. An XaaS QoS Flow ID (XQFI) may be used to identify an XaaS QoS flow. The XQFI may be a scalar ID used as a reference for specific XaaS QoS characteristics. Traffic (e.g., user plane traffic) with the same XQFI in an XaaS session may receive the same data processing and data forwarding treatments. Data processing treatments may refer to computation precision, computation latency, privacy level, storage duration, data processing policy, data cleaning policy, data normalization policy, etc. Data forwarding treatments may include scheduling policies, queue management policies, link layer protocol configurations (e.g., MAC / RLC configurations), admission thresholds, etc. In some aspects, the XQFI may be carried within an encapsulation header of a CN, UE, or RAN packet (e.g., a GTP-U packet header, an SDAP packet header, a Segment Routing over IPv6 (SRv6) packet header, or a Quick UDP Internet Connections (QUIC) packet header).

[0158] In some aspects, XaaS in 6G may further involve XaaS QoS parameters, which may include both parameters for data forwarding and data processing. In some aspects, XaaS QoS parameters may be configured per node (e.g., per UE), per network function, per XaaS session, per XaaS QoS flow, or per XaaS bearer.

[0159] In some aspects, the data forwarding processing parameters may include one or more of a data forwarding resource scheduling policy, a data queue management policy, a data forwarding priority level, a link layer protocol configuration (e.g., MAC / RLC configuration), an admission threshold, a data loss rate, a data forwarding latency, a data forwarding security method, a security level, etc. The data forwarding processing parameters may relate to data forwarding in the data plane, e.g., in the RAN L2 / L1 layer and in the CN UPF.

[0160] In some embodiments, the data processing parameters may include one or more of a data processing scheduling policy, a calculation accuracy, a calculation latency, an AI model type, a privacy protection method, a privacy level, a data storage period, a data processing policy, a data cleaning policy, a data normalization policy, a data quality level, a data processing priority, and the like.

[0161] In some aspects, data transfer and data processing parameters may be mutually tuned and dynamically adapted, e.g., under the control of an XC or other control plane function. For example, data transfer latency and computation latency may be mutually tuned to guarantee a total latency threshold for an XaaS task, e.g., decreasing data transfer latency while increasing computation latency for a trade-off.

[0162] In some embodiments, one or more data transfer process parameters may be correlated with one or more data processing process parameters. For example, ensuring a data transfer process parameter (e.g., data loss rate) may be a prerequisite for ensuring a data processing process parameter (e.g., calculation accuracy).

[0163] In some aspects, one XaaS session may be configured with one SDAP entity. Each XaaS bearer may be configured with one PF entity. Each DRB may be associated with one PDCP entity. In some aspects, the SDAP sublayer may perform mapping between data of one or more XaaS QoS flows and one or more XaaS bearers. One or more XaaS QoS flows may be mapped to one XaaS bearer. One or more XaaS bearers may further be mapped to one or more DRBs.

[0164] In some aspects, if the traffic granularity of the XaaS QoS flow is the same as the traffic granularity of the XaaS bearer, mapping between the XaaS QoS flow and the XaaS bearer may not be required, and therefore, an SDAP entity may not be configured.

[0165] 5 illustrates an embodiment of 6G data processing in accordance with an aspect of the present disclosure. In a traditional connection-oriented service, such as service 502, a PDU session is established between the UE and the DN, and UL or DL ​​data is transferred between the UE and the CN DN without forking (e.g., without changing the traffic direction). Thus, in a traditional connection-oriented service, a RAN node can act as a conduit to forward received data (DL or UL) from the CN or UE to a lower or higher layer without intercepting or setting aside the data. UL or DL ​​data traffic received by the RAN is transferred unidirectionally. For example, the RAN cannot directly send UL UP data received from the UE back to the UE, or directly send DL UP data received from the CN DN back to the CN DN.

[0166] According to one aspect, in 6G XaaS, UL or DL ​​data traffic received by the RAN 310 can be forwarded bidirectionally or multidirectionally, in part, by one or more of the PF sublayer, the XaaS bearer 510, and the XaaS session 420. For example, the RAN 310 can send UL UP data received from the UE 506 (which may be similar to the UE 300) back to the UE 506 or another UE 508 (which may also be similar to the UE 300) after data processing. The RAN 310 can also send DL UP data received from a CN (e.g., a CN PF or a CN DN) back to the CN after data processing. As another example, the RAN 310 can transmit UL UP data received from a UE to another RAN via the PF sublayer after data processing. The RAN 310 can also transmit DL UP data received from a CN function (e.g., a CN PF or a CN DN) to another CN function via the PF sublayer after data processing.

[0167] According to one aspect, throughout an XaaS session, data may be flexibly processed within different nodes, such as within the PF sublayer of the RAN, within the PF sublayer of the UE, and within the CN PF unit. The number of nodes (e.g., RAN, UE, and CN functions) participating in an XaaS session may be unlimited. For example, an XaaS session may go through one or more RAN nodes, and the RAN nodes may cooperate to process the XaaS data sequentially or in parallel. In some aspects, the participating order and routines for different nodes may be flexible.

[0168] Also, unlike deploying a PF outside the RAN, such as in an MEC or cloud, deploying a PF in the RAN Radio Layer 2 can enable the RAN to recognize and adjust XaaS performance. For example, the RAN may recognize and adjust XaaS performance based on one or more of the XaaS requirements (e.g., data processing and forwarding requirements), XaaS resource conditions (e.g., data processing resources (e.g., computational load), and data forwarding radio resources (e.g., radio CSI conditions) considered jointly.

[0169] 6 illustrates an embodiment of dynamic configuration for different cases according to an aspect of the present disclosure. In some aspects, for example, in case 602, the RAN is only required to perform data transfer services and may not have XaaS capabilities, or the RAN does not need to be involved in XaaS. In such a case, data does not need to be processed in the RAN, and therefore, a PF sublayer may not be configured in the RAN, and the RAN may operate according to 5G RAN capabilities. As shown, in case 602, a PDU session tunnel may be established between the CN and the RAN, and a DRB may be established between the RAN and the UE.

[0170] In some aspects, for example, in case 604, the RAN may have XaaS capability, and only the RAN and UE (not the CN) may be involved in XaaS. In such a case, the PF sublayer 314 may be configured in the RAN, but the RAN SDAP sublayer and the XaaS session tunnel between the RAN and the CN may not be configured. Furthermore, the PF sublayer 304 may be configured in the UE as shown. In addition, an XaaS bearer may be established between the RAN and the UE.

[0171] In some aspects, for example, in case 606, the RAN may have XaaS capability, and XaaS may be processed only in the RAN and the CN. In such a case, the PF sublayer may be configured in the RAN. However, the SDAP sublayer, the wireless L2 sublayer, and the PHY layer may not be configured in the RAN.

[0172] In some aspects of case 606, an SDAP sublayer may be configured in the RAN (wherein an SDAP PDU in the SDAP layer may be configured to include a data field but not a packet header (e.g., not including a DL SDAP header or a UL SDAP header)), while simultaneously configuring a wireless L2 sublayer and a PHY layer in the RAN. Furthermore, a PF may be configured in the CN. In addition, to support the RAN XaaS capability, an XaaS session tunnel may be established between the RAN and the CN.

[0173] In some aspects, for example, in case 608, XaaS may be processed sequentially by the CN, the RAN, and the UE. In such a case, sublayers including an SDAP sublayer, a PF sublayer, a PDCP sublayer, an RLC sublayer, a MAC sublayer, and a PHY layer may be configured in the RAN and the UE. Furthermore, an XaaS session tunnel between the CN and the RAN may be configured. Similarly, an XaaS bearer may be established between the RAN and the UE as shown.

[0174] According to one aspect, data mapping between upper layers (e.g., PDU layer, GTP-U layer), SDAP sublayer, PF sublayer, and PDCP sublayer may be provided. According to another aspect, a functional diagram of the PF sublayer may be provided. According to another aspect, a block diagram of the PF sublayer may be provided. According to another aspect, a format and parameters of a PF sublayer protocol data unit (PDU) may be provided. According to another aspect, a data mapping scheme for different cases (e.g., when a UE or a group of UEs and a RAN-PF are involved in XaaS tasks) may be provided. In some aspects, an XaaS bearer may be configured per UE or per UE group.

[0175] 7 illustrates an embodiment of a functional diagram of a PF sublayer in accordance with an aspect of the present disclosure. The PF sublayer 700 may include one or more PF entities as shown. In some aspects, one or more PF entities (e.g., a transmit PF (Tx-PF) entity 702 or a receive PF (Rx-PF) entity 712) may be deployed or configured within a node (e.g., within a UE, a CN side, and a RAN side).

[0176] In one aspect, if the Tx-PF entity 702 is deployed in the UE, the Rx-PF entity 712 may be deployed in the RAN. Similarly, if the Tx-PF entity 702 is deployed in the RAN, the Rx-PF entity 712 may be deployed in the UE.

[0177] 7 may be based on a radio interface protocol architecture. As one skilled in the art can appreciate, FIG. 7 is merely an illustration of a PF sublayer according to one aspect and is therefore not a limitation on how the PF sublayer may be implemented. Other reasonable implementations of the PF sublayer 700 may be known by one skilled in the art and are part of the scope of one or more aspects of the present disclosure.

[0178] In some aspects, if the transmitting PF entity is deployed in a UE, the receiving PF entity may be deployed in a RAN. Similarly, if the transmitting PF entity is deployed in a RAN node, the receiving PF entity may be deployed in a UE.

[0179] In one aspect, PF entities 702 and 712 may be located within the PF sublayer for XaaS. In some aspects, several PF entities may be configured for a UE or RAN node. In some aspects, in 6G, a PF entity may be configured for each XaaS bearer on the airlink.

[0180] In some aspects, a PF entity may receive (or deliver) PF SDUs from (or to) a higher layer or another PF entity and submit (or receive) PF PDUs to (or from) its peer PF entity via a lower layer.

[0181] In some aspects, the transmitting PF entity 702 may receive PF SDUs from higher layers and submit or transmit PF PDUs to its peer PF entity via lower layers. In some aspects, the transmitting PF entity 702 may receive PF SDUs from another PF entity (e.g., from a receiving PF entity residing in the same node) and submit or transmit PF PDUs to its peer PF entity via lower layers.

[0182] In some aspects, the receiving PF entity 712 may deliver PF SDUs to a higher layer and receive PF PDUs from its peer PF entity via a lower layer. In some aspects, the receiving PF entity 712 may deliver PF SDUs to another PF entity (e.g., a transmitting PF entity residing in the same node) and receive PF PDUs from its peer PF entity via a lower layer.

[0183] As one skilled in the art will appreciate, in a 5G data forwarding approach, each sublayer of the RAN may only receive data from a higher or lower layer and forward the received data to a lower or higher layer. Thus, in 5G, the RAN may act as an intermediate conduit for forwarding data.

[0184] According to one aspect, in 6G XaaS, the RAN (e.g., PF sublayer) can be a data destination and a data source. In some aspects, a PF entity can receive (or distribute) data from (or to) a higher or lower layer. In some aspects, a PF entity can also receive (or distribute) data from (or to) another PF entity within the same PF sublayer and the same node. In some aspects, a PF entity can enable XaaS data traffic to originate, terminate, or both at the RAN in the PF sublayer. For example, 6G sensing data can originate at the RAN.

[0185] In some aspects, a PF entity may function or operate as one or both of a transmitting PF (PF-Tx) entity 702 and a receiving PF (PF-Rx) entity 712. Thus, one or more PF entities may be deployed on the same node, and each PF entity may act as a PF-TX entity or a PF-RX entity.

[0186] According to one aspect, the PF sublayer (via one or more PF entities) may include data buffer components 704 and 714 for supporting data buffering operations (e.g., user plane data). In some aspects, the PF sublayer may include data processing components 705 and 715 for supporting data processing operations (e.g., user plane data). Data processing operations may include operations involving AI and data privacy protection, among others. In some aspects, the PF sublayer may include data forwarding components 706 and 716 for supporting data forwarding operations (e.g., user plane data). Data forwarding operations may include one or more of adding or removing PF headers, maintaining PF sequence numbers (SNs), e.g., sequence numbering, and reordering and in-order delivery. In some aspects, the PF sublayer may include routing components 707 and 717 for supporting routing operations.

[0187] Although the components (eg, data buffers, data processing, routing, and data forwarding) are shown as separate from one another, in some aspects one component may perform the functions of two or more components.

[0188] In some aspects, a corresponding PF entity may reside on the same node where a PF entity may reside. For example, an Rx-PF entity 701 may reside in the same node where a Tx-PF entity 702 may reside. Similarly, a Tx-PF entity 711 may reside in the same node where an Rx-PF entity 712 may reside. Thus, according to one aspect, the Tx-PF entity 702 may receive data from one or more higher layers (e.g., the CN, the SDAP sublayer when the PF sublayer is deployed below the SDAP sublayer) and may also receive data from the same layer (e.g., the Rx-PF entity 701), as further shown in FIG. 9.

[0189] According to one aspect, the PF entities may buffer data via data buffer components 704 and 714 to achieve "big data" (as one skilled in the art would understand). The resulting "big data" may then be used for data processing 705 and 715. For example, the Tx-PF entity 702 may buffer PF SDUs received from a higher layer or another PF entity (e.g., from the Rx-PF entity 701 residing in the same node). Similarly, the Rx-PF entity 733 may buffer PF PDUs received via a lower layer from its peer transmitting PF entity.

[0190] As an example, in the NET4Data service, DAM service, and NET4AI service, the Rx-PF entity 712 may buffer data from one or more Rx-PF entities to achieve "big data" data processing purposes. Data processing may include AI training, data privacy protection (e.g., privacy protection using K-anonymization). Similarly, the Tx-PF entity may buffer data received from a higher layer or another PF entity (e.g., from the Rx-PF entity 701 residing in the same node) to achieve "big data" for subsequent data processing.

[0191] According to one aspect, data processing may include the PF entity analyzing and processing the data using one or more methods of AI training, AI inference, data analysis, privacy protection, and data preprocessing (e.g., data cleaning, data normalization, useless data filtering, and data feature engineering).

[0192] According to one aspect, on the transmit side, when a PF entity (e.g., Tx-PF entity 702) receives one or more PF SDUs from a higher layer or another PF entity (e.g., from Rx-PF entity 701 residing in the same node), the PF entity may construct a corresponding PF PDU and submit it to a lower layer.

[0193] According to one aspect, constructing the PF PDU may include parsing and processing raw data encapsulated in the payload of one or more PF SDUs using one or more methods (e.g., AI training, AI inference, data privacy protection). This construction of the PF PDU differs from traditional 5G connection-oriented networks in which the PDUs of each RAN sublayer are constructed without parsing the payload of the SDUs.

[0194] In some aspects, after receiving the PF SDU, one or more parameters associated with data processing of the PF SDU may be triggered by the PF entity. The one or more parameters may relate to QoS requirements for the XaaS bearer and may optionally be pre-configured in the PF entity by the XC. The one or more parameters may include a time count threshold within which the PF PDU may be constructed, a precision level according to which the PF SDU may be processed, and a privacy level according to which the PF PDU may be guaranteed.

[0195] According to one aspect, on the receiving side, when a PF entity (e.g., Rx-PF entity 712) receives a PF PDU from a lower layer, the PF entity may extract the corresponding PF SDU, and in some aspects, the PF entity may deliver the PF SDU to a higher layer or to another PF entity (e.g., to a transmitting PF entity 711 that resides in the same node (e.g., RAN) of the receiving PF entity).

[0196] In some aspects, after retrieving corresponding PF SDUs from lower layers, the PF entity may parse and process the retrieved one or more PF SDUs, and may deliver the processed PF SDUs to a higher layer or to another PF entity (e.g., to a transmitting PF entity 711 residing in the same node (e.g., RAN) as the receiving PF entity).

[0197] In some aspects, after the PF SDUs are extracted, the raw data encapsulated in one or more of the extracted PF SDUs may be analyzed and processed using specific methods (e.g., AI training, AI inference, data privacy protection). As one skilled in the art can appreciate, the analysis and processing of the PF SDUs may differ from traditional 5G connection-oriented networks in which the extracted SDUs are directly forwarded without analysis and processing.

[0198] As described herein, the PF SDU or the processed PF SDU may be forwarded by the Rx-PF entity 712 to the Tx-PF entity 711, which resides in the same node (e.g., RAN) as the receiving PF entity. In some aspects, the transmitting PF entity 711 may forward the PF SDU or the processed PF SDU to a receiving PF entity that resides in a peer node (e.g., one or more UEs or another RAN). These operations performed by the Rx-PF entity 712 and the transmitting PF entity 711 may differ from traditional 5G connection-oriented networks in which the extracted SDUs are forwarded to higher layers. The PF entity (Rx-PF entity and Tx-PF entity) operations described herein may be applicable to a scenario in which XaaS tasks are performed between the UE and the RAN, the XaaS tasks are terminated at the RAN, and the CN is not involved.

[0199] In some aspects, after receiving a PF PDU, one or more parameters associated with data processing of the PF PDU may be triggered by the PF entity. The one or more parameters may be related to XaaS bearer QoS and may optionally be pre-configured in the PF entity by the XC. The one or more parameters may include a time count threshold within which the PF PDU should be processed, a precision level according to which the retrieved PF SDU may be processed, and a privacy level according to which the processed PF SDU may be guaranteed.

[0200] As an example, in the NET4AI service, a PF entity can analyze the payload of a received SDU and use it to train an AI model. For example, a Tx-PF entity on the RAN side and a Rx-PF entity on the UE side can cooperate with each other to train the AI ​​model.

[0201] As another example, in a DAM service, a PF entity can process data (which may contain or indicate identifying information) to protect data privacy. For example, the PF entity can process the payload of an SDU with one or more operations, such as obfuscation-based, encryption-based, hardware-based, or AI-based privacy protection methods, to remove or hide identifying information or to anonymize the data.

[0202] In some aspects, data privacy protection may be performed in either the Tx-PF entity or the Rx-PF entity, or both. The PF entity may also process useless and redundant data that is not directly usable, and may perform, for example, data cleaning, data normalization, useless data filtering, and data feature engineering.

[0203] As another example, in a NET4Data or DAM service, a PF entity may receive sensing data from a sensor and buffer the received sensing data in local storage, for example, for further use of the sensing data.

[0204] According to one aspect, the PF sublayer may support data forwarding operations performed by data forwarding components 706 and 716 via one or more PF entities. In some aspects, functions related to forwarding of data may include sequence numbering and adding or removing PF headers.

[0205] In some aspects, upon receiving a PF SDU from a higher layer or another PF entity (e.g., from the Rx-PF entity 701 residing in the same node), the Tx-PF entity 702 may store the received PF SDU in a receive buffer. In some aspects, the Tx-PF entity may process the received PF SDU. In some aspects, the Tx-PF entity may further construct a corresponding PF PDU. In some aspects, the Tx-PF entity may further perform sequence numbering to set the PF SN. In some aspects, the Tx-PF entity may further submit the PF PDU sequentially to a lower layer. The PF PDU may be used to carry one or more of a PF header and a payload that encapsulates user plane data (i.e., the received PF SDU or the processed PF SDU). In some aspects, the PF SN may be included in the PF header.

[0206] According to some aspects, upon receiving a PF PDU from a lower layer, the Rx-PF entity 712 may remove the PF header and extract the PF SDU. In some aspects, the Rx-PF entity 712 may further store the resulting PF SDU in a receive buffer. The Rx-PF entity 712 may further process the resulting PF SDU and deliver the resulting PF SDU or the processed PF SDU sequentially to a higher layer or another PF entity (e.g., to the Tx-PF entity 711 residing in the same node).

[0207] In some aspects, the Tx-PF entity 702 may add packet routing information to the header of the PF PDU. In some aspects, the Rx-PF entity 712 may retain the routing information in the header of the PF SDU to allow a routing module to decide on a routing action, for example, to decide to submit the packet to a higher layer or another Tx-PF entity.

[0208] According to one aspect, the PF sublayer may further support routing 710 via one or more PF entities. In some aspects, the Tx-PF entity 702 may add routing information to PF sublayer packets (e.g., to the header of the PF PDU) to help the Rx-PF entity of the peer node decide on a routing action, i.e., whether the processed data (e.g., the original extracted SDU or the processed SDU) should be submitted to a higher layer or to another PF entity.

[0209] According to one aspect, routing information can be configured to the Tx-PF entity by the control plane (eg, by the XC controller).

[0210] In some aspects, the routing information can be generated by the Tx-PF entity 702 itself based on the processed results (e.g., generated by the data processing component 705 of the Tx-PF entity). For example, if the processed results do not reach required data processing parameters (e.g., the accuracy level or privacy level of an AI model, or the AI ​​model does not converge (e.g., in federated learning or generative adversarial network training)), the Tx-PF entity 702 may require the cooperation of a peer node to continue data processing for one or more additional rounds. Thus, the Tx-PF entity 702 can generate the routing information (e.g., the data processing component 705 of the Tx-PF entity 702 can generate the routing information) and attach the routing information to the PF sublayer packet (e.g., to the header of the PF PDU) to notify or indicate to the peer node that continued data processing is required at the peer node and that the processed results should be submitted to the PF sublayer and sent back to the transmitting PF entity rather than submitted to an upper layer.

[0211] In some aspects, the Rx-PF entity 712 may determine a routing action based on the routing information. The Rx-PF entity 712 may determine whether the processed data (e.g., the original extracted SDU or the processed SDU) should be submitted to a higher layer or to another PF entity (e.g., the transmitting PF entity 711 residing in the same node).

[0212] According to one aspect, the routing information can be configured by the control plane (e.g., by the XC controller) at the Rx-PF entity 712. In some aspects, the routing information can be included in the PF sublayer packet (e.g., in the header of the PF PDU) via the peer Tx-PF entity adding the routing information therein.

[0213] In some aspects, the routing information may be generated by the Rx-PF entity 712 itself based on the processed results (e.g., generated by the data processing component 715 of the Rx-PF entity). In some aspects, if the processed results do not reach the required data processing parameters (e.g., the accuracy level or privacy level of the AI ​​model, or the AI ​​model has not yet converged (e.g., in federated learning or generative adversarial network training)), the Rx-PF entity 712 may require the cooperation of peer nodes to continue data processing for several rounds. Thus, the Rx-PF entity 712 may generate routing information (via the data processing component 715) and notify the routing component 717 to submit the processed results to the PF sublayer instead of submitting them to an upper layer.

[0214] In some aspects, the routing information may be used by the Rx-PF entity 712 to determine the address of the next-hop node.

[0215] Although in some aspects the PF sublayer (and one or more PF entities and corresponding implementations of the PF sublayer) may be described as being deployed between the SDAP sublayer and the PDCP sublayer, the PF sublayer is not limited to such a deployment and may be deployed in any reasonable location. For example, the PF sublayer may be deployed between the PDCP sublayer and the RLC sublayer, between the RLC sublayer and the MAC sublayer, between the MAC sublayer and the PHY sublayer, above the SDAP sublayer, above the PDU layer, above the GPRS Tunneling Protocol for the user plane (GTP-U) layer, above the User Datagram Protocol (UDP) layer, above the Internet Protocol (IP) layer, above the Quick UDP Internet Connections (QUIC) layer, or within any of the PDU layer, SDAP sublayer, PDCP sublayer, RLC sublayer, MAC sublayer, PHY layer, GTP-U layer, DUP layer, IP layer, and QUIC layer.

[0216] The sequence of participation of different functions (performed by different components, such as data buffer components 704 and 714, data processing components 705 and 715, routing components 707 and 717, and data forwarding components 706 and 716) of a PF entity (either the Tx-PF entity 702 or the Rx-PF entity 712) is not limited to the illustrated diagram. Any reasonable sequence of one or more operations performed by one or more components in a PF entity may fall within the scope of an aspect of the present disclosure.

[0217] According to one aspect, the participating sequence of one or more operations performed by one or more components in the PF entity may be flexibly adjusted, such as the sequence of operations involved in determining whether a retrieved SDU should be processed in the Rx-PF entity 712 (i.e., whether the retrieved SDU should be processed by the data processing component 715) before being forwarded to a transmitting PF entity residing in the same node 711. Figure 8 illustrates another embodiment of the sequence of different components of the Rx-PF entity 812 in the PF sublayer in accordance with the present disclosure.

[0218] 8 illustrates another functional diagram of the PF sublayer according to one aspect. Similar to the PF sublayer 700, the PF sublayer 800 may include one or more PF entities (a Tx-PF entity 802 and an Rx-PF entity 812) as shown. The Tx-PF entity 802 may include a participating sequence of one or more PF entity components similar to that of the Tx-PF entity 702 of the PF sublayer 700. The Tx-PF entity 802 may include one or more of a data buffer component 804, a data processing component 805, a routing component 807, and a data forwarding component 806. As shown, the Rx-PF entity 812 may include a participating sequence of one or more components that differs compared to the participating sequence of one or more components in the Rx-PF entity 712 (of the PF sublayer 700). For example, the Rx-PF entity 712 may make a data routing decision via the routing component 717 after having a data buffering operation performed by the data buffer component 714, whereas the Rx-PF entity 812 may make a data routing decision via the routing component 817 without first having a data buffering operation performed (by the data buffer component 814). Another example of a different participation sequence in the Rx-PF entity 812 and the Rx-PF entity 712 may relate to a data forwarding operation. In the Rx-PF entity 812, a data forwarding operation (performed by the data forwarding 806) may occur after a routing decision is performed by the routing component 817, whereas in the Rx-PF entity 712, a data forwarding operation performed by the data forwarding component 717 is performed before a routing decision is performed (e.g., by the routing component 717).

[0219] 9 illustrates one embodiment of a data path in the PF sublayer in accordance with one aspect of the present disclosure. The PF sublayer 900 in the UE may have a Tx-PF entity 902 and an Rx-PF entity 911 that reside within the same node (e.g., the UE). The PF sublayer 940 in the RAN may have a Tx-PF entity 942 and an Rx-PF entity 951 that reside within the same node (e.g., the RAN node).

[0220] According to one aspect, the UE Rx-PF entity 911 may transmit data 922 (which may be processed data) to the UE Tx-PF entity 902 (e.g., to a data buffer component 904 of the UE Tx-PF entity 902). Similarly, the RAN Rx-PF entity 951 may transmit data 943 (which may be processed data) to the RAN Tx-PF entity 942 (e.g., to a data buffer component 944 of the RAN Tx-PF entity 942).

[0221] In some aspects, the UE Tx-PF entity 902 may receive data 924 from the UE upper layers 920 and process the data 924 to obtain processed data 926. The UE Tx-PF entity 902 may further transmit the processed data 926 to a RAN Rx-PF entity 951 of the RAN PF sublayer 940 over the air interface 930.

[0222] In some aspects, the UE Tx-PF 902 may transmit data 928 (which may be processed data) buffered in the data buffer component 904 to the RAN PF sublayer 940 (RAN Rx-PF 951) over the air interface 930. In some aspects, the RAN Rx-PF entity 951 may transmit data 932 (which may be processed data) to one or both of the RAN upper layers 960 and the RAN Tx-PF entity 942. In some aspects, the RAN Tx-PF entity 942 may transmit data 934 (e.g., data stored in the data buffer component 944) over the air interface 930 to the UE PF sublayer 900 (e.g., to the UE Rx-PF 911).

[0223] In some aspects, the UE Tx-PF entity 902 may receive data 924 from the UE upper layers 920 and perform processing on the data, e.g., via a data processing component 905, to obtain processed data 926. The processed data 926 may then be transmitted to a RAN Rx-PF entity 951 of the RAN PF sublayer 940 via an air interface 930. In some aspects, the RAN Rx-PF entity 951 of the RAN PF sublayer 940 may perform further processing on the processed data 926, e.g., via a data processing component 955, to obtain further processed data 943. The RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further transmit the further processed data 943 to a RAN Tx-PF entity 942 of the RAN PF sublayer 940. In some aspects, the RAN Tx-PF entity 942 of the RAN PF sublayer 940 may further process the processed data 943 to obtain further processed data 934, e.g., via a data processing component 945. The RAN Tx-PF entity 942 of the RAN PF sublayer 940 may further transmit the processed data 934 to the UE PF sublayer 900 (e.g., to the UE Rx-PF 911) via the air interface 930. In some aspects, the UE Rx-PF entity 911 of the UE PF sublayer 900 may further process the received processed data 934 via a data processing component 915 to obtain further processed data 922. In some aspects, the UE Rx-PF entity 911 of the UE PF sublayer 900 may further transmit the processed data 922 to the UE Tx-PF entity 902 of the UE PF sublayer 900 (e.g., to a data buffer 904). The UE Tx-PF entity 902 of the UE PF sublayer 900 may further process the received processed data 922 via a data processing component 905 to obtain processed data 928.In some aspects, the UE Tx-PF entity 902 of the UE PF sublayer 900 may further transmit the processed data 928 to a RAN Rx-PF entity 951 of the RAN PF sublayer 940 via an air interface 930. In some aspects, the RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further process the processed data 928 via a data processing component 955 to obtain processed data 932. The RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further transmit the processed data 932 to the RAN upper layer 960.

[0224] In some aspects, a PF entity in the UE, such as the UE Tx-PF entity 902, may receive raw data 924 from a protocol layer of the UE and perform processing on the raw data 924, e.g., via a data processing component 905, to obtain processed data 926. The protocol layer of the UE may be one of a network sensing layer, a PF sublayer, a PHY layer, an RLC sublayer, a MAC sublayer, a PDCP sublayer, an SDAP sublayer, a PDU layer, and a reconfigurable intelligent surface (RIS) layer. In some aspects, the raw data 924 may be sensing data, RIS data, Internet of Things data, positioning data, or other type of data collected by the protocol layer of the UE, e.g., collected from one or more RAN nodes or CNFs. The processed data 926 may then be transmitted over the air interface 930 to the RAN Rx-PF entity 951 of the RAN PF sublayer 940. In some aspects, the RAN Rx-PF entity 951 of the RAN PF sublayer 940 may perform further processing on the processed data 926, e.g., via a data processing component 955, to obtain further processed data 943. The RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further transmit the further processed data 943 to a RAN Tx-PF entity 942 of the RAN PF sublayer 940. In some aspects, the RAN Tx-PF entity 942 of the RAN PF sublayer 940 may further process the processed data 943, e.g., via a data processing component 945, to obtain further processed data 934. The RAN Tx-PF entity 942 of the RAN PF sublayer 940 may further transmit the processed data 934 to the UE PF sublayer 900 (e.g., to the UE Rx-PF 911) via the air interface 930.In some aspects, the UE Rx-PF entity 911 of the UE PF sublayer 900 may further process the received processed data 934 via a data processing component 915 to obtain further processed data 922. In some aspects, the UE Rx-PF entity 911 of the UE PF sublayer 900 may further transmit the processed data 922 to a UE Tx-PF entity 902 of the UE PF sublayer 900 (e.g., to a data buffer 904). The UE Tx-PF entity 902 of the UE PF sublayer 900 may further process the received processed data 922 via a data processing component 905 to obtain processed data 928. In some aspects, the UE Tx-PF entity 902 of the UE PF sublayer 900 may further transmit the processed data 928 to a RAN Rx-PF entity 951 of the RAN PF sublayer 940 via an air interface 930. In some aspects, the RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further process the processed data 928 via a data processing component 955 to obtain processed data 932. The RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further transmit the processed data 932 to the RAN upper layer 960.

[0225] In some aspects, the procedure may start with a PF entity in the RAN, such as the RAN Tx-PF entity 942 of the RAN PF sublayer 940, which may receive raw data 943 from a protocol layer of the RAN. The protocol layer of the RAN may be one of a network sensing layer, a PF sublayer, a PHY layer, an RLC sublayer, a MAC sublayer, a PDCP sublayer, an SDAP sublayer, a PDU layer, a reconfigurable intelligent surface (RIS) layer, a GTP-U layer, a QUIC layer, an SRv6 layer, a UDP layer, and a Hypertext Transfer Protocol (HTTP) layer. In some aspects, the raw data 943 may be sensing data, RIS data, Internet of Things data, location data, or other type of data collected by the protocol layer of the RAN, for example, collected from one or more UEs or CNFs. In some aspects, the RAN Tx-PF entity 942 of the RAN PF sublayer 940 may further process the raw data 943 via a data processing component 945 to obtain further processed data 934. The RAN Tx-PF entity 942 of the RAN PF sublayer 940 may further transmit the processed data 934 to the UE PF sublayer 900 (e.g., to the UE Rx-PF 911) via the air interface 930. In some aspects, the UE Rx-PF entity 911 of the UE PF sublayer 900 may further process the received processed data 934 via a data processing component 915 to obtain further processed data 922. In some aspects, the UE Rx-PF entity 911 of the UE PF sublayer 900 may further transmit the processed data 922 to the UE Tx-PF entity 902 of the UE PF sublayer 900 (e.g., to the data buffer 904). The UE Tx-PF entity 902 of the UE PF sublayer 900 may further process the received processed data 922 via a data processing component 905 to obtain processed data 928.In some aspects, the UE Tx-PF entity 902 of the UE PF sublayer 900 may further transmit the processed data 928 to a RAN Rx-PF entity 951 of the RAN PF sublayer 940 via an air interface 930. In some aspects, the RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further process the processed data 928 via a data processing component 955 to obtain processed data 932. The RAN Rx-PF entity 951 of the RAN PF sublayer 940 may further transmit the processed data 932 to the RAN upper layer 960.

[0226] 10 illustrates a sequence diagram of a process 1022 of an XaaS task of the PF sublayer according to one embodiment of the present disclosure. Referring to FIG. 10, on the UE side, one or more upper layers 1004 and a UE PF sublayer (an Rx-PF entity 1006 and a Tx-PF entity 1008) may be deployed. Similarly, on the RAN side, an upper layer 1014 and a RAN PF sublayer (a Tx-PF entity 1018 and an Rx-PF entity 1016) may be deployed. In some aspects, the UE PF sublayer and the RAN PF sublayer in FIG. 10 may be similar to the UE PF sublayer 900 and the RAN PF sublayer 940 in FIG. 9.

[0227] According to one aspect, the XaaS task may include a receiving side (e.g., RAN node 1010) sending processed data received from a transmitting side (e.g., UE 1002) back to the transmitting side instead of forwarding it to a higher layer (e.g., RAN SDAP, PDU layer, or CN). For example, the RX-PF entity 1016 residing in the RAN node 1010 may receive one or more PF PDUs from the Tx-PF entity 1008 residing in the UE 1002. The Rx-PF entity 1016 may extract and process some or all of the one or more PF SDUs to obtain processed PF SDUs. In one aspect, the processed PF SDUs at the RAN node 1010 may need to be sent back to the UE 1002 instead of to a higher layer (e.g., RAN SDAP, PDU layer, or CN) according to process 1022.

[0228] According to one aspect, process 1022 may include forwarding the processed data (e.g., processed PF SDUs) of the Rx-PF entity 1016 to a Tx-PF entity 1018 residing in the same node (e.g., RAN node 1010). The Tx-PF entity 1018 may deliver the processed data encapsulated in one or more PF PDUs via lower layers to the Rx-PF entity 1006 residing in a peer node (e.g., UE 1002). In one aspect, process 1022 may be performed based on a configuration of an associated XC indicating that the XaaS associated with process 1022 may be terminated at the RAN-PF, e.g., indicating that only the UE and RAN, and not the CN, may be involved in the XaaS task.

[0229] According to one aspect, the process 1022 may involve a PF sublayer in the UE 1002, the RAN node 1010, and the CN 1020. The process 1022 may include the UE upper layer 1004 (e.g., SDAP sublayer, PDU layer) delivering or transmitting 1024 one or more PF SDUs of the XaaS to a Tx-PF entity 1008 (e.g., UE Tx-PF 1008) residing in the UE 1002.

[0230] In one aspect, the one or more PF SDUs may be used for one or more of AI training, AI inference, data analysis, data privacy protection, data cleaning, data normalization, useless data filtering, data feature engineering, and the like.

[0231] The process 1022 may further include the UE Tx-PF entity 1008 constructing 1026 one or more PF PDUs based on the received one or more PF SDUs. In some aspects, constructing the one or more PF PDUs may include the UE Tx-PF entity 1008 performing one or more of data buffering, data processing, PF header attachment, and data sequence numbering.

[0232] In some embodiments, data processing may be performed using one or more methods including AI training, AI inference, data analysis, data privacy protection, data cleaning, data normalization, useless data filtering, or data feature engineering, etc.

[0233] In some aspects, the process 1022 may further include the UE Tx-PF entity 1008 transmitting 1028 the constructed one or more PF PDUs to the peer RAN Rx-PF entity 1016 via a lower layer, for example, of the XaaS bearer 510.

[0234] In some aspects, the process 1022 may further include the RAN Rx-PF entity 1016 extracting 1030 one or more PF SDUs from the received one or more PF PDUs. In some aspects, the RAN Rx-PF entity 1016 may further process the extracted one or more PF SDUs. The RAN Rx-PF entity 1016 may perform one or more of PF header removal, reordering based on SN, data buffering, and data processing.

[0235] In some embodiments, data processing may be performed based on one or more methods such as AI training, AI inference, data analysis, data privacy protection, data cleaning, data normalization, useless data filtering, data feature engineering, and the like.

[0236] In some aspects, if the CN 1020 needs to participate in XaaS, the process 1022 may include the RAN Rx-PF entity 1016 forwarding 1032 the retrieved or processed one or more PF SDUs to a Tx-PF entity 1018 (RAN Tx-PF entity 1018) residing within the RAN.

[0237] In some aspects, if the CN 1020 needs to be involved in an XaaS task, then the process 1022 may include the RAN Rx-PF entity 1016 submitting or transmitting 1034 the retrieved or processed one or more PF SDUs to the RAN upper layer(s) 1014 (e.g., the SDAP sublayer, the GTP-U layer, the UDP layer, the IP layer, the QUIC layer, or the PDU layer).

[0238] In some aspects, the process 1022 may further include the RAN upper layer(s) 1014 delivering or transmitting 1036, for example, upper layer data encapsulating the one or more PF SDUs to the CN, for example, to a UPF or PF deployed within the CN, for example, via an XaaS QoS flow or an XaaS session tunnel between the RAN and the CN.

[0239] In some aspects, process 1022 may further include CN 1020 using the PF SDU to perform data processing 1038. The data processing may be performed based on one or more methods such as AI training, AI inference, data analysis, data privacy protection, data cleaning, data normalization, useless data filtering, or data feature engineering.

[0240] In some aspects, the process 1022 may further include the CN 1020 delivering or transmitting 1040 the processed data to the RAN upper layer 1014 (e.g., an SDAP sublayer, a GTP-U layer, a UDP layer, an IP layer, a QUIC layer, or a PDU layer), for example, via an XaaS QoS flow or an XaaS session tunnel between the RAN and the CN. The RAN upper layer 1014 may then deliver or transmit 1042 one or more PF SDUs encapsulating the CN's processed data to the RAN Tx-PF entity 1018.

[0241] In some aspects, the process 1022 may further include the RAN Tx-PF entity constructing PF PDUs for the corresponding one or more PF SDUs 1044. Constructing the one or more PF PDUs may include the RAN Tx-PF entity 1018 performing one or more of data buffering, data processing, PF header attachment, and data sequence numbering.

[0242] In some embodiments, data processing may be performed based on one or more methods including AI training, AI inference, data analysis, data privacy protection, data cleaning, data normalization, useless data filtering, or data feature engineering, etc.

[0243] In some aspects, the process 1022 may further include the RAN Tx-PF entity 1018 delivering or transmitting 1046 the constructed one or more PF PDUs to the peer UE Rx-PF entity 1006 via a lower layer, for example, of an XaaS bearer.

[0244] In some aspects, the process 1022 may further include the UE Rx-PF entity 1006 extracting 1048 one or more PF SDUs from the received one or more PF PDUs. In some aspects, the UE Rx-PF entity 1006 may further process the one or more PF SDUs.

[0245] In some aspects, when the UE upper layer 1004 (e.g., application layer) does not need to be involved in XaaS, i.e., when the data is terminated at the UE PF sublayer, the process 1022 may further include the UE Rx-PF 1006 forwarding or transmitting 1050 the extracted or processed PF SDU to the UE Tx-PF entity 1008.

[0246] In some aspects, if a UE upper layer (e.g., application layer) needs to be involved in XaaS, i.e., when the data is not terminated at the PF sublayer, the process 1022 may further include the UE Rx-PF entity 1006 submitting or transmitting 1052 the retrieved or processed one or more PF SDUs to the(s) UE upper layer(s) 1004 (e.g., SDAP sublayer, PDU layer, or application layer).

[0247] In some aspects, the process 1022 may further include the UE upper layer(s) 1004 (e.g., application layer) performing data processing 1054 using the one or more PF SDUs. The data processing may be performed based on one or more methods including AI training, AI inference, data analysis, data privacy protection, data cleaning, data normalization, useless data filtering, data feature engineering, etc.

[0248] In some aspects, the process 1022 may further include the UE upper layer(s) transmitting 1056 one or more PF SDUs encapsulating the UE processed data to the UE Tx-PF entity 1008.

[0249] In some aspects, the process 1022 may further include the UE Tx-PF entity 1008 constructing 1058 one or more PF PDUs corresponding to the one or more PF SDUs. To construct the one or more PF PDUs, the RAN Tx-PF entity 1008 may perform one or more of data buffering, data processing, PF header attachment, and data sequence numbering.

[0250] In some embodiments, data processing may be performed based on one or more methods including AI training, AI inference, data analysis, data privacy protection, data cleaning, data normalization, useless data filtering, data feature engineering, etc.

[0251] In some aspects, the process 1022 may further include the UE Tx-PF entity 1008 transmitting the constructed one or more PF PDUs to the peer RAN Tx-PF entity 1016 via a lower layer, for example, of an XaaS bearer.

[0252] In some aspects, process 1022 may further include one or more operations that are repeated until the XaaS task is complete. The one or more operations may include operations referenced at 1030, 1032, 1034, 1036, 1038, 1040, 1042, 1044, 1046, 1048, 1050, 1052, 1054, 1056, 1058, and 1060.

[0253] A workflow or process 1022 may be used to perform XaaS tasks. According to one aspect, a workflow 1022 may be used to perform XaaS tasks associated with a NET4AI service.

[0254] According to one aspect, one or more of the UEs (e.g., UE 1002) can be active as participants in federated learning, and the RAN (e.g., RAN node 1010) can be active as an aggregator of the federated learning. In one aspect, referring to FIG. 10 , the UE upper layers (e.g., SDAP sublayer, PDU layer) can deliver 1024 one or more PF SDUs encapsulating local private data to the UE Tx-PF entity 1008. The UE Tx-PF entity 1008 can train a local model using the private data and, when constructing 1026 one or more PF PDUs, encapsulate the trained local model parameters into the payload of the one or more PF PDUs. The UE Tx-PF entity 1008 can then deliver or transmit 1028 the one or more PF PDUs to the RAN Rx-PF entity 1016 via lower layers, for example, of an XaaS bearer.

[0255] In some aspects, the RAN Rx-PF entity 1016 may retrieve 1030 local model parameters for the UE from one or more received PF PDUs. The RAN Rx-PF entity 1016 may further aggregate one or more local parameters for multiple UEs to obtain global model parameters.

[0256] In some aspects, the RAN Rx-PF entity 1016 may further forward 1032 one or more PF SDUs including the global model parameters to the RAN Tx-PF entity 1018.

[0257] In some aspects, the RAN Tx-PF entity 1016 may submit or transmit 1035 one or more PF SDUs including the local parameters of the UE to the RAN upper layers 1014.

[0258] 1036. The RAN upper layer may then deliver 1036 one or more PF SDUs to the CN 1020, for example, to a UPF or PF deployed in the CN. The CN 1020 may aggregate 1038 local parameters of multiple UEs to obtain global model parameters. The CN 1020 may further deliver 1040 the global model parameters to the RAN upper layer 1014 (e.g., SDAP sublayer, GTP-U layer), for example, via an XaaS QoS flow or an XaaS session tunnel. The RAN upper layer 1014 may then transmit 1042 one or more PF SDUs encapsulating the global model parameters to the RAN Tx-PF 1018.

[0259] In some aspects, the RAN Tx-PF entity 1018 may construct 1044 one or more PF PDUs corresponding to the one or more PF SDUs containing the global model parameters. The RAN Tx-PF entity 1018 may further add a PF PDU header(s) and a SN.

[0260] In some aspects, the RAN Tx-PF entity 1018 may deliver or transmit 1046 the constructed one or more PF PDUs including the global model parameters to the peer UE Rx-PF entity 1006 via a lower layer, for example, an XaaS bearer.

[0261] The UE Rx-PF entity 1006 may retrieve 1048 global model parameters from the received one or more PF PDUs. In some aspects, the UE Rx-PF entity 1006 may further train a local model using the most recently received global model parameters and local private data. The local private data may be buffered at the Rx-PF entity 1006. In some aspects, the local private data may be part of private data previously received from the upper layer 1004 (e.g., received 1024 from the upper layer 1004) or at some point after reception 1024.

[0262] In some aspects, the UE Rx-PF entity 1006 may forward 1050 one or more PF SDUs including the latest trained local model parameters to a Tx-PF entity 1008 residing in the UE.

[0263] In some aspects, the UE Rx-PF entity 1006 may submit or transmit 1052 the retrieved global model parameters to the UE upper layer 1004. In one aspect, the UE upper layer 1004 (e.g., application layer) may train 1054 a local model using the most recently received global model parameters and local private data. The UE upper layer 1004 may further transmit 1056 one or more PF SDUs including the most recently trained local model parameters to the UE Tx-PF entity 1008.

[0264] In some aspects, the UE Tx-PF entity 1008 may construct 1058 one or more PF PDUs corresponding to the one or more PF SDUs. The UE Tx-PF entity 1008 may further add a PF PDU header and a SN. The UE Tx-PF entity 1008 may further transmit 1060 the constructed one or more PF PDUs including the latest local model parameters to the peer RAN Rx-PF entity 1016 via lower layers, for example, on an XaaS bearer.

[0265] In some aspects, one or more operations may be performed until the associative learning model training task is completed, which may include the operations referenced at 1030, 1032, 1034, 1036, 1038, 1040, 1042, 1044, 1046, 1048, 1050, 1052, 1054, 1056, 1058, and 1060.

[0266] According to one aspect, the workflow 1022 can be used to perform XaaS tasks associated with a DAM service. For example, in a DAM service, a UE (e.g., the UE 1002) can be active as a data source and can report data to be collected to the RAN (e.g., the RAN node 1010). The DAM service can include one or more of protecting data privacy (e.g., location information), and cleaning, filtering, or normalizing non-directly usable, useless, and redundant data.

[0267] In one aspect, the UE and the RAN may cooperate to protect the privacy of the reporting data (UE identity information) based on one or more methods (e.g., generative adversarial networks (GANs)).

[0268] In one aspect, performing an XaaS task associated with a DAM service may include the UE upper layer 1004 (e.g., SDAP sublayer, PDU layer) providing or transmitting 1024 one or more PF SDUs encapsulating private data to the UE Tx-PF entity 1008.

[0269] The UE Tx-PF entity 1008 may use the PF SDUs to train the adversarial network. In one aspect, the UE Tx-PF entity 1008 may construct 1026 one or more PF PDUs and encapsulate the output of the adversarial model into the payload of the one or more PF PDUs.

[0270] The UE Tx-PF entity 1008 may deliver or transmit 1028 the one or more PF PDUs to the RAN Rx-PF entity 1016 via a lower layer, for example, an XaaS bearer. The RAN Rx-PF entity 1016 may retrieve 1030 the output of the adversarial model from the one or more received PF PDUs. The RAN Rx-PF entity 1016 may then train a generative model using the retrieved output of the adversarial model.

[0271] In some aspects, the RAN Rx-PF entity 1016 may forward 1032 one or more PF SDUs including the output of the generative model to the RAN Tx-PF entity 1018.

[0272] In some aspects, the RAN Rx-PF entity 1016 may submit 1034 one or more PF SDUs including the output of the adversarial model to the RAN upper layer 1014. The RAN upper layer 1014 may distribute 1036 the one or more PF SDUs to the CN 1020, for example, to a UPF or PF deployed within the CN. In some aspects, the CN 1020 may use 1038 the output of the adversarial model to train a generative model. The CN 1020 may further distribute or transmit 1040 the output of the generative model to the RAN upper layer 1014 (e.g., SDAP sublayer, GTP-U layer). In one aspect, the RAN upper layer 1014 may transmit one or more PF SDUs encapsulating the output of the generative model to the RAN Tx-PF entity 1018.

[0273] The RAN Tx-PF entity 1018 may construct 1044 one or more PF PDUs corresponding to the one or more PF SDUs containing the output of the Generative Model. The RAN Tx-PF entity 1018 may further add a PF PDU header and a SN. The RAN Tx-PF entity 1018 may then deliver 1046 the constructed one or more PF PDUs containing the output of the Generative Model to the peer UE Rx-PF entity 1006 via lower layers, for example, over an XaaS bearer.

[0274] In one aspect, the UE Rx-PF entity 1006 may retrieve 1048 the output of the generative model from one or more received PF PDUs. The UE Rx-PF entity 1006 may further train a local adversarial model using the output of the most recently received generative model and the local private data. The local private data may be buffered at the Rx-PF entity 1006. In some aspects, the local private data may be part of private data previously received from the upper layer 1004 (e.g., received 1024 from the upper layer 1004) or at some point after reception 1024.

[0275] In some aspects, the UE Rx-PF 1006 may forward 1050 one or more PF SDUs including the latest output of the adversarial model to the UE Tx-PF entity 1008. In some aspects, the UE Rx-PF entity 1006 may submit or transmit 1052 the output of the generative model to the UE upper layers 1004.

[0276] In some aspects, the UE upper layer 1004 (e.g., application layer) may train 1054 an adversarial model using the most recently received generative model output and the local private data. In some aspects, the UE upper layer 1004 may further transmit 1056 one or more PF SDUs including the most recently received output of the adversarial model to the UE Tx-PF entity 1008.

[0277] The UE Tx-PF entity 1008 may construct 1058 one or more PF PDUs corresponding to the one or more PF SDUs. The UE Tx-PF entity 1008 may further add a PF PDU header and a SN. The UE Tx-PF entity 1008 may further transmit 1060 the constructed one or more PF PDUs containing the latest outputs of the adversarial model to the peer RAN Rx-PF entity 1016 via lower layers, for example, on an XaaS bearer.

[0278] In some aspects, one or more operations may be performed until the GAN training task is completed, which may include the operations referenced at 1030, 1032, 1034, 1036, 1038, 1040, 1042, 1044, 1046, 1048, 1050, 1052, 1054, 1056, 1058, and 1060.

[0279] In some aspects, after training is complete, the trained generative model in the RAN Rx-PF entity 1016 can output generated data that may have the same characteristics as the original UE private data. Then, in some aspects, the RAN Rx-PF entity 1016 can forward one or more PF SDUs containing the latest outputs (i.e., generated data) of the trained adversarial model or parameters of the trained generative model to the RAN upper layer 1014. In some aspects, the RAN upper layer 1014 can distribute the generated data or the generative model to the CN 1020, for example, to a UPF or PF deployed within the CN.

[0280] In some aspects, the CN 1020 can be a data consumer that holds the generated data or generative models for further use, for example, to perform data analysis. As a data consumer, the CN 1020 may further expose the generated data or generative models to other data consumers, such as third parties, for further use. In this way, the generated data or generative models are exposed to the data consumers instead of the original UE private data, thereby protecting the privacy of the UE.

[0281] According to one aspect, the workflow 1022 can be used to perform XaaS associated with DAM services. In one aspect, the UE upper layers 1004 (e.g., SDAP sublayer, PDU layer) can deliver 1024 one or more PF SDUs encapsulating data (to be reported to the RAN) to the UE Tx-PF entity 1008.

[0282] The UE Tx-PF entity 1008 may clean, normalize, or filter non-directly usable, useless, and redundant data included in one or more PF SDUs, for example, based on preconfigured data processing rules. In some aspects, the UE Tx-PF entity 1008 may also provide a level of privacy protection for the information included in the one or more PF SDUs (e.g., by removing or replacing identifying information from the information). The UE Tx-PF entity 1008 may also build 1026 one or more PF PDUs and encapsulate the processed data into the payload of the one or more PF PDUs.

[0283] In some aspects, the UE Tx-PF entity 1008 may deliver or transmit 1028 one or more PF PDUs to the RAN Rx-PF entity 1016 via a lower layer, e.g., an XaaS bearer. The RAN Rx-PF entity 1016 may retrieve 1030 one or more PF SDUs. The RAN Rx-PF entity 1016 may further clean, normalize, or filter out non-directly usable, useless, and redundant data included in the one or more retrieved PF SDUs. The RAN Rx-PF entity 1016 may further perform feature engineering, e.g., based on preconfigured data processing rules. The RAN Rx-PF entity 1016 may further provide a level of privacy protection for information included in the one or more PF SDUs (e.g., by removing or replacing identifying information from the information). In providing a level of privacy protection, the RAN Rx-PF entity 1016 may use one or more methods of privacy protection. For example, a RAN Rx-PF entity may buffer one or more PF SDUs from K UEs and use a K-anonymization method to protect data privacy.

[0284] In some aspects, the RAN Rx-PF entity may forward 1034 one or more PF SDUs containing the processed data to the RAN upper layer 1014. The RAN upper layer 1014 may deliver 1036 the processed data to the CN 1020, e.g., to a UPF or PF deployed within the CN, e.g., via an XaaS QoS flow or an XaaS session tunnel. The CN 1020 can be a data consumer that holds the processed data, e.g., to perform data analysis. In some aspects, the CN 1020 may further expose the data to other data consumers, e.g., third parties, for further use.

[0285] 11 shows an example of a block diagram of the PF sublayer according to one embodiment of the present disclosure. Block diagram 1100 is one possible configuration for the PF sublayer, and as will be understood by those skilled in the art, this implementation is not limited to this.

[0286] The PF sublayer 1102 may be deployed between the SDAP sublayer 1104 and the PDCP sublayer 1106. The PDCP sublayer 1106 may provide a radio bearer 1108 to the PF sublayer 1102. The PF sublayer 1102 may provide an XaaS bearer 1110 to the SDAP sublayer 1104.

[0287] The SDAP sublayer 1104 may deploy one or more SDAP entities 1112 and 1114. The PF sublayer 1102 may deploy one or more PF entities 1116 and 1118. The PDCP sublayer 1106 may deploy one or more PDCP entities 1120, 1122, 1124, 1126, and 1128.

[0288] According to one aspect, XaaS sessions 1130 may include different XaaS QoS flows. Each XaaS session 1130 may be configured with one SDAP entity (e.g., SDAP entity 1112). The SDAP entity may map data included in the XaaS QoS flows to one or more PF entities. For example, one SDAP entity 1112 may map data included in the XaaS QoS flows to two PF entities 1116 and 1118. The PF entities may further map data to one or more PDCP entities. For example, PF entity 1116 may map data to two different PDCP entities 1120 and 1122, and PF entity 1118 may map data to one PDCP entity 11124.

[0289] According to one aspect, the SDAP entity 1112 may support an XaaS session 1130. In some aspects, the SDAP entity 1114 may support a 5G PDU session connection 1132.

[0290] In one aspect, the 5G PDU session connection 1132 may not be configured with a PF entity. For example, the SDAP entity 1114 (used for the 5G PDU session connection 1132) may interface directly with the PDCP sublayer 1106 (one or more PDCP entities). In one aspect, the SDAP entity 1114 may map 5G PDU session connection data to three PDCP entities 1124, 1126, and 1128.

[0291] In some aspects, the PDCP entity 1124 may carry data from both the XaaS session 1130 and the 5G PDU session connection 1132. Thus, the PDCP entity 1124 may be multiplexed by the XaaS session 1130 and the 5G PDU session 1132.

[0292] According to one aspect, from a configuration perspective, the PF sublayer 1102 can be the anchor for one or more XaaS bearers 1110. The functionality of one or more PF entities 1116 and 1118 within the PF sublayer 1102 can be configured by RRC or by dedicated XaaS signaling messages, e.g., via XSB by the XC sublayer.

[0293] In one aspect, FIG. 11 illustrates an architecture for downlink and uplink related to XaaS and 5G PDU session connection services.

[0294] According to one aspect, for XaaS, the PDCP sublayer 1106 may offer or provide radio bearer(s) to the PF sublayer 1102. In some aspects, the PF sublayer 1102 may provide the XaaS bearer 1110 to the SDAP sublayer 1104. The SDAP sublayer may offer the XaaS QoS flows for the XaaS session to the CN.

[0295] In some aspects, if the traffic granularity of the XaaS QoS flow or XaaS session is the same as the traffic granularity of the XaaS bearer, the SDAP sublayer 1104 may not be configured (or may be configured without a DL SDAP header or a UL SDAP header). That is, there is a one-to-one mapping between the XaaS QoS flow or XaaS session and the XaaS bearer. According to one aspect, the XaaS QoS flow or XaaS session can be one-to-one mapped to the XaaS bearer. For example, the XaaS session or XaaS QoS flow can be established between the UE and the CN PF instead of between the UE and the DN. The CN PF in the network itself can generate the XaaS QoS flow data traffic based on the granularity of the XaaS bearer. Thus, in some aspects, data traffic granularity can be aligned between the CN PF and the RAN, and XaaS sessions or XaaS QoS flows can be mapped one-to-one to XaaS bearers without the SDAP sublayer.

[0296] In some aspects, when only the UE and RAN are involved in XaaS, the SDAP sublayer 1104 may not be configured (or may be configured without a DL SDAP header or a UL SDAP header). For example, only the UE and RAN may be involved in the XaaS task with the UP, and the CN need not be involved in the XaaS task. XaaS data may only be processed between the UE and RAN, or originate or terminate at the RAN-PF. In this case, the XaaS data does not need to be received from or forwarded to the CN or UE upper layers (e.g., application layer), and therefore data mapping between the CN and the RAN may not be required. Only an over-the-air link may need to be established. Therefore, the SDAP sublayer 1104 may not need to be configured. In this case, there may be only an XaaS bearer between the UE and RAN, without an XaaS QoS flow.

[0297] In some aspects, if XaaS is processed only in the RAN and CN, the SDAP sublayer 1104 may not be configured (or may be configured without a DL SDAP header or a UL SDAP header). For example, the PF sublayer on the RAN and the CN tunnel between the RAN and CN may be configured, while the RAN SDAP sublayer and other wireless L2 sublayers and the PHY layer may not be configured.

[0298] In some aspects, for a connection service, the PDCP sublayer 1106 may offer a radio bearer 1108 to the SDAP sublayer 1104. In some aspects, for a connection service, the PDCP sublayer 1106 may offer a radio bearer to the PF sublayer 1102, and the PF sublayer 1102 may offer an XaaS bearer 1110 to the SDAP sublayer 1104, but the PF sublayer 1102 may operate in transparent mode (TM), i.e., a PF PDU at the PF layer is configured to include only a data field and no packet header. Data passes transparently through the PF layer without being processed. In some aspects, for a connection service, the SDAP sublayer 1104 may offer a connection QoS flow of the PDU session to the CN.

[0299] In some aspects, a radio bearer (e.g., DRB) may carry only XaaS data, only connectivity service data, or both XaaS data and connectivity data, i.e., only one or more PF entities in the PF sublayer for XaaS, only one or more SDAP entities in the SDAP sublayer for connectivity services, or both, may map data to the same PDCP entity in the PDCP sublayer.

[0300] In some aspects, as one skilled in the art can appreciate, for both XaaS and PDU connection services, the RLC sublayer may offer RLC channels to the PDCP sublayer. In some aspects, for both XaaS and PDU connection services, the MAC sublayer may offer logical channels to the RLC sublayer. In some aspects, for both XaaS and PDU connection services, the physical layer may offer transport channels to the MAC sublayer. In some aspects, for both XaaS and PDU connection services, resources in the RLC sublayer, MAC sublayer, and physical layer (e.g., MAC entities, physical resource blocks) may be multiplexed with XaaS data and connection service data.

[0301] 12 illustrates one embodiment of a data flow according to one aspect of the present disclosure. In one aspect, the CN may send one or more packets associated with the XaaS (e.g., CN packet n 1202, CN packet n+1 1204, and CN packet n+2 1206).

[0302] The SDAP layer may receive CN packets (via one or more SDAP entities) and process the CN packets into SDAP SDUs. For example, the SDAP layer processes CN packet n 1202 into an SDAP SDU 1212, CN packet n+1 1204 into an SDAP SDU 1214, and CN packet n+2 1206 into an SDAP SDU 1216. The SDAP layer then adds an SDAP packet header to each SDAP SDU and encapsulates one SDAP SDU and one SDAP packet header into one SDAP PDU. In some aspects, an SDAP PDU may include only an SDAP SDU without an SDAP packet header.

[0303] The SDAP layer 1104 may send the SDAP PDU to the PF sublayer for further processing. The PF sublayer 1102 (via one or more PF entities) may process the SDAP SDU into PF SDUs. In one aspect, the PF sublayer may process packets SDAP SDU 1212 (corresponding to CN packet n 1202) and SDAP SDU 1214 (corresponding to CN packet n+1 1204) into PF SDU 1218. The PF sublayer 1102 may further process SDPA SDU 1216 (corresponding to CN packet n+2 1206) into PF SDU 1220. The PF sublayer 1102 may send the PF SDU to the PDCP sublayer 1106 for further processing. The PDCP sublayer 1106 (via one or more PDCP entities) may process the PF SDU into PDCP SDUs. The PDCP sublayer may process the PF SDU 1218 into PDCP SDU 1222 and process the PF SDU 1220 into PDCP SDU 1224.

[0304] The PDCP sublayer 1106 can transmit the PDCP SDUs to the RLC sublayer 1226, which further processes the PDCP SDUs 1222 and 1224 into RLC SDUs 1228 and 1230, respectively. In some aspects, one PDCP SDU may also be split into multiple RLC SDUs (not shown).

[0305] The RLC sublayer 1226 can send the RLC SDUs 1228 and 1230 to the MAC sublayer 1232, which processes the RLC SDUs 1228 and 1230 into MAC SDUs 1234 and 1236, respectively.

[0306] 12 , a DN (e.g., a third party) may send one or more packets, such as IP packet m 1238, over radio bearer 1240. IP packet m 1238 may be processed in PDCP sublayer 1106 and encapsulated into PDCP SDU 1242. PDCP SDU 1242 may be further processed (e.g., encapsulated or de-encapsulated) by RLC sublayer 1226 into RLC SDUs 1244 and 1246. RLC sublayer 1226 may transmit RLC SDUs 1244 and 1246 to MAC layer 1232. MAC sublayer 1232 may process RLC SDUs 1244 and 1246 into MAC SDUs 1248 and 1250, respectively.

[0307] Referring to FIG. 12, box "H" may represent the header(s) or subheader(s) of a packet of each sublayer.

[0308] According to one aspect, the MAC sublayer 1232 may generate the MAC PDU 1252 based on one or more MAC SDUs received via the X-centric bearer 1208 and the radio bearer 1240. In one aspect, the MAC sublayer 1232 may generate the MAC PDU 1252 based on the MAC SDUs received via the X-centric bearer 1208 (e.g., MAC SDUs 1234 and 1236) and the MAC SDU 1238 received via the radio bearer 1240.

[0309] Thus, transport block 1252 may be generated by MAC 1232 by concatenating three RLC PDUs: two RLC PDUs 1228 and 1230 from XaaS bearer 1208 and one RLC PDU 1244 from radio bearer 1240. Transport block 1252 may be transmitted over physical resource blocks.

[0310] As can be understood by those skilled in the art, a PDU (e.g., an RLC PDU) of an upper layer can be an SDU (e.g., a MAC SDU) of the next lower layer. The lower layer (e.g., the MAC 1232) can add a packet header ("H" in the figure) to the SDU to obtain the lower layer PDU (e.g., MAC SDU + MAC packet header (H) = MAC PDU). For example, in a traditional connection service (5G), SDAP SDU + SDAP H = SDAP PDU, SDAP PDU = PDCP SDU, and PDCP SDU + PDCD H = PDCP PDU. In some aspects, a PDCP PDU may be separated into one or more RLC SDUs. Furthermore, RLC SDU + RLC H = RLC PDU, RLC PDU = MAC SDU, and MAC SDU + MAC H = MAC PDU. In a traditional connection service, it can be said that the lower layer cannot analyze and understand the meaning (evaluate the information) in the PDU of the upper layer.

[0311] According to one aspect, a PF layer may be provided in XaaS (6G). In some aspects, one or more SDAP PDUs may be processed to obtain one PF SDU. For example, the one or more SDAP PDUs may be a training data set that may be provided to the PF layer. The PF layer may analyze and understand the meaning of the training data set (e.g., evaluate the training data set via performing one or more operations using the training data set, including processing the training data set). In one aspect, the PF layer may use the training data set (i.e., SDAP PDUs or SDAP SDUs included in the SDAP PDUs) to obtain a trained model result, which may be in the form of a PF SDU. The PF layer may add a header to the PF SDU to obtain a PF PDU (e.g., PF SDU + PF H = PF PDU). In some aspects, the PF PDU may be a PDCP SDU or may be separated into multiple PDCP SDUs. Then, the PDCP layer may add a PDCP header to each PDCP SDU to obtain a PDCP PDU (e.g., PDCP SDU + PDCP H = PDCP PDU).

[0312] In some aspects, one or more PF PDUs may be processed to obtain one new PF SDU, and then a second PDU may be constructed. For example, the one or more PF PDUs may be a training data set that may be provided to the PF layer by the PF layer of the peer node, e.g., via a lower layer. The PF layer may analyze and understand the meaning of the training data set (e.g., evaluate the training data set via performing one or more operations using the training data set, including processing the training data set). In one aspect, the PF layer may use the training data set (i.e., the PF PDUs or the PF SDUs included in the PF PDUs) to obtain a trained model result, which may be in the form of a new PF SDU. The PF layer may add a header to the new PF SDU to obtain a second PF PDU (e.g., PF SDU + PF H = PF PDU). In some aspects, the PF PDU may be a PDCP SDU or may be separated into multiple PDCP SDUs. The PDCP layer may then add a PDCP header to each PDCP SDU to obtain a PDCP PDU (eg, PDCP SDU+PDCP H=PDCP PDU).

[0313] According to one aspect, the RLC PDU 1244 from the radio bearer 1240 can be a segment of an IP packet (m) 1238, e.g., the IP packet can be from a DN. The two RLC PDUs 1228 and 1230 from the XaaS bearer 1208 each correspond to one PDCP PDU, PDCP SDUs 1222 and 1224, respectively.

[0314] One of the two PDCP PDUs from the XaaS bearer 1208, e.g., PDCP SDU 1222, may correspond to a data processing result of the PF sublayer 1102 based on two CN packets (n 1202 and n+1 1204), e.g., these two CN packets may be from the CN PF. The other PDCP SDU 1224 may correspond to a data processing result of the PF sublayer 1102 based on one CN packet (n+2) 1206, which may be from the CN PF. In some aspects, the CN packet (n+2) 1206 may be transparently forwarded by the PF sublayer 1102 to the PDCP sublayer 1106 without data processing or PF header addition, i.e., the PF may be in transparent mode.

[0315] According to an aspect, a PDU format and one or more PDU parameters of the PF sublayer may be provided. In an aspect, the PF PDU may have two types: a data PDU and a control PDU.

[0316] According to one aspect, a data PDU may be used to carry one or more of the following: a PF header, user plane data, or data plane data. A control PDU may be used to carry control information, e.g., only a PF header without encapsulated user plane data or data plane data.

[0317] 13 illustrates one embodiment of a format of a PF PDU according to one aspect of the present disclosure. The PF PDU format 1300 may indicate one or more of control information (according to a packet header 1302) and a payload 1304. The packet header 1302 may include one or more fields to indicate one or more of Xs 1306, a sequence number (SN) 1308, a processing or forwarding (P / F) direct 1310, a destination (De) 1312, and an XaaS QoS flow identifier (XQFI) 1314. The payload may indicate data. The data may be raw data or processed data.

[0318] According to one aspect, a PF PDU may be a length-justified (e.g., byte-justified by a multiple of 8 bits) bit string. With reference to Figure 13, the bit string may be represented by a table, and the first most significant bit of the bit string may be the left-most bit of the first row of the table. In general, the bit string may be read from left to right, and then in row reading order.

[0319] In one aspect, the PF PDU may include one or more fields for indicating data. The length of the data may be variable. In some aspects, the one or more fields for indicating data may further include a PF SDU.

[0320] According to one aspect, referring to UL data on the UE side (or DL ​​data on the RAN side) as an example, a PF SDU can refer to the original data (i.e., the original PF SDU) received by a PF entity from a higher layer, e.g., from the SDAP sublayer. In some aspects, a PF SDU can refer to the result of processing performed by the PF entity using the original PF SDU.

[0321] In some aspects, for XaaS, the original PF SDU may be processed by the PF sublayer according to one or more methods (e.g., AI training, data privacy protection), and the processed result may be included in the PF PDU instead of the original PF SDU. The PF SDU may be included in the PF PDU starting from the first bit. In some aspects, for example, when the PF sublayer of the XaaS bearer operates in transparent mode to provide connection services, the original PF SDU may be included in the PF PDU.

[0322] According to one aspect, referring to DL data on the UE side (or UL data on the RAN side) as an example, a PF SDU can refer to the original data (i.e., the original retrieved PF SDU) retrieved by a PF entity from a received PF PDU from a lower layer, e.g., from the PDCP sublayer. In some aspects, a PF SDU can refer to the result of processing performed by a PF entity using the original retrieved PF SDU.

[0323] In some aspects, for XaaS, the original retrieved PF SDU can be processed by the PF sublayer using one or more methods (e.g., AI training, data privacy protection), and the processed result can be forwarded to a higher layer or another PF entity instead of the original retrieved PF SDU. In some aspects, for example, when the PF sublayer of the XaaS bearer operates in a transparent mode to provide connection services, the original retrieved PF SDU can be forwarded to a higher layer.

[0324] In some aspects, the Xs field 1306 may have a length of x bits. The Xs field 1306 may indicate the type of XaaS to which the PF data may belong. In some aspects, the Xs field 1306 may indicate the type of XaaS if the type of XaaS is not configured or specified for the XaaS bearer when the XaaS bearer (e.g., the PF entity) is established (e.g., when established under control of the control plane), such as when the XaaS bearer is established as a common or default XaaS bearer for all types of services. The type of XaaS to which the PF PDU may belong can be indicated to the peer node for correct data processing; for example, the UE may instruct the peer RAN node to provide privacy-protected DAM services for the PF sublayer.

[0325] In some embodiments, the Xs field 1306 can include a data process type (e.g., data collection, data sanitization, or data pre-processing, etc.). In some embodiments, the Xs field 1306 can be defined at a finer granularity to further indicate the data process type. For example, the granularity can be at the level of "process type" to indicate the data collection, data sanitization, or other process type of the corresponding XaaS.

[0326] According to one aspect, the data process type may be configured by the control plane (e.g., by the XaaS Controller (XC) sublayer) to the PF sublayer. When the PF entity is established in the XaaS bearer setup procedure, the PF entity may be configured by the XC to indicate what process type may be selected to process the data.

[0327] FIG. 14 illustrates one embodiment of a table illustrating a description of the Xs field according to one aspect of the present disclosure. In some aspects, the Xs field 1306 may have a size of 3 bits (although other sizes may be applicable) to indicate one or more XaaSs. For example, the Xs field may be set to '001' to indicate that the packet belongs to a NET4AI service. The Xs field may be set to '010', which may indicate that the packet belongs to a DAM service. The Xs field may be set to '011', which may indicate that the packet belongs to a mission with multiple XaaSs.

[0328] According to one aspect, the SN field 1308 has a length of y bits. The SN field 1308 can indicate a sequence number of the PF PDU for data ordering or reordering. In some aspects, the data size (AI training dataset, AI trained model parameters) for XaaS can be large, and therefore the sequence of data traffic (e.g., AI inference results) can be important. With large data sizes, the SN can be required to have correct data ordering. In some aspects, the SN can also include the task ID or data processing step ID (e.g., epoch ID) to which the PF PDU belongs for synchronization in case of data processing or data transfer delays.

[0329] According to one aspect, the P / F field 1310 may have a length of 1 bit. The P / F field 1310 (via the P / F bit) may indicate whether the PF SDU needs to be processed or forwarded directly. For example, due to computational or radio channel condition limitations, or due to service logic requirements, the PF entity of a peer node may need to participate in the processing of a previous PF PDU but not the current PF PDU. That is, in some aspects, the peer PF entity may be required to perform data processing dynamically on demand or conditions instead of always processing all data passing through the PF sublayer.

[0330] Taking AI as an example, the UE or RAN may not participate in AI training in some training epochs due to computational delays. The UE or RAN may simply extract the PF SDU from the PF PDU and forward the PF SDU to the UE application layer or CN without data processing. In some aspects, in a specific AI service logic, the UE, in cooperation with the CN PF or DN, may perform AI training on the PF sublayer in some steps or epochs, and during some of those steps or epochs, the RAN may be involved to help the UE and CN process intermediate data on the PF sublayer, but in other steps or epochs, the RAN may not be involved.

[0331] In some aspects, the XaaS bearer can operate in transparent mode, which can be used as a DRB. The P / F bit can instruct the PF entity of the peer node to switch between the XaaS bearer and the DRB. Thus, the PF entity of the peer node can be flexibly activated or deactivated via the P / F bit to switch between the XaaS bearer and the DRB. In some aspects, the DRB can be configured with a PF entity operating in transparent mode (TM). For example, if the P / F field 1310 indicates that the data fields of the PF PDU do not need to be processed by the PF sublayer and only need to be directly forwarded by the PF sublayer to an upper or lower layer, the PF sublayer of the XaaS bearer can operate in transparent mode.

[0332] 15 illustrates one embodiment of a table illustrating a description of the P / F field according to one aspect of the present disclosure. In one aspect, the P / F field may be set to '0' to indicate that the data field of the PF PDU need only be forwarded without processing, thus deactivating the PF sublayer to transparent mode. In some aspects, the P / F field may be set to '1' to indicate that data processing may be required for the data field of the PF PDU.

[0333] According to one aspect, the destination (De) field 1312 may have a length of z bits. The De field 1312 may indicate routing information (e.g., a destination address) for an RF entity to forward a PF PDU, a PF SDU extracted or processed from the PF PDU, e.g., to another PF entity residing in the same node, another PF entity in a peer node, or one or more of a higher layer. In some aspects, a PF entity (e.g., an Rx-PF entity) may forward the De field along with a PF SDU extracted or processed from a PF PDU. In some aspects, the De field may not be removed, or only a portion of the information contained in the De field may be removed. In some aspects, the De field may be updated when a PF entity performs PF PDU decapsulation, for example, when the De field indicates routing information in a source routing or Bit Index Explicit Replication (BIER) manner.

[0334] In some aspects, data through an XaaS session can be flexibly processed between different nodes, such as within a CN PF unit, within a PF sublayer of a RAN, or within a PF sublayer of a UE. There can be one or more RAN, UE, and CN functions participating in an XaaS session; for example, an XaaS session can pass through several RAN nodes, which can cooperate to process the XaaS data sequentially or in parallel. In some aspects, an Rx-PF entity within a node (e.g., within a RAN node or a UE) can submit a PF SDU extracted from or processed from a PF PDU to a higher layer or transmit it to a Tx-PF entity residing within the same node. In some aspects, different routing actions can be indicated on a PF PDU to a peer node. In some aspects, the De field can provide flexible and precise data transfer between different nodes. Data transfer can be unicast or multicast. The De field can also provide flexible and precise data transfer between different protocol layers.

[0335] According to one aspect, the header 1302 may include routing information, such as a destination address (one or more of the address of the next hop and the address of the last node terminating the task). For example, the destination address may refer to one or more of the address of a PF entity residing in a UE, the address of a PF entity residing in a RAN node, and the address of a PF entity residing in a CN node. In some aspects, a globally unique address may be pre-assigned (e.g., by the control plane) to each PF entity in the PF sublayer. In some aspects, a routing table may be pre-configured (e.g., by the control plane) in each node for a specific task of XaaS. Based on the destination address and the pre-configured routing table, the current PF entity can know or determine the next hop (which node may be the next hop, e.g., whether to hop to another PF entity residing in the same or a different node, or to a higher layer).

[0336] According to one aspect, the XQFI field 1314 may have a length of t bits. The XQFI field 1314 may indicate the ID of the XaaS QoS flow to which the PF PDU belongs. The XaaS QoS Flow ID may indicate to other protocol layers (e.g., the PDCP sublayer) what data forwarding operation it may be preferable to perform. The XaaS QoS Flow ID may also indicate to a PF entity (e.g., a PF entity in the same node, a PF entity in a peer node) what data processing operation it may be preferable to perform.

[0337] In some aspects, the PF PDU may include one or more parameters indicated by one or more of the Xs field, SN field, P / F field, De field 1312, XQFI field 1314, and Data field. In some aspects, as one skilled in the art can appreciate, the DL PDU header may indicate one or more parameters indicated in the UL PF PDU, and vice versa.

[0338] According to one aspect, an XaaS bearer may be configured per UE, i.e., one XaaS bearer serves one dedicated UE and may therefore deliver (and receive) dedicated PF data packets to (and from) one dedicated UE over the air interface.

[0339] Figure 16 illustrates one embodiment of a DL Layer 2 architecture for XaaS and PDU connection services in accordance with one aspect of the present disclosure. Figure 16 illustrates one possible DL Layer 2 architecture for XaaS (i.e., solid line boxes), among other possible implementations, as one skilled in the art will appreciate. Figure 16 also illustrates a DL Layer 2 architecture for PDU connection services (i.e., dashed line boxes).

[0340] According to one aspect, one XaaS bearer per UE can have one or more characteristics. One SDAP entity can be configured for each XaaS session, i.e., SDAP:XaaS session = 1:1. For example, SDAP entity 1602 can be configured for XaaS session 1604 of UE1. One XaaS session can include one or more XaaS QoS flows.

[0341] In some aspects, one XaaS session, e.g., 1604, may be mapped, e.g., by the SDAP sublayer 1104, to one or more XaaS data bearers (XDB), e.g., XaaS B1 1606 and XaaS B2 1608. The mapping of an XaaS session to one or more XaaS data bearers may be based on XaaS QoS requirements, e.g., data forwarding and processing requirements. In some aspects, one XaaS bearer can transport data for one or more XaaS sessions, i.e., XaaS session:XDB=Q:M.

[0342] According to one aspect, one PF entity can be configured for each XaaS bearer, i.e., XDB:PF entity = 1:1. For example, a PF entity (e.g., Data Processing 1610) can be configured for XaaS B1 1606, and a PF entity 1612 can be configured for XaaS B2 1608.

[0343] In some aspects, each PF entity (e.g., data processing 1610 and 1612) may perform one or more functions of a Tx-PF entity (e.g., Tx-PF entity 702, 802) and an Rx-PF entity (e.g., Rx-PF entity 702, 812) related to XaaS bearers, as described herein. Thus, the PF entity 1610 or 1612 may have a transmitter and a receiver, as shown in FIG. 17 and described herein.

[0344] In some aspects, an XaaS bearer may be configured with one of a Tx-PF entity and an Rx-PF entity. In some aspects, when necessary, an XaaS bearer of a node (e.g., of a RAN, of a UE) may be configured with only a Tx-PF entity and receive data via an associated PF sublayer from another XaaS bearer of that node configured with only an Rx-PF entity.

[0345] Similarly, in some aspects, an XaaS bearer of a node (e.g., of a RAN, of a UE) may be configured with only an Rx-PF entity and deliver data via the PF sublayer to another XaaS bearer of that node configured with only a Tx-PF entity.

[0346] According to one aspect, one XaaS bearer may serve only one dedicated UE, but one UE may be configured with multiple XaaS bearers. For example, XaaS B1 1606 and XaaS B2 1608 may each be configured with one UE1 1614, but UE1 1614 may be configured with XaaS B1 1606 and XaaS B2 1608.

[0347] According to one aspect, one XaaS bearer can be mapped to one or more DRBs of the same UE, and each DRB can be configured with one PDCP entity. Thus, data from one PF entity can be mapped to one or more PDCP entities configured for the same UE. In some aspects, the mapping can be based on XaaS QoS requirements, such as data forwarding and data processing requirements. In some aspects, mapping information between XaaS bearers and DRBs can be configured via dedicated XaaS signaling messages or RRC messages, for example, via the XSB or other control plane function via the XC sublayer. In some aspects, one DRB can carry data for one or more XaaS bearers among multiple XaaS bearers, i.e., XaaS bearers:DRB=M:N.

[0348] According to one aspect, the DRB carrying the PDU session data and the DRB carrying the XaaS session data can multiplex radio resources. Thus, data from the XaaS session and data from the PDU session can be mapped to the same MAC sublayer 1232 to multiplex radio resources. For example, the XaaS session data of UE1, the PDU session data of UE1, the XaaS session data of UEn, and the PDU session data of UEn may multiplex radio resources.

[0349] According to one aspect, for a UE, the ratio of the number of XaaS sessions, SDAP entities, XaaS bearers, PF entities, DRBs, and PDCP entities may be XaaS sessions:SDAP entities:XaaS bearers:PF entities:DRBs:PDCP entities:UE=Q:Q:M:M:N:N.

[0350] In some aspects, dedicated types of one or more of radio bearers, RLC channels, logical channels, transport channels, and physical channels may be defined, reserved, or configured for the XaaS, hi some aspects, dedicated physical radio resources (e.g., radio spectrum) may be allocated to the XaaS.

[0351] In some aspects, the XaaS bearers may be configured via dedicated XaaS signaling messages or RRC messages, for example via XSB or other control plane functions by the XC sublayer.

[0352] In some aspects, if the traffic granularity of an XaaS QoS flow or an XaaS session is the same as the traffic granularity of an XaaS bearer, a mapping between the XaaS QoS flow and the XaaS bearer may not be required, and an SDAP entity may not be configured. Thus, an XaaS QoS flow or an XaaS session can be one-to-one mapped to an XaaS bearer without an SDAP entity.

[0353] In some aspects, if XaaS originates or terminates at the RAN node without the involvement of the CN, the SDAP sublayer may not be configured and the service may be terminated at the PF sublayer between the RAN node and the UE.

[0354] In some aspects, if XaaS is handled only by the RAN and CN and does not involve the UE, the SDAP sublayer may not be configured (or may be configured without a DL SDAP header or a UL SDAP header).

[0355] FIG. 17 illustrates one embodiment of a model of a PF entity having a transmitter (Tx) and a receiver (Rx) in accordance with one aspect of the present disclosure. The PF entity 1700 may include a Tx unit 1702 and an Rx unit 1712. The Tx unit 1702 may be similar to the Tx-PF entity described herein, and the Rx unit 1712 may be similar to the Rx-PF entity described herein. According to one aspect, the Tx unit 1702 and the Rx unit 1712 may each include one or more components for performing one or more functions. For example, the Tx unit 1702 may include a data buffer component 1704, a data processing component 1705, and a data forwarding component 1706. The Rx unit 1712 may include a routing component 1717, a data processing component 1715, a data buffer component 1714, and a data forwarding component 1716. The functionality of each component will be described herein with reference to the PF entity.

[0356] FIG. 18 illustrates another embodiment of a PF entity having a Tx section and an Rx section in accordance with an aspect of the present disclosure. The PF entity 1800 may include a Tx section 1802 and an Rx section 1812. The Tx section 1802 may be similar to the Tx-PF entity described herein, and the Rx section 1812 may be similar to the Rx-PF entity described herein. According to an aspect, the Tx section 1802 and the Rx section 1812 may each include one or more components for performing one or more functions. For example, the Tx section 1802 may include a data buffer component 1804, a data processing component 1805, a routing component 1807, and a data forwarding component 1806. The Rx section 1812 may include a routing component 1817, a data processing component 1815, a data buffer component 1814, and a data forwarding component 1816. The functionality of each component will be described herein with reference to the PF entity.

[0357] According to one aspect, mapping information between XaaS QoS flows and XaaS bearers included in an XaaS session may be known by the SDAP entity when XaaS QoS flow data is received from a tunnel (e.g., a GTP-U tunnel) that binds to the XaaS bearer, or when it is received from an XaaS function in the CN, such as the CN XaaS PF. In some aspects, the binding information may be pre-configured when the XaaS QoS flows and XaaS bearers are established.

[0358] In some aspects, a CN packet received by the SDAP sublayer (via an SDAP entity) may include indication information (e.g., in a data header) to indicate that the packet is XaaS data rather than connection service data. In some aspects, the indication information may be a one-bit value, a Boolean value, a specific QFI (i.e., XQFI), or a specific PDU Session ID. Based on the indication information, the SDAP sublayer may determine or derive mapping information.

[0359] In some aspects, the indication information (e.g., a bit value, a Boolean value, a specific QFI (i.e., XQFI), or a specific PDU Session ID) may be included in the SDAP PDU or in the header of a GTP-U packet to indicate to which XaaS QoS flow the SDAP PDU or an SDAP SDU extracted from the SDAP PDU may belong. In some aspects, performing data mapping (UL data mapping on the RAN side or DL ​​data mapping on the UE side) by the SDAP sublayer may be necessary when an XaaS bearer carries data for multiple XaaS QoS flows (i.e., multiple XaaS QoS flows may be mapped to an XaaS bearer), for example, based on pre-configured XaaS QoS flow and XaaS bearer mapping rules.

[0360] 19 illustrates one embodiment of an SDAP PDU format with an XQFI field in the SDAP header in accordance with an aspect of the present invention. SDAP PDU format 1900 may have a header 1902 and a payload 1904. Header 1902 may have an XQFI field 1914 to indicate that the packet is XaaS data.

[0361] In some aspects, an XaaS bearer may be configured per UE group, i.e., one XaaS bearer may serve a group of UEs and deliver (and receive) dedicated PF data packets to (and from) the group of UEs over the air interface. A UE group may have one or more participating UEs.

[0362] According to one aspect, when an XaaS bearer is configured for a UE group, a first distribution method for transmission of XaaS data packets over the air interface between the RAN and one or more UEs in the UE group may include distributing a single copy of a PF data packet (e.g., a PF PDU) over the air interface to multiple UEs, for example using a broadcast or multicast method.

[0363] In some aspects, when an XaaS bearer is configured for a UE group, a second delivery method for transmission of XaaS data packets over the air interface between the RAN and one or more UEs in the UE group may include delivering separate copies of the same PF data packet (e.g., PF PDU) over the air interface to each of the one or more UEs in the UE group.

[0364] In some aspects, when an XaaS bearer is configured for a UE group, the second delivery method for transmitting XaaS data packets over an air interface between the RAN and one or more UEs in the UE group may include delivering different PF data packets (e.g., different data processing results) generated by the PF entity to different UEs of the one or more UEs in the UE group over the air interface.

[0365] 20 illustrates another embodiment of a DL Layer 2 architecture for XaaS and PDU connection services in accordance with an aspect of the present disclosure. The DL Layer 2 architecture for XaaS is shown for UE group 1 2038, see the hatched boxes for the PF entity (data processing entity 2006), the PDCP entity (ROHC entity 2010 and security entity 2018), and the RLC entity (segmentation entity 2026). In some aspects, the security entity 2018 may not be deployed. A second DL Layer 2 architecture for XaaS is shown for UE group 2 2044, UEl 2046, and UEn 2050, showing the PF entity (data processing entity 2008) in bold boxes, the PDCP entities (ROHC entity 2012, security entity 2020 for UE group 2 2044; ROHC entity 2012, ROHC entity 2014, security entity 2020, and security entity 2022 for UEl 2046; ROHC entity 2016 and security entity 2024 for UEn 2050; in some aspects, security entity 2020 may not be deployed), and the RLC entities (segmentation entity 2028 for UE group 2 2044; segmentation ARQ entity 2030 and segmentation entity 2032 for UEl 2046; See Segmentation ARQ entity 2034 for 2050. Those skilled in the art will appreciate that the implementation of the DL Layer 2 architecture for XaaS is not limited to the illustrated implementation, and other implementations may be possible.

[0366] FIG. 20 illustrates another embodiment of a DL Layer 2 architecture 2060 for a PDU connection service according to an aspect of the present disclosure. In some aspects, in a first distribution method in which transmission of XaaS data may include distributing a single copy of a PF data packet (e.g., a PF PDU) to multiple UEs over the air interface using, for example, a broadcast or multicast method, a mode 1 XaaS bearer used for a UE group (see hatched box) may have one or more characteristics. In some aspects, similar to the aspect described with reference to FIG. 16, one SDAP entity may be configured for each XaaS session, i.e., SDAP:XaaS session=1:1. For example, an SDAP entity 2004 (XaaS QoS flow handling entity 2004) may be configured for XaaS session 2002. One XaaS session, e.g., XaaS session 2002, may include one or more XaaS QoS flows.

[0367] In some aspects, with reference to the first delivery method, similar to the aspect described with reference to Figure 16, one XaaS session 2002 may be mapped to one or more XaaS data bearers (XaaS bearer 1 2040), for example, by the SDAP sublayer 1104. The mapping of an XaaS session to one or more XaaS bearers may be based on XaaS QoS requirements, such as data forwarding and processing requirements. In some aspects, one XaaS bearer can transport data for one or more XaaS sessions, where XaaS session:XDB = Q:M.

[0368] In some aspects, with reference to the first distribution method, one PF entity may be configured for each XaaS bearer, i.e., XDB:PF entity=1:1, similar to the aspect described with reference to Figure 16. For example, a PF entity (e.g., Data Processing 2006) may be configured for XaaS Bearer 1 2040.

[0369] In some aspects, referring to the first distribution method, one XaaS bearer 2040 may serve one UE group (e.g., UE group 1 2038) that includes one or more UEs. In some aspects, one UE may participate in multiple groups. In some aspects, one UE may be configured with multiple XaaS bearers.

[0370] In some aspects, an XaaS bearer may be mapped to a new type of radio bearer (NRB) to carry data for the XaaS bearer. The NRB may be intended for point-to-multipoint data transmission between the network and the UE, for example, using a multicast or broadcast method.

[0371] According to one aspect, an NRB can be configured with one PDCP entity. Thus, data from one PF entity can be mapped to one PDCP entity configured for a group of UEs. In some aspects, the mapping can be based on XaaS QoS requirements, such as data forwarding and data processing requirements. Mapping information between XaaS bearers and NRBs can be configured via dedicated XaaS signaling messages or RRC messages, for example, via an XSB or other control plane function via the XC sublayer. In some aspects, one NRB can only carry data for one or more XaaS bearers, with a 1:1 ratio of XaaS bearers to NRBs. In some aspects, a DRB carrying PDU session data and an NRB carrying XaaS session data can multiplex radio resources.

[0372] Therefore, for a UE referring to the first distribution method, the ratio of the number of XaaS sessions, SDAP entities, XaaS bearers, PF entities, NRBs, and NRB PDCP entities may be XaaS sessions:SDAP entities:XaaS bearers:PF entities:NRBs:PDCP entities=Q:Q:M:M:M:M.

[0373] According to one aspect, the NRB may be configured as a Multicast / Broadcast Service (MBS) Radio Bearer (MRB).

[0374] As described herein, a second delivery method for transmitting XaaS data may include delivering separate copies of the same PF data packet (e.g., PF PDU) over the air interface to each UE in the UE group, or delivering different PF data packets (e.g., different data processing results) generated by the PF entity to different UEs of one or more UEs in the UE group over the air interface.

[0375] According to one aspect, in the second distribution method, the XaaS bearer for each UE group (e.g., see the bold box in FIG. 20) may have one or more characteristics. In some aspects, similar to the aspect described with reference to FIG. 16, one SDAP entity may be configured for each XaaS session, i.e., SDAP:XaaS session=1:1. For example, SDAP entity 2004 (XaaS QoS flow handling entity 2004) may be configured for XaaS session 2002. One XaaS session, which is XaaS session 2002, may include one or more XaaS QoS flows.

[0376] In some aspects, referring to the second delivery method, similar to the aspect described with reference to Figure 16, one XaaS session may be mapped to one or more XaaS data bearers, for example, by the SDAP sublayer. The mapping of an XaaS session to one or more XaaS bearers may be based on XaaS QoS requirements. At the same time, one XaaS bearer can transport data for one or more XaaS sessions, i.e., XaaS session:XDB = Q:M.

[0377] In some aspects, with reference to the second distribution method, one PF entity may be configured for each XaaS bearer, and the XDB:PF entity ratio may be 1:1, similar to the aspect described with reference to Figure 16. For example, a PF entity (e.g., Data Processing 2008) may be configured for XaaS Bearer 2 2042.

[0378] In some aspects, referring to the second distribution method, one XaaS bearer (e.g., XaaS bearer 2 2042) may serve a group of UEs (e.g., UE group 2 2044, UE 1 2046, UE n 2050). In some aspects, one UE may be configured with multiple XaaS bearers.

[0379] According to one aspect, one XaaS bearer may be mapped to one or more DRBs and (optionally) one or more NRBs. Each DRB or NRB may be configured with one PDCP entity, for example, based on XaaS QoS requirements and UE radio channel conditions. Thus, one PF entity may be mapped to one or more PDCP entities, and each PDCP entity may be configured for a dedicated UE or UE group. The mapping between PF entities and PDCP entities and the configuration of PDCP entities described herein may enable flexible priority and scheduling handling. The mapping of PF entities to one or more PDCP entities may be based on XaaS QoS requirements, such as data forwarding and data processing requirements. The mapping information between XaaS bearers and NRBs and between XaaS bearers and DRBs may be configured via dedicated XaaS signaling messages or RRC messages, for example, via the XSB or other control plane function via the XC sublayer. In some aspects, one DRB / NRB can carry data for one or more XaaS bearers among a plurality of XaaS bearers, ie, XaaS bearer:DRB / NRB=M:N.

[0380] According to one aspect, XaaS traffic in the second distribution method may be split. In some aspects, XaaS traffic can be split at the PF sublayer 1102, i.e., one PF entity may be configured with multiple PDCP entities. For example, the data processing entity 2008 may be configured with multiple PDCP entities (e.g., ROHC entity 2012, ROHC entity 2014, and ROHC entity 2016). XaaS data carried by one PF entity may be mapped to multiple PDCP entities configured for a dedicated UE or UE group. For example, separate copies of the same PF data packet (e.g., PF SDU) carried by one PF entity may be mapped to multiple PDCP entities. As another example, different PF data packets (e.g., different data processing results) generated by the PF entity may be mapped to multiple PDCP entities.

[0381] According to one aspect, XaaS traffic may be segmented at the PDCP sublayer 1106; that is, one PF entity may be configured with one or more PDCP entities, and each PDCP entity may be configured with multiple RLC entities. Referring to FIG. 20, the PDCP entity 2020 may be configured with multiple RLC entities (e.g., a segmentation entity 2028 and a segmentation ARQ entity 2030). In some aspects, when a security entity, such as the security entity 2020, is not deployed, a ROHC entity (e.g., the ROHC entity 2012) may be configured with multiple RLC entities (e.g., the segmentation entity 2028 and the segmentation ARQ entity 2030). For example, separate copies of the same XaaS data packet carried by one PDCP entity (e.g., the security entity 2020, the ROHC entity 2012) may be mapped to one or more RLC entities configured for one or more UEs. As another example, different XaaS data packets carried by one PDCP entity may be mapped to multiple RLC entities.

[0382] According to one aspect, traffic splitting in the PF sublayer 1102 and traffic splitting in the PDCP sublayer 116 may be deployed jointly. For example, referring to Figure 20, one PF entity (e.g., data processing entity 2008) may be configured with multiple PDCP entities (e.g., ROHC entity 2012, ROHC entity 2014, and ROHC entity 2016), and at the same time, a PDCP entity (e.g., security entity 2020, ROHC entity 2012) may be configured with multiple RLC entities (e.g., segmentation entity 2028 and segmentation ARQ entity 2030).

[0383] In some aspects, radio resources may be multiplexed between one or more of the DRBs and NRBs carrying PDU session data and one or more of the DRBs and NRBs carrying XaaS session data.

[0384] According to one aspect, for a UE with reference to the second distribution method, the ratio of the number of XaaS sessions, SDAP entities, XaaS bearers, DRBs, DRB PDCP entities, NRBs, and NRB PDCP entities may be XaaS sessions:SDAP entities:XaaS bearers:DRBs:DRB PDCP entities:NRBs:NRB PDCP entities:UE=Q:Q:M:M:N:N:K:K.

[0385] In some aspects, for both the first and second distribution methods, one or more dedicated types of radio bearers, RLC channels (e.g., an XaaS traffic channel (XTCH) that may be mapped to a downlink shared channel DL-SCH, or a reused MBS traffic channel MTCH), logical channels, transport channels, and physical channels may be defined, reserved, or configured for the XaaS. In some aspects, dedicated physical radio resources (e.g., radio spectrum) may be allocated to the XaaS.

[0386] In some aspects, per-UE XaaS bearers and per-UE group XaaS bearers may be deployed jointly. For example, some XaaS bearers in the network may be configured for UEs based on the per-UE XaaS bearer scheme as in FIG. 16, and at the same time, some XaaS bearers in the network may be configured for UEs based on the per-UE XaaS bearer scheme as in FIG. 20. In some aspects, the one or more UEs for which one or more XaaS bearers are configured based on the per-UE scheme may be the same as or different from the one or more UEs for which one or more XaaS bearers are configured based on the per-UE group scheme. In some aspects, if XaaS originates or terminates at a RAN node without CN involvement, the SDAP sublayer may not be required and the service may be terminated at the PF sublayer.

[0387] In some aspects, if the traffic granularity of an XaaS QoS flow or an XaaS session is the same as the traffic granularity of an XaaS bearer, a mapping between the XaaS QoS flow and the XaaS bearer may not be required, and an SDAP entity may not be configured. Thus, an XaaS QoS flow or an XaaS session can be one-to-one mapped to an XaaS bearer without an SDAP entity.

[0388] In some aspects, the PDCP sublayer may not be configured for signaling broadcast, e.g., over XSB. In some aspects, data splitting in the PF entity may enable security protection for the PDCP sublayer (e.g., at per-UE granularity) compared to traditional multicast / broadcast.

[0389] In some aspects, when an RLC entity is configured for a group of UEs, the RLC entity may operate in unacknowledged mode (UM), and the RLC entity may not perform ARQ procedures.

[0390] In some aspects, when RLC is configured for a UE, the RLC can operate in unacknowledged mode (UM) or acknowledged mode (AM). An RLC entity in acknowledged mode can perform ARQ procedures.

[0391] Aspects of the present disclosure may provide one or more of an XaaS session, an XaaS QoS flow, and an XaaS bearer. Some aspects may provide one or more XaaS QoS parameters having one or more data processing parameters and one or more data forwarding parameters. One or more aspects described with reference to an XaaS session, an XaaS QoS flow, an XaaS bearer, and an XaaS QoS parameter may enable 6G XaaS on the CN, RAN, and UE sides. According to some aspects described herein, a new type of bearer on the airlink may be provided.

[0392] According to one aspect, a functional diagram of a PF may be provided. Aspects may provide a functional design of a Tx-PF entity and an Rx-PF entity. Some aspects may provide a PF PDU format and associated parameters included in the PDU. Aspects described with reference to one or more of the PF entities, the PF PDU format, and associated parameters enable the RAN to be a data source and data destination, and XaaS data can originate or terminate at the RAN.

[0393] According to one aspect, a PF entity architecture diagram may be provided illustrating how entities of the PF sublayer, PDCP sublayer, SDAP sublayer, and RLC sublayer may be connected. Some aspects may provide an XaaS bearer configuration design per UE or per UE group. Aspects described with reference to the PF architecture diagram and XaaS bearer configuration design may enable data mapping between XaaS sessions, XaaS QoS flows, XaaS bearers, DRBs, and NRBs.

[0394] According to one aspect, a PF entity is configured in a PF protocol layer in a CNF node, and the functionality of the PF entity on the CNF node is the same as the PF entities on the RAN node and the UE. Different PF entities in one or more of the CNF node, the RAN node, and the UE can operate in cooperation.

[0395] According to one aspect, the PF sublayer may be deployed in one of, but not limited to, above the PDCP sublayer, between the SDAP sublayer and the PDCP sublayer, between the PDCP sublayer and the RLC sublayer, between the RLC sublayer and the MAC sublayer, between the MAC sublayer and the PHY layer, above the SDAP sublayer, above the 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, above the Segment Routing over 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.

[0396] FIG. 21 illustrates an embodiment of an apparatus 2100 that can perform any or all of the operations of the above-described methods and mechanisms, explicitly or implicitly described herein, according to different aspects of the present disclosure. For example, a computer with network capabilities can be configured as the apparatus 2100. In some aspects, the apparatus 2100 can be a PF (e.g., Tx-PF, Rx-PF), a transmitter, a receiver, user equipment, a RAN node, a CN function, or any other entity as may be described herein. In some aspects, the apparatus 2100 can be a device that connects to a network infrastructure over a radio interface, such as a mobile phone, smartphone, or other device that may be classified as user equipment (UE). In some aspects, the apparatus 2100 can be a machine-type communication (MTC) device (also referred to as a machine-to-machine (m2m) device) or other device that may be classified as a UE even though it does not directly provide service to a user. In some aspects, the apparatus 2100 can be used to implement one or more aspects described herein. For example, apparatus 2100 may be configured to perform the operations performed by one or more of the entities and functions described herein.

[0397] As shown, device 2100 may include a processor 2110, such as a central processing unit (CPU) or a dedicated processor such as a graphics processing unit (GPU), or other such processor unit; memory 2120; non-transitory mass storage 2130; input / output interface 2140; network interface 2150; and transceiver 2160, all of which may be communicatively coupled via a bidirectional bus 2170. According to particular aspects, any or all of the illustrated elements may be utilized, or only a subset of these elements may be utilized. Also, device 2100 may include multiple of a particular element, such as multiple processors, memories, or transceivers. Elements of a hardware device may also be directly coupled to other elements without a bidirectional bus. Other electronic circuits, such as integrated circuits, may be used in addition to or in place of the processor and memory to perform the necessary logical operations.

[0398] The memory 2120 may include any type of non-transitory memory, such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination thereof. The mass storage 2130 may include any type of non-transitory storage device, such as, for example, a solid-state drive, a hard disk drive, a magnetic disk drive, an optical disk drive, a USB drive, or any computer program product configured to store data and machine-executable program code. According to some aspects, the memory 2120 or the mass storage 2130 may record statements and instructions executable by the processor 2110 to perform any of the foregoing method operations described above.

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

[0400] It will be understood that, although specific aspects of the technology have been described herein for purposes of illustration, various modifications may be made without departing from the scope of the technology. Accordingly, the specification and drawings should be considered merely as illustrative of the invention as defined by the appended claims, and all modifications, variations, combinations, or equivalents falling within the scope of the invention are intended to be covered. In particular, it is within the scope of the technology to provide a computer program product or program element, or a program storage or memory device, such as, for example, a magnetic or optical wire, or a tape or disk, for storing machine-readable signals for controlling the operation of a computer in accordance with the methods of the technology, and / or for implementing some or all of its components in accordance with the systems of the technology.

[0401] The operations associated with the methods described herein may be implemented as instructions coded in a computer program product, in other words, a computer-readable medium having software code recorded thereon for performing the methods when the computer program product is loaded into a memory and executed on a microprocessor of a wireless communication device.

[0402] Furthermore, each operation of the method may be performed on any computing device, such as a personal computer, a server, or a PDA, according to one or more program elements, modules, or objects created from any programming language, such as C++ or Java. Each operation, or a file or object implementing each operation, may be performed by dedicated hardware or a circuit module designed for that purpose.

[0403] Through the description of the above aspects, the present invention can be implemented by using hardware alone or by using software and a required general-purpose hardware platform. Based on this understanding, the technical solution of the present invention may be embodied in the form of a software product. The software product may be stored on a non-volatile or non-transitory storage medium, which may be a compact disc read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a plurality of instructions that enable a computing device (a personal computer, a server, or a network device) to execute the methods provided in the aspects of the present invention. For example, such execution may correspond to simulating logic operations as described herein. The software product may additionally or alternatively include a plurality of instructions that enable a computing device to execute operations for configuring or programming a digital logic device according to the aspects of the present invention.

[0404] While the invention has been described with reference to particular features and aspects thereof, it will be apparent that various modifications and combinations can be made thereto without departing from the invention. Accordingly, the specification and drawings are to be considered merely as illustrative of the invention as defined by the appended claims, and it is intended to cover any and all modifications, variations, combinations, or equivalents that fall within the scope of the invention. is.

Claims

1. 1. A method for providing a network service, comprising: receiving, by a first device, from a second device, at least one protocol data unit (PDU) including at least one service data unit (SDU) associated with the network service; extracting, by the first device, the at least one SDU from the at least one PDU; processing, by the first device, the at least one SDU to obtain a processed version of the at least one SDU; constructing, by the first device, at least one additional PDU having the processed version of the at least one SDU; transmitting, by the first device, the at least one additional PDU to the second device; A method having the following.

2. The method of claim 1 , wherein the first device is a radio access network (RAN) node and the second device is a user equipment (UE).

3. The method of claim 1 , wherein the first device is a UE and the second device is a RAN node.

4. 4. The method of claim 2, wherein the extracting the at least one SDU, the processing the at least one SDU, and the constructing the at least one additional PDU are performed at the first device by a Processing Function (PF) in the first device.

5. 5. The method of claim 1, wherein receiving the at least one PDU at the first device comprises receiving the at least one PDU via at least one network service data bearer (XDB) established between the first device and the second device, the at least one XDB being configured for the network service.

6. 5. The method of claim 4, wherein the communication network in which the first device and the second device are deployed includes a PF protocol sublayer, and wherein the retrieval of the at least one SDU, the processing of the at least one SDU, and the construction of the at least one additional PDU at the first device are performed at the PF protocol sublayer by the PF at the first device.

7. the second device includes a PF deployed at the second device at the PF protocol sublayer; 7. The method of claim 6, wherein receiving the at least one PDU from the second device comprises receiving the at least one PDU from the PF deployed on the second device via at least one Network Service Data Bearer (XDB) established between the first device and the second device.

8. The method of claim 7 , wherein the at least one XDB is supported by the PF protocol sublayer.

9. 9. The method of claim 1, wherein the network services include one or more of data analysis, artificial intelligence (AI) training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

10. The method of claim 6 , wherein the communication network further includes a Packet Data Convergence Protocol (PDCP) sublayer, and the PF protocol sublayer is deployed above the PDCP sublayer.

11. The method of claim 10 , wherein the communication network further includes a Service Data Adaptation Protocol (SDAP) sublayer, and the PF protocol sublayer is deployed below the SDAP sublayer.

12. 12. The method of claim 10 or 11, wherein the PDCP sublayer provides the PF protocol sublayer with at least one Data Radio Bearer (DRB) between the first device and the second device.

13. The method of claim 11 , wherein the PF protocol sublayer provides the at least one network service data bearer (XDB) to the SDAP sublayer.

14. 12. The method of claim 10 or 11, wherein the communication network includes a radio link control (RLC) sublayer, a medium access control (MAC) sublayer, and a physical (PHY) layer, and the PDCP sublayer is above the RLC sublayer, the MAC sublayer, and the PHY layer.

15. 14. The method of claim 5, 7, 8 or 13, wherein each of the at least one XDB has a respective PF entity in the PF protocol sublayer, each PF entity configured for a respective XDB.

16. The method of claim 12 , wherein the PDCP sublayer includes a respective PDCP entity in the PDCP sublayer for each of the at least one DRB.

17. 14. The method of claim 13, wherein an SDAP entity in the SDAP sublayer is configured for at least one session of the network service, any of the at least one session of the network service being between the UE and a Core Network Function (CNF), and the method further comprises establishing a CN session tunnel between the RAN node and the CNF.

18. any of the at least one session of the network service includes at least one Quality of Service (QoS) flow of the network service, and one QoS flow of the at least one QoS flow of the network service is a finest-grained QoS differentiation for a session of the at least one session of the network service; 20. The method of claim 17, wherein traffic in the same one of the at least one QoS flow of the network service receives the same data forwarding and data processing treatments.

19. 20. The method of claim 18, wherein the parameters of the data processing operation include one or more of a data processing scheduling policy, a data computation accuracy, a data computation latency, an artificial intelligence (AI) model type, an AI model privacy level, an AI model accuracy level, an AI training method, an AI inference method, a privacy protection method, a data management policy, a data sanitization policy, a data compression policy, a data embedding policy, a data representation learning policy, a data feature extraction policy, a data preprocessing policy, a privacy level, a data storage period, a data processing policy, a data cleaning policy, a data normalization policy, a data quality level, and a data processing priority.

20. 20. The method of claim 18 or 19, wherein the parameters of the data transfer processing parameters include one or more of a data transfer resource scheduling policy, a data queue management policy, a data transfer priority level, a link layer protocol configuration, an admission threshold, a data loss rate, a data transfer latency, a data transfer security protection method, and a security level.

21. 14. The method of claim 7, 8, or 13, wherein the at least one XDB is configured to serve only the UE, and the at least one XDB is also configured to deliver and receive PF protocol sublayer PDUs to and from the UE over a radio interface.

22. The method of claim 21 , wherein the UE is configured with the at least one XDB.

23. 23. The method of claim 21 or 22, wherein one or more PF entities of the at least one XDB are connected with one or more PDCP entities, and the one or more PDCP entities are dedicated to the UE.

24. 23. The method of claim 21 or 22, wherein the at least one XDB of the UE is mapped to one or more Data Radio Bearers (DRBs) of the same UE.

25. 19. The method of claim 17 or 18, wherein the at least one session of the network service is mapped by the SDAP entity to the at least one XDB dedicated to the UE.

26. 20. The method of claim 18, wherein the at least one QoS flow of the at least one session of the network service is mapped by the SDAP entity to the at least one XDB dedicated to the UE.

27. 14. The method of claim 7, 8, or 13, wherein the at least one XDB is configured to deliver at least one PF protocol sublayer PDU to a group of UEs including the UE and to receive the at least one PF protocol sublayer PDU from the group of UEs.

28. 28. The method of claim 27, wherein the at least one XDB distributes copies of the at least one PF protocol sublayer PDU to the group of UEs over an air interface using one of a broadcast and a multicast method.

29. 28. The method of claim 27, wherein the UEs of the group of UEs are configured with the at least one XDB.

30. 29. The method of claim 27 or 28, wherein at least one PF entity of the at least one XDB for the group of UEs is connected with at least one PDCP entity for the group of UEs.

31. 31. The method of claim 30, wherein the at least one PDCP entity is configured for one Multimedia Broadcast Multicast Service (MBMS) Point-to-Multipoint Radio Bearer (MRB).

32. 31. The method of claim 30, wherein the at least PDCP entity is configured for a point-to-multipoint radio bearer (NRB).

33. 29. The method of claim 27 or 28, wherein the at least one session of the network service is mapped by the SDAP entity to the at least one XDB of the group of UEs.

34. 20. The method of claim 18, wherein the at least one QoS flow of the at least one session of the network service is mapped by the SDAP entity to the at least one XDB of a group of UEs including the UE.

35. The at least one XDB is transmitted over the air interface to different UEs of the group of UEs. different PF protocol sublayer PDUs, or a separate copy of the PF protocol sublayer PDU; 28. The method of claim 27, wherein the

36. 36. The method of claim 35, wherein the group of UEs is configured with the at least one XDB.

37. 37. The method of claim 35 or 36, wherein at least one PF entity of the at least one XDB for the group of UEs is connected to at least one PDCP entity.

38. 38. The method of claim 37, wherein any of the at least one PDCP entity is configured for at least one UE in the group of UEs.

39. 39. The method of claim 38, wherein any of the at least one PDCP entity is connected to at least one radio link control (RLC) entity.

40. 39. The method of claim 37 or 38, wherein any of the at least one PDCP entity is configured for one or more of a Data Radio Bearer (DRB), a Multicast / Broadcast Service Radio Bearer (MRB), and a Point-to-Multipoint Radio Bearer (NRB).

41. 37. A method according to claim 35 or 36, wherein at least one session of the network service is mapped to the at least one XDB of the group of UEs by an SDAP entity.

42. 37. A method according to claim 35 or 36, wherein at least one Quality of Service (QoS flow) of at least one session of the network service is mapped to the at least one XDB of the group of UEs by an SDAP entity in the SDAP sublayer.

43. 43. The method of any one of claims 6 to 8 or 10 to 42, wherein the PF protocol sublayer comprises a PF entity, the PF entity comprising one or more of a data buffer component, a data processing component, a routing component, and a data forwarding component.

44. 44. The method of claim 43, wherein the data buffer component is configured to perform one or more of storing data, buffering data, and accumulating data for the data processing component to perform data processing.

45. 45. The method of claim 43 or 44, wherein the data processing component is configured to perform data processing using one or more of the following methods: data analysis, artificial intelligence (AI) training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

46. 46. ​​The method of claim 43, wherein the routing component of the PF entity is configured to add routing information to a header of a PF PDU to help another PF entity determine a routing action, or to determine the routing action of the PF entity based on the routing information included in the header of the PF PDU.

47. 47. The method of claim 46, wherein the routing action of the PF entity or the routing action of the other PF entity includes one or more of: stopping data forwarding, forwarding data to a PF entity residing in the same node as the PF entity, forwarding data to a PF entity residing in the same node as the other PF entity, forwarding data to a PF entity of a peer node, forwarding data to an upper layer entity, or forwarding data to a lower layer entity, and the data includes one or more of a PF SDU included in the PF PDU, a processed version of the PF SDU included in the PF PDU, a constructed PF PDU having the PF SDU included in the PF PDU, or a constructed PF PDU having the processed version of the PF SDU included in the PF PDU.

48. 48. The method of claim 43, wherein the data forwarding component is configured to perform one or more of the following with respect to data: mapping or distributing the data to corresponding transmission tunnels or channels; performing sequence numbering of the data; and sequentially delivering the data to the PF protocol sublayer, the upper layer, or the lower layer.

49. The PF entity: At least one PF SDU, Upper layer, Lower layers, and Another PF entity, receiving from or delivering to, At least one PF PDU, the lower layer, or said other PF entity; submitting to or receiving from, 49. The method of any one of claims 43 to 48, further comprising performing one or more of the following:

50. 50. The method of claim 49, wherein the at least one PF PDU comprises one or more of a packet header and a PF SDU.

51. 51. The method of claim 50, wherein a PF PDU of the at least one PF PDU has a packet header indicating one or more of: a type of the network service to which the one PF PDU belongs; a sequence number of the one PF PDU; an instruction for further processing the one PF SDU included in the one PF PDU; a type of data processing for the one PF SDU included in the one PF PDU; an instruction for directly forwarding the PF SDU included in the one PF PDU; routing information; and a network service QFI that identifies the QoS flow to which the one PF PDU belongs.

52. 52. The method of claim 51 , wherein the type of data processing comprises one or more of the following methods: data analysis, AI training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

53. the routing information indicates a destination to which a PF entity receiving the PF PDU should forward the data, and the data includes one or more of the PF SDU included in the PF PDU, the processed version of the PF SDU included in the PF PDU, a reconstructed PF PDU having the PF SDU included in the PF PDU, or a reconstructed PF PDU having the processed version of the PF SDU included in the PF PDU; the destination is one or more of the PF entity, another PF entity residing in the same node as the PF entity, another PF entity in a peer node, an entity at a higher layer, or an entity at a lower layer; 53. The method of claim 51 or 52.

54. removing the at least one SDU from the at least one PDU comprises removing the at least one PF SDU from the at least one PF PDU by the PF entity; 54. The method of claim 49, wherein extracting the at least one PF SDU from the at least one PF PDU comprises removing one or more packet headers included in the at least one PF PDU.

55. constructing the at least one additional PDU is performed by the PF entity after extracting the at least one PF SDU from the at least one PF PDU; Constructing the at least one additional PDU comprises one or more of analyzing and processing the raw data encapsulated in one or more payloads of the at least one PF SDU using one or more methods of data analysis, AI training, AI inference, data privacy protection, data sanitization, data processing, data management, data cleaning, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

55. The method of claim 54.

56. For the at least one XDB of the network service, one or more dedicated types of associated data radio bearers (DRBs), associated radio link control (RLC) channels, logical channels, transport channels, and physical channels are defined, provided, or configured; Dedicated physical radio resources are allocated to the at least one XDB of the network service.

56. The method of any one of claims 5, 7, 8, 13, 15, or 17-55.

57. 57. The method of claim 56, wherein the at least one XDB and the associated DRB are configured to multiplex associated radio resources using the same medium access control (MAC) entity of an associated MAC sublayer.

58. 58. The method of claim 56 or 57, wherein the at least one XDB is configured via a dedicated signaling message for the network service or a radio resource control (RRC) message for the network service.

59. 59. The method of claim 58, wherein the dedicated signaling message for the network service is sent via a signaling radio bearer between the RAN node and the UE by a control entity of a control protocol layer above an associated PDCP sublayer.

60. 60. The method of claim 59, wherein the PF entity comprises one or more of a transmitter and a receiver, each of the transmitter and the receiver performing one or more functions of the PF entity.

61. 61. The method of claim 60, wherein the PF protocol sublayer is configured in one or more of the RAN node and the UE node, and the PF protocol sublayer operates in a transparent mode when the RAN node is to perform data forwarding.

62. The PF protocol sublayer is configured in the RAN node and the UE without configuring a session tunnel between the RAN node and a CN function (CNF); The network service involves the RAN node and the UE without involving the CNF.

61. The method of claim 60.

63. The PF protocol sublayer is configured in the RAN node without configuring an SDAP sublayer, a wireless L2 sublayer, and a PHY layer in the RAN node; The network service involves the RAN node and a CN function (CNF) without involving the UE.

61. The method of claim 60.

64. sublayers including the SDAP sublayer, the PF protocol sublayer, the associated PDCP sublayer, an associated Radio Link Control (RLC) sublayer, an associated MAC sublayer, and an associated PHY layer are configured in the RAN node and the UE; When the RAN node, the UE, and the CNF are involved in the network service, a session tunnel is configured between the CNF and the RAN node.

61. The method of claim 60.

65. 65. The method of claim 64, wherein the RAN node, the UE, and the CNF are configured without the SDAP sublayer, and a traffic granularity of QoS flows of the network service is the same as a traffic granularity of the at least one XDB.

66. 66. The method of claim 64 or 65, wherein a CNF PF entity is configured in an associated PF protocol layer in the CNF, the CNF PF entity performing the functions of at least one of a RAN PF entity in the RAN node and a UE PF entity in the UE.

67. The PF protocol sublayer is located above the PDCP sublayer, between the SDAP sublayer and the PDCP sublayer, between the PDCP sublayer and the RLC sublayer, between the RLC sublayer and the MAC sublayer, between the MAC sublayer and the PHY layer, above the SDAP sublayer, above the PDU layer, above the GTP-U layer, above the UDP layer, above the IP layer, above the QUIC layer, and above the HyperText Transfer Protocol (HTTP) layer.

67. The method of any one of claims 64 to 66, wherein the method is deployed in one of above a Segment Routing over IPv6 (SRv6) layer, in the PDU layer, in the SDAP sublayer, in the PDCP sublayer, in the RLC sublayer, in the MAC sublayer, in the PHY layer, in the GTP-U layer, in the UDP layer, in the IP layer, in the application layer, in the HTTP layer, in the SRv6 layer, and in the QUIC layer.

68. 68. The method of claim 5, 7, 8, 13, 15, or 17-67, wherein traffic in the same XDB of the at least one SDB receives the same data transfer and data processing operations, and one or more data processing and data transfer parameters are configured for each XDB of the at least one XDB.

69. The method of claim 1 , wherein the first device is a Radio Access Network (RAN) node and the second device is a Core Network Function (CNF).

70. The method of claim 1 , wherein the first device is a CNF and the second device is a RAN node.

71. The method of claim 1 , wherein the first device is a CNF and the second device is a UE.

72. The method of claim 1 , wherein the first device is a UE and the second device is a CNF.

73. a memory configured to store instructions; a processor configured to execute the instructions stored in the memory; and wherein the instructions stored in the memory, when executed, configure the processor to perform the method of any one of claims 1 to 72. Device.

Images