Technologies for data collection plane in a wireless network

Abstract

The present application relates to devices and components including apparatus, systems, and methods for a data collection plane in a wireless network.

Description

TECHNOLOGIES FOR DATA COLLECTION PLANE IN A WIRELESS NETWORKTECHNICAL FIELD

[0001] This application relates generally to communication networks and, in particular, to technologies for a data collection plane in a wireless network.BACKGROUND

[0002] Third Generation Partnership Project (3GPP) Technical Specifications (TSs) define standards for wireless networks. These TSs describe aspects related to signaling traffic through systems that incorporate wireless networks.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 illustrates a network environment in accordance with some embodiments.

[0004] FIG. 2 illustrates a network architecture with a data collection plane in accordance with some embodiments.

[0005] FIG. 3 illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0006] FIG. 4A illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0007] FIG. 4B illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0008] FIG. 5A illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0009] FIG. 5B illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0010] FIG. 6A illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0011] FIG. 6B illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0012] FIG. 6C illustrates another network architecture with a data collection plane, in accordance with some embodiments.

[0013] FIG. 7 illustrates an example procedure in accordance with some embodiments.

[0014] FIG. 8 illustrates another example procedure in accordance with some embodiments.

[0015] FIG. 9 illustrates another example procedure in accordance with some embodiments.

[0016] FIG. 10 illustrates another example procedure in accordance with some embodiments.

[0017] FIG. 11 illustrates an example identifier allocation scheme, in accordance with some embodiments.

[0018] FIG. 12 illustrates another example procedure in accordance with some embodiments.

[0019] FIG. 13 illustrates example tunnels for carrying service data, in accordance with some embodiments.

[0020] FIG. 14 illustrates example aspects of a user equipment, a radio access network, a data plane function, and a data network function, in accordance with some embodiments.

[0021] FIG. 15 illustrates an example of a task data adaptation protocol (TDAP) transmission entity and a TDAP reception entity, in accordance with some embodiments.

[0022] FIG. 16 illustrates an operational flow / algorithmic structure in accordance with some embodiments.

[0023] FIG. 17 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0024] FIG. 18 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0025] FIG. 19 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0026] FIG. 20 illustrates a user equipment in accordance with some embodiments.

[0027] FIG. 21 illustrates a network device in accordance with some embodiments.DETAILED DESCRIPTION

[0028] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, and techniques in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A / B” and “A or B” mean (A) , (B) , or (A and B) ; and the phrase “based on A” means “based at least in part on A, ” for example, it could be “based solely on A” or it could be “based in part on A. ”

[0029] The following is a glossary of terms that may be used in this disclosure.

[0030] The term “circuitry” as used herein refers to, is part of, or includes hardware components that are configured to provide the described functionality. The hardware components may include an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) , an application specific integrated circuit (ASIC) , a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structured ASIC, or a programmable system-on-a-chip (SoC) ) , or a digital signal processor (DSP) . In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the  functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0031] The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, or transferring digital data. The term “processor circuitry” may refer an application processor, baseband processor, a central processing unit (CPU) , a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, or functional processes.

[0032] The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I / O interfaces, peripheral component interfaces, and network interface cards.

[0033] The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities that may allow a user to access network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. Furthermore, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communications interface.

[0034] The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” or “system” may refer to multiple computer devices or multiple computing systems that are communicatively coupled with one another and configured to share computing or networking resources.

[0035] The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component or asset within a computing or network environment, or a  physical or virtual component within, accessible by, or available to a device or component. Resources could include, but are not limited to, memory space / usage, processor / CPU time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input / output operations, ports or network sockets, channel / link allocations, throughput, or workload units. A “hardware resource” may refer to compute, storage, or networking resources provided by physical hardware elements. A “virtualized resource” may refer to compute, storage, or networking resources provided by virtualization infrastructure to an application, device, or system. The term “communication resource” may refer to resources that are accessible by, or available to, computer devices / systems for transferring information over a channel of a communication network. For example, communication resources may include, but are not limited to, time / frequency resources, code resources, modulation resources, etc. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0036] The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with or equivalent to “communications channel, ” “data communications channel, ” “transmission channel, ” “data transmission channel, ” “access channel, ” “data access channel, ” “link, ” “data link, ” “carrier, ” “radio-frequency carrier, ” or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices for the purpose of transmitting and receiving information.

[0037] The terms “instantiate, ” “instantiation, ” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0038] The term “connected” may mean that two or more elements, at a common communication protocol layer, have an established signaling relationship with one another over a communication channel, link, interface, or reference point.

[0039] The term “network element” as used herein refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network  services. The term “network element” may be considered synonymous to or referred to as a networked computer, networking hardware, network equipment, network node, or a virtualized network function.

[0040] The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. An information element may include one or more additional information elements.

[0041] FIG. 1 illustrates a network environment 100 in accordance with some embodiments. The network environment 100 may include user equipment (UE) 104 communicatively coupled with base station 108 of a radio access network (RAN) 110. The UE 104 and the base station 108 may communicate over air interfaces compatible with 3GPP TSs, such as those that define a Fifth Generation (5G) new radio (NR) system or a later system (e.g., Sixth Generation (6G) system) . The base station 108 may provide user plane (UP) and control plane (CP) protocol terminations toward the UE 104.

[0042] The network environment 100 may further include a core network (CN) 112. For example, the CN 112 may comprise a 5th Generation Core network (5GC) , a 6th Generation Core network (6GC) , or later generation core network. The CN 112 may be coupled to the base station 108 via a fiber optic or wireless backhaul. The CN 112 may provide functions for the UE 104 via the base station 108. These functions may include managing subscriber profile information, subscriber location, authentication of services, or switching functions for voice and data sessions.

[0043] The network environment 100 may further include an external data network 120, which may be accessed by the UE 104 via the RAN 110.

[0044] In some embodiments, the network environment 100 may also include UE 106. The UE 106 may be coupled with the UE 104 via a sidelink interface. In some embodiments, the UE 106 may act as a relay node to communicatively couple the UE 104 to the RAN 110. In other embodiments, the UE 106 and the UE 104 may represent end nodes of a communication link. For example, the UEs 104 and 106 may exchange data with one another.

[0045] The 5G network architecture is primarily designed as a tunnel for communication data transmission (e.g., to a destination address) . The destination (e.g.,  termination) for the communication data transmission is an external network (e.g., DN 120) or the UE, and the 5G network does not decode or handle the data.

[0046] For 3GPP awareness non-communication services (e.g. positioning, minimization of drive tests (MDT) , artificial intelligence (AI)  / machine learning (ML) , quality of experience (QOE) ) , all the transmissions are via the control plane (e.g., via the RAN and access and management function (AMF) ) . 6G will introduce a wealth of new services, which are not related to communication service, such as services that serve information network and / or network maintenance. These services may be referred to as data services or non-communication services. The non-communication services may include, for example, AI, sensing, computing, positioning, MDT, QOE, and / or other services.

[0047] The data characteristics for non-communication services may be different from the legacy communication services. For example, the non-communication services may involve significantly larger amounts of data. Additionally, the non-communication services may be terminated within the 3GPP internal network. The legacy AMF and user plane function (UPF) may not work well to support the non-communication services from both CP and UP perspective.

[0048] Accordingly, embodiments herein provide technologies for a data collection plane to support 3GPP native non-communication services. In some embodiments, the data collection plane may be implemented in the CN 112. The data collection plane may enable data transmissions for the data services to be offloaded from the control plane (e.g. AMF path) . In some embodiments, the data collection plane architecture may be common and / or shared with both a 5G and a 6G network, to enable the data services to be supported in 5G systems such as 5G-Advanced (5G-A) .

[0049] FIG. 2 illustrates a network architecture 200 with a data collection plane 202 in accordance with various embodiments. The network architecture may include a UE 204 (e.g., corresponding to UE 104) , RAN 210 (e.g., corresponding to RAN 110) , DN 220 (e.g., corresponding to DN 120) , UPF 222, AMF 224, and / or SMF 226. In embodiments, the RAN 210, UPF 222, AMF 224, and SMF 226 may included in a 5G network, a 6G network, and / or another wireless cellular network.

[0050] In various embodiments, the data collection plane 202 may include a data management function (DMF) 230, a data plane function (DPF) 232, a data coordination function (DCF) 234, and / or one or more data network functions (DNFs) 236a-c. The data  collection plane 202 may support non-communication data services for the UE 204 and / or RAN 210, thereby offloading the non-communication data services and associated data traffic from the control plane (e.g., via the AMF 224) .

[0051] The non-communication data services may include, for example, one or more of AI, sensing, computing, positioning, MDT, QOE, and / or another data service. In some embodiments, the non-communication data service may be for a specific UE, area-based (e.g., to collect and / or analyze service data from multiple UEs in a geographic area) , and / or RAN-based.

[0052] The service data handled by the data collection plane 202 may include AI data, sensing data, computing data, and / or network operation data. The AI data may include, for example, data related to AI training and / or inference, such as models, training data, testing data (e.g., measurement reports) , and / or output data. The sensing data may include, for example, raw data, sensing measurement data, pre-processed data, and / or sensing results (e.g., generated by the UE and / or RAN) . The network operation data may include, for example, data related to network operation, maintenance, and / or management (e.g., obtained from the network side) , such as configuration information, performance information, logs, and / or alarm information. The computing data may include data related to management and / or coordination of the computing power between the UE and the network. The computing data may additionally assist the network to distribute computing to one or more other computing-based functions (e.g., AI and / or sensing) . The data collection plane 202 may support the collection, transmission, storage, analysis, and / or sharing of the data within the network. Additionally, the data collection plane 202 may enable providing the data to network internal functions and / or external applications conveniently, efficiently, and securely.

[0053] In embodiments, the management of data services and associated data transmission in the data collection plane 202 may be based on a task (rather than a protocol data unit (PDU) session as in legacy communication services) . A task may be associated with one or more data service types (e.g., AI, sensing, computing, etc. ) . In embodiments, the data may be generated, collected, processed, stored, and / or analyzed within the data collection plane 202 (e.g., by the DNFs 236a-c and / or DCF 234, as described further herein) . The data may include different data types, such as raw data, measurement data, pre-processed data, and / or results data. In some embodiments, different service types may be coordinated for a  single task (e.g., by the DCF 234) . Accordingly, the data collection plane 202 may enable new use cases while also offloading the burden from the control plane.

[0054] The DMF 230 may perform task management, e.g., including establishment, modification, and / or release of a task. The DMF 230 may be responsible for allocation and / or management of a task ID for the task (which may be used for routing of data packets associated with the task) . Additionally, the DMF 230 may configure and / or maintain a tunnel between the RAN 210 and the DNFs 236a-c to service the task. For example, the DMF 230 may receive a task setup request associated with the UE 204. The task setup request may include task information for a task. The DMF may generate a task configuration for the task that is associated with one or more of the DNFs 236a-c. The DMF 230 may send the task configuration to the DPF 232 to establish a tunnel between the RAN 210 and the one or more DNFs 236a-c for the task. The DMF 230 may further send the task configuration to the UE 204 and / or RAN 210 to establish a data service path between the UE 204 and the one or more DNFs 236a-c (e.g., via the DPF 232) .

[0055] The DPF 232 may perform data routing between the UE 204 and / or RAN 210 and the DNFs 236a-c and / or DCF 234. For example, the data may be routed based on the task ID (and / or sub-task ID as further described herein) . The DPF 232 may handle quality of service (QoS) management, and / or access traffic steering, switching, and splitting (ATSSS, e.g., between a 5G network and a 6G network) .

[0056] The DNFs 236a-c may perform one or more functions for a data service. For example, the DNFs 236a-c may provide respective services, such as sensing, AI, and / or computing. The DNFs 236a-c may provide a configuration, data preprocessing, data storage, and / or data analysis for the respective service. In some embodiments, the DNFs 236a-c may allocate a service ID for the data service.

[0057] The DCF 234 may support a task that involves multiple data services, e.g., handled by different DNFs 236a-c. The DCF 234 may split the task into multiple sub-tasks to be handled by different DNFs 236a-c. The DCF 234 may provide sub-task configurations to the DNFs 236a-c and / or other components of the data collection plane 202. Additionally, the DCF 234 may coordinate between DNFs 236a-c and / or perform data preprocessing, data storage, and / or data analysis across DNFs 236a-c.

[0058] Further aspects of the DMF 230, DPF 232, DCF 234, and / or DNFs 236a-c will be explained in further detail below.

[0059] In some embodiments, the data collection plane may be shared by multiple networks, e.g., with different access technologies. For example, FIG. 3 illustrates a network architecture 300 with a data collection plane 302 coupled to both a 5G network 340 and a 6G network 342. The arrangement and operation of the data collection plane 302 with respect to the 5G network 340 and / or 6G network 342 may be similar to that described above with respect to FIG. 2.

[0060] In some embodiments, the DMF of the data collection plane may be deployed together with (e.g., co-located with) the SMF and / or in the RAN. Additionally, or alternatively, the DPF may be deployed together with (e.g., co-located with) the UPF, the AMF, and / or in the RAN. FIGS. 4A-4B, 5A-5B, and 6A-6C illustrate additional example network architectures and associated data and / or signaling paths, in accordance with some embodiments. All of the components of the data collection plane and / or communication network shown in FIG. 2 may not be shown in or reintroduced for each of FIGS. 4A-4B, 5A-5B, and 6A-6C. However, it will be understood that the components may be present and may have similar functionality to that described with respect to other figures (e.g., FIG. 2) .

[0061] FIGS. 4A and 4B illustrate example network architectures 400 and 450, respectively, in which the data and / or other signaling between the RAN 410 (and / or UE 404) and components of the data collection plane 402 (e.g., DMF 430, DCF 434, DNFs 436a-c) may be via the AMF 424. In the network architecture 400, the DPF 432 may be co-located with the AMF 424 (or assumed to be co-located for purposes of other components of the network architecture 400) . In the network architecture 450, the DPF may be disabled or omitted. The functions of the DPF (e.g., signal routing) may be performed by the AMF 424.

[0062] FIGS. 5A and 5B illustrate example network architectures 500 and 550, respectively, in which the data and / or other signaling between the RAN 510 (and / or UE 504) and components of the data collection plane 502 (e.g., DMF 530, DCF 534, DNFs 536a-c) may be via the UPF 522 and / or the AMF 524. In network architecture 500, the DPF 532 may be co-located with the UPF 522.

[0063] In the network architecture 550, the DPF 532 may be separate from the UPF 522 and coupled to the UPF 522 via an interface (e.g., a point-to-point (P2P) tunnel or a tunnel based on Internet Protocol (IP) address routing) . The UPF 522 may receive data from the RAN 510 and forward the data to the DPF 532. The DPF 532 may forward the data to the  respective DNFs 536a-c (e.g., based on a task ID and / or sub-task ID associated with the data) .

[0064] In network architecture 500 and 550, the components of the data collection plane 502 may be further coupled to the AMF 524, e.g., as shown.

[0065] FIGS. 6A, 6B, and 6C illustrate further examples of network architectures in accordance with some embodiments. For example, FIG. 6A illustrates an example network architecture 600 in which the DMF 630 of the data collection plane 602 is co-located with the SMF 626. FIG. 6B illustrates an example network architecture 650 in which the DPF 632 is co-located with the UPF 622. FIG. 6C illustrates an example network architecture 660 in which the DMF 630 is co-located with the SMF 626 and the DPF 632 is co-located with the UPF 622.

[0066] In various embodiments, the UE may send a task request to the DMF to establish a task and associated tunnel. The task request may be triggered while the UE is in idle and / or inactive state with the RAN and / or while the UE is in connected state with the RAN.

[0067] FIG. 7 illustrates an example procedure 700 for task management when the UE starts in idle and / or inactive state. Aspects of the procedure 700 may be performed by a UE (e.g., UE 104) , a RAN (e.g., RAN 110) , an AMF (e.g., AMF 224) , a DMF (e.g., DMF 230) , a DPF (e.g., DPF 232) , and / or a DNF (e.g., DNF 236a-c) .

[0068] At 702 of the procedure 700, the UE may be in idle state. At 704, the UE may send a task request to the RAN. The task request may be initiated by the UE and / or by the RAN (e.g., via paging) . Additionally, or alternatively, the DMF may initiate a new task (e.g., based on an external request) and send a message to the UE and / or RAN to trigger the task request.

[0069] The task request may include task information associated with a task. For example, the task information may include one or more data services that are associated with the task (e.g., sensing, AI, and / or computing) . In some embodiments, the task request may include an access identity, access category, and / or establishment cause associated with the task request. The access identity may define one or more task types associated with the task. The access category may define one or more QoS configurations for the task. In some embodiments, the task request may include an establishment cause that indicates an access  identity and / or access category via one or more mapping tables. The mapping tables may be similar to tables used for an RRC setup request message, such as Table 4.5.2.1 of 3GPP TS 24.501 (table for access identities) , Table 4.5.2.2 of TS 24.501 (mapping table for access categories) , and / or Table 4.5.6.1 of TS 24.501 (mapping table for access identities / access categories and RRC establishment cause) . In some embodiments, one or more of these tables may be extended to include one or more RRC establishment causes, access identities, and / or access categories for task-based services. In other embodiments, separate tables may be defined for task-based services. Accordingly, the task setup message may correspond to the RRC setup request message or a designated RRC message for task request.

[0070] The task request may be routed from the UE to the AMF (e.g., via the RAN) . If the AMF accepts the connection with the UE, the AMF forwards the task request to the DMF. In embodiments, the RAN and / or AMF may add or remove information from the task request to be transmitted to the DMF. In embodiments, the AMF may approve establishment of a connection with the UE (e.g., access stratum (AS) and / or non-access stratum (NAS) connection) . The UE may enter a RRC connected state with the RAN and / or AMF (e.g., shown at 716 of the procedure 700) .

[0071] At 710 of the procedure 700, the DMF, DPF, and / or DNF may perform a task establishment procedure. For example, the DMF may allocate a task ID to the task. The DMF may provide task information (e.g., one or more service types, QoS information such as a QoS profile and / or policy, and / or one or more DNFs associated with the task) to the DPF to enable the DPF to establish a tunnel (e.g., data service path) between the DNF and the RAN (and / or UE) for the task. The DMF may generate a task configuration for the task (e.g., in cooperation with the DNF and / or DPF) . The task configuration may indicate the task ID, the DNF that is to service the task, routing information, and / or other information associated with the task. In some embodiments, the DNF may allocate a service ID to identify a service instance for the task within the corresponding DNF.

[0072] In some embodiments, different modes may be supported for different types of tasks. For example, a task may be a real-time task and / or a non-real time task. Additionally, or alternatively, the task may be deployed in the UE, the RAN, and / or the DNF (e.g., based on the type of data and / or service involved) . For example, network-centric sensing, in which the RAN (e.g., one or more base stations) receives the sensing signal, may be implemented in  the RAN. UE-centric sensing, in which one or more UEs receive the sensing signal, may be implemented in the UE.

[0073] At 712 of the procedure 700, the DMF may send a task setup response to the AMF and / or RAN. The task setup response may include the task configuration. At 716, the UE may enter an RRC connected state.

[0074] At 718, the UE may receive the task configuration, e.g., from the RAN. For example, the task configuration may be received in a RRC reconfiguration message. At 720, the UE may send an acknowledgment (ACK) to confirm receipt of the task configuration. The ACK may be forwarded to the DMF.

[0075] At 722 of the procedure 700, data for the task may be transmitted between the UE and the DNF (e.g., based on the task configuration) . The data may be transmitted via the tunnel established by the DPF, e.g., from the UE to the RAN, the RAN to the DPF, and the DPF to the DNF (and back to the UE) .

[0076] FIG. 8 illustrates another example procedure 800 in accordance with some embodiments. Aspects of the procedure 700 may be performed by a UE (e.g., UE 104) , a RAN (e.g., RAN 110) , an AMF (e.g., AMF 224) , a DMF (e.g., DMF 230) , a DPF (e.g., DPF 232) , and / or a DNF (e.g., DNF 236a-c) . In the procedure 800, the UE may be in RRC connected state with the RAN prior to sending the task request.

[0077] At 802, the UE may be in RRC connected state with the RAN. At 804, the UE may send a task request with task information. In some embodiments, the UE may transmit a NAS message to the DMF (e.g., via the RAN) with the task request. The NAS message may be sent directly to the DMF from the RAN, bypassing the AMF.

[0078] At 810, the DMF may perform the task establishment procedure (e.g., corresponding to the task establishment procedure performed at 710 of FIG. 7) . The DMF may generate a task configuration.

[0079] At 812, the DMF may send a task setup response to the RAN. The task setup response may include the task configuration. At 814, the RAN may send the task configuration to the UE, e.g., in a RRC reconfiguration message. At 816, the UE may send an ACK to confirm receipt of the task configuration. The ACK may be forwarded to the DMF.

[0080] At 818, the UE may exchange service data with the DNF based on the task configuration.

[0081] FIG. 9 illustrates another example procedure 900 in accordance with some embodiments. Aspects of the procedure 900 may be performed by a UE (e.g., UE 104) , a RAN (e.g., RAN 110) , an AMF (e.g., AMF 224) , a DMF (e.g., DMF 230) , a DPF (e.g., DPF 232) , and / or a DNF (e.g., DNF 236a-c) . In the procedure 900, the task (or a portion of the task) may be implemented in the RAN rather than the UE.

[0082] At 910, the DMF may perform the task establishment procedure with the DNF and / or DPF. At 912, the DNF may determine a location in the RAN to perform the task. At 914, the DNF may send a RAN task setup message to the DMF. The RAN task setup message may include task configuration information. At 916, the DMF may send a RAN task setup message to the RAN. The RAN task setup message may include the task configuration information from the DNF.

[0083] At 918, the RAN may implement the task. At 920, the RAN may transmit and / or receive service data with the DNF. The service data may be routed via the DPF (e.g., via a tunnel established by the DPF) .

[0084] FIG. 10 illustrates another example procedure 1000 in accordance with some embodiments. Aspects of the procedure 1000 may be performed by a UE (e.g., UE 104) , a RAN (e.g., RAN 110) , an AMF (e.g., AMF 224) , a DMF (e.g., DMF 230) , a DPF (e.g., DPF 232) , a DCF (e.g., DCF 234) and / or a DNF (e.g., DNF 236a-c) . In the procedure 1000, the task may involve multiple service types, which may be split into subtasks to be serviced by different DNFs. The DCF may split the task into subtasks and / or manage coordination of the sub-tasks.

[0085] At 1002 of the procedure 1000, the UE may be in RRC connected state with the RAN. At 1004, the UE may send a task request with task information. The task information may include multiple service types to indicate that the task involves multiple data services (e.g., sensing and AI in one example) . The task information may be transmitted to the DMF (e.g., via the RAN) .

[0086] The DMF may allocate a task ID to the task. Additionally, the DMF may identify that the task involves multiple data services based on the task information. Accordingly, at 1010, the DMF may send a task request to the DCF. The task request may  include the task ID and the task information (e.g., the service types and other information associated with the task) .

[0087] At 1012, the DCF may split the task into a first sub-task (subtask1) and a second sub-task (subtask2) to be serviced by respective DNFs (e.g., DNF #1 and DNF #2 as shown in FIG. 10) . The DCF may allocate respective sub-task IDs to the first and second sub-tasks. At 1014, the DCF may establish (e.g., activate) the first sub-task at the first DNF (DNF #1) . At 1016, the DCF may establish the second sub-task at the second DNF (DNF #2) . For example, the DCF may send sub-task information associated with the first or second sub-tasks to the respective DNFs. The DCF and / or DNFs may generate sub-task configurations for the respective sub-tasks. In some embodiments, the individual DNFs may allocate a service ID to identify a service instance for the sub-task within the respective DNF.

[0088] FIG. 11 illustrates an example of IDs to track a task, in accordance with some embodiments. As shown, the DMF may allocate a task ID 1102 for the task. The DCF may allocate a first subtask ID 1104a and a second sub-task ID 1104b for respective sub-tasks of the task. A first DNF that handles the first sub-task associated with first sub-task ID 1104a may allocate a service ID 1106a for the service instance in the first DNF that services the first sub-task. A second DNF that handles the second sub-task associated with second sub-task ID 1104b may allocate a service ID 1106b for the service instance in the second DNF that services the second sub-task.

[0089] Returning to FIG. 10, the DCF may generate a task configuration that includes the sub-task configurations. In some embodiments, the task configuration may further include task-level configuration information.

[0090] At 1018 of the procedure 1000, the DCF may send the task configuration (e.g., including the sub-task configurations) to the DMF. The DCF and / or the DMF may send a message to the DPF to establish service data paths between the UE and the respective DNFs.

[0091] At 1020, the DMF may send the task configuration to the UE (e.g., via the RAN) . At 1024, the UE may send an ACK to confirm receipt of the task configuration.

[0092] At 1026, the UE may communicate (e.g., transmit and / or receive) service data for the first sub-task with the first DNF. At 1028, the UE may communicate service data for the second sub-task with the second DNF.

[0093] At 1030, the DCF may coordinate data between the first and second DNFs. For example, the DNFs may send service data for the respective subtasks to the DCF. The service data may include, for example, data that is provided to the DNF (e.g., from the UE) and / or processed / generated by the DNF. The DCF may combine the service data for the multiple subtasks. In some embodiments, the DCF may perform further processing of the service data for the multiple subtasks. Additionally, or alternatively, the DCF may provide service data from the first subtask to the second DNF (that services the second subtask) as needed and / or provide service data from the second subtask to the first DNF. In some embodiments, the DCF may generate and / or output a task output for the task.

[0094] FIG. 12 illustrates another example procedure 1100 in accordance with various embodiments. Aspects of the procedure 1100 may be performed by a UE (e.g., UE 104) , a RAN (e.g., RAN 110) , an AMF (e.g., AMF 224) , a DMF (e.g., DMF 230) , a DPF (e.g., DPF 232) , a DCF (e.g., DCF 234) and / or a DNF (e.g., DNF 236a-c) . In the procedure 1100, the task may involve multiple service types, similar to the procedure 1000 of FIG. 10. However, in the procedure 1100, the DCF may be omitted or co-located with the DMF. Accordingly, the DMF may perform some or all of the functions of the DCF. Additionally, the DMF may designate one of the DNFs as an anchor to coordinate the service data for the multiple sub-tasks.

[0095] At 1202 of the procedure 1200, the UE may be in RRC connected state with the RAN. At 1204, the UE may send a task request with task information. The task information may include multiple service types to indicate that the task involves multiple data services. The task information may be transmitted to the DMF (e.g., via the RAN) .

[0096] The DMF may allocate a task ID to the task. Additionally, the DMF may identify that the task involves multiple data services based on the task information. Accordingly, at 1210 of the procedure 1200, the DMF may split the task into a first sub-task (subtask1) and a second sub-task (subtask2) to be serviced by respective DNFs (e.g., DNF #1 and DNF #2 as shown in FIG. 12) . The first and second sub-tasks may be associated with respective sub-task IDs.

[0097] The DMF may establish (e.g., activate) the first subtask at the first DNF and the second subtask at the second DNF. For example, at 1214 of the procedure 1200, the DMF may transmit a first task request to the first DNF. The first task request may include the task ID, the first sub-task ID, task information (e.g., associated with the first sub-task and / or the  whole task) , and / or data service information. Additionally, the first task request may include an indication that the first DNF is designated as the anchor for the task.

[0098] At 1216 of the procedure 1200, the DMF may transmit a second task request to the second DNF. The second task request may include the task ID, the second sub-task ID, task information (e.g., associated with the first sub-task and / or the whole task) , and / or data service information. The second task request may additionally indicate that the first DNF is the anchor for the task.

[0099] At 1218 of the procedure 1200, the first DNF may send a first sub-task configuration to the DMF. The first sub-task configuration may be for the first sub-task to be serviced by the first DNF. At 1220, the second DNF may send a second sub-task configuration to the DMF. The second sub-task configuration may be for the second sub-task to be serviced by the second DNF.

[0100] The DMF may generate a task configuration based on the first and second sub-task configurations. At 1222, the DMF may send the task configuration to the UE (e.g., via the RAN) . At 1224, the UE may send an ACK to confirm receipt of the task configuration.

[0101] At 1226, the DMF may send a message to the DPF to establish a tunnel for the task. The DPF may establish a first service data path between the UE and the first DNF for the first sub-task and a second service path between the UE and the second DNF for the second sub-task.

[0102] At 1228, the UE may exchange (e.g., transmit and / or receive) service data for the first sub-task with the first DNF. At 1230, the UE may exchange service data for the second sub-task with the second DNF.

[0103] At 1232, the second DNF may perform a first level of processing of the data for the second sub-task. At 1234, the second DNF may transmit the generated service data for the second sub-task (e.g., after processing) to the first DNF. At 1236, the DNF (e.g., acting as anchor) may perform a second level of processing (e.g., on the service data for the first and second sub-tasks) . In some embodiments, the second DNF may generate and / or output a task output for the task.

[0104] As discussed above, the DPF may establish a tunnel between one or more DNFs and the UE and / or the RAN. The data routing may be based on the task ID and / or sub-task ID. In some embodiments, the interface between the DPF and the DNFs may be a P2P  interface. In other embodiments, the interface may be a service-based architecture (SBA) interface.

[0105] For some types of services (e.g., area-based data operation that involves multiple UEs) , the task configured for multiple UEs may share the same task ID. Alternatively, different task IDs may be allocated to different UEs, and the DPF may use a common tunnel to route the data.

[0106] For a RAN-level task (e.g., the task is implemented in the RAN) , the DPF may establish a task-specific tunnel between the RAN and the one or more DNFs.

[0107] For a task that involves multiple services (e.g., multiple sub-tasks) , the data for the multiple services and / or sub-tasks may be transmitted within the same tunnel (e.g., via respective service data paths to / from the respective DNFs) . The DPF may establish a common tunnel for multiple services and / or sub-tasks with different QoS profiles.

[0108] FIG. 13 illustrates example tunnels that may be established by the DPF in accordance with some embodiments. For example, a tunnel 1304 may be established for a UE dedicated task. A tunnel 1308 may be established for another UE dedicated task that includes multiple sub-tasks. A tunnel 1312 may be established for a shared task that is shared by multiple UEs (e.g., an area-based task) . A tunnel 1316 may be established for a RAN-level task.

[0109] In various embodiments, the UE and / or RAN may include an adaptation layer in their respective protocol stacks to handle task-based data transmission. The adaptation layer may be referred to as a task data application protocol (TDAP) layer. The TDAP layer may be similar to the SDAP layer used for communication data. However, the PDU of the TDAP layer may include a task ID (e.g., in place of PDU session) and, in some instances, a sub-task ID (e.g., in place of QoS flow) .

[0110] FIG. 14 illustrates example protocol stacks of a UE 1404 and a RAN 1410 in accordance with some embodiments. The UE may include a layer 1 (L1) 1420, which may correspond to the physical (PHY) layer. The UE may further include a layer 2 (L2) 1422, which may handle protocols such as media access control (MAC) , radio link control (RLC) , packet data convergence protocol (PDCP) , and / or service data adaptation protocol (SDAP) . In embodiments, the UE may further include a TDAP layer 1424 to handle task-based communication. For example, the TDAP layer 1424 may include and / or be coupled with a  DNF user plane (UP) component 1426 to interface with a DNF UP component 1428 of a DNF 1430 (e.g., via a DPF 1432) .

[0111] The RAN 1410 may include a L1 1434, a L2 1436, and a TDAP 1438. The TDAP 1438 may interface with the TDAP of the UE and / or with the DNF 1428 to communicate task-based data.

[0112] In some embodiments, the PDCP layer of the associated protocol stack may provide one or more functions for the respective TDAP, such as security protection and / or data compression.

[0113] FIG. 15 illustrates an example of task-based data transmission from a TDAP transmission (Tx) entity 1502 to a TDAP reception (Rx) entity 1504. The TDAP Tx entity 1502 and TDAP Rx entity 1504 may each correspond to a UE, a RAN, a DNF, and / or another component discussed herein.

[0114] At block 1510 of the TDAP Tx entity 1502, the TDAP Tx entity 1502 may receive sub-task data and map the sub-task data to a radio bearer (RB) . If a TDAP header is configured, then block 1512 maps the TDAP header prior to transmission to the TDAP Rx entity 1504. If the TDAP header is not configured, then block 1512 may be bypassed.

[0115] At the TDAP Rx entity 1504, the TDAP header may be removed at block 1514 if one is configured. The received sub-task data is then output.

[0116] FIG. 16 is an operational flow / algorithmic structure 1600 for task-based data service, in accordance with some embodiments. The operational flow / algorithmic structure 1600 may be implemented by a DMF such as, for example, DMF 230, network device 2100, or components thereof, for example, processors 2104A.

[0117] The operational flow / algorithmic structure 1600 may include, at 1604, receiving a task setup request associated with a UE. The task setup request may include task information for a task.

[0118] The operational flow / algorithmic structure 1600 may include, at 1608, generating a task configuration for the task, wherein the task configuration includes a task ID and is associated with one or more DNFs. For example, the task configuration may be generated based on configuration information received from the one or more DNFs.

[0119] The operational flow / algorithmic structure 1600 may further include, at 1612, encoding the task configuration for transmission to the UE to establish a data service path between the UE and the one or more DNFs to service the task.

[0120] FIG. 17 is an operational flow / algorithmic structure 1700 for task-based data service, in accordance with some embodiments. The operational flow / algorithmic structure 1700 may be implemented by a DCF such as, for example, DCF 234, network device 2100, or components thereof, for example, processors 2104A.

[0121] The operational flow / algorithmic structure 1700 may include, at 1704, receiving, from a DMF, task information associated with a task.

[0122] The operational flow / algorithmic structure 1700 may further include, at 1708, splitting the task into multiple sub-tasks to be performed by respective DNFs.

[0123] The operational flow / algorithmic structure 1700 may further include, at 1712, determining sub-task configurations for the respective DNFs. For example, the DCF may receive the sub-task configurations from the respective DNFs.

[0124] The operational flow / algorithmic structure 1700 may further include, at 1716, outputting the sub-task configurations for transmission to the DMF.

[0125] FIG. 18 is an operational flow / algorithmic structure 1800 for task-based data service, in accordance with some embodiments. The operational flow / algorithmic structure 1800 may be implemented by a DPF such as, for example, DPF 232, network device 2100, or components thereof, for example, processors 2104A.

[0126] The operational flow / algorithmic structure 1800 may include, at 1804, receiving, from a DMF, a task configuration associated with a task. The task configuration may include, for example, a task ID and an indication of a DNF to provide a service for the task.

[0127] The operational flow / algorithmic structure 1800 may further include, at 1808, establishing, based on the task configuration, a data service path between a UE and the DNF for transmission of task data.

[0128] FIG. 19 is an operational flow / algorithmic structure 1900 for task-based data service, in accordance with some embodiments. The operational flow / algorithmic structure  1900 may be implemented by a UE such as, for example, UE 104, UE 204, UE 2000, or components thereof, for example, processors 2004A.

[0129] The operational flow / algorithmic structure 1900 may include, at 1904, encoding, for transmission to a network, a task setup request that includes task information.

[0130] The operational flow / algorithmic structure 1900 may further include, at 1908, receiving, based on the task setup request, a task configuration that includes a task ID associated with a data service path between the UE and a DNF to service the task.

[0131] The operational flow / algorithmic structure 1900 may further include, at 1912, encoding task data to or receiving task data from the DNF via the data service path.

[0132] FIG. 20 illustrates a UE 2000 in accordance with some embodiments. The UE 2000 may be similar to and substantially interchangeable with UE 104 and / or UE 204.

[0133] The UE 2000 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, inventory sensors, electric voltage / current meters, or actuators) , video surveillance / monitoring devices (for example, cameras or video cameras) , wearable devices (for example, a smart watch) , or Internet-of-things devices.

[0134] The UE 2000 may include processors 2004, RF interface circuitry 2008, memory / storage 2012, user interface 2016, sensors 2020, driver circuitry 2022, power management integrated circuit (PMIC) 2024, antenna 2026, and battery 2028. The components of the UE 2000 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 20 is intended to show a high-level view of some of the components of the UE 2000. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0135] The components of the UE 2000 may be coupled with various other components over one or more interconnects 2032, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, or optical connection  that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0136] The processors 2004 may include processor circuitry such as, for example, baseband processor circuitry (BB) 2004A, central processor unit circuitry (CPU) 2004B, and graphics processor unit circuitry (GPU) 2004C. The processors 2004 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 2012 to cause the UE 2000 to perform operations as described herein (e.g., operations associated with task-based data services) . The processors 2004 may also include interface circuitry 2004D to communicatively couple the processor circuitry with one or more other components of the UE 2000.

[0137] In some embodiments, the baseband processor 2004A may access a communication protocol stack 2036 in the memory / storage 2012 to communicate over a 3GPP compatible network. In general, the baseband processor 2004A may access the communication protocol stack 2036 to: perform user plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a NAS layer. In some embodiments, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 2008.

[0138] The baseband processor 2004A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some embodiments, the waveforms for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0139] The memory / storage 2012 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 2036) that may be executed by one or more of the processors 2004 to cause the UE 2000 to perform operations as described herein (e.g., operations associated with task-based data services) .

[0140] The memory / storage 2012 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 2000. In some embodiments, some of the memory / storage 2012 may be located on the processors 2004 themselves (for example, memory / storage 2012 may be part of a chipset that corresponds to the baseband processor 2004A) , while other memory / storage 2012 is external to the processors 2004 but accessible  thereto via a memory interface. The memory / storage 2012 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable programmable read only memory (EPROM) , electrically erasable programmable read only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0141] The RF interface circuitry 2008 may include transceiver circuitry and a radio frequency front module (RFEM) that allows the UE 2000 to communicate with other devices over a radio access network. The RF interface circuitry 2008 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, and control circuitry.

[0142] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna 2026 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that down-converts the RF signal into a baseband signal that is provided to the baseband processor of the processors 2004.

[0143] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna 2026.

[0144] In various embodiments, the RF interface circuitry 2008 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0145] The antenna 2026 may include antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna 2026 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna 2026 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, or phased array antennas. The antenna 2026 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0146] The user interface 2016 includes various input / output (I / O) devices designed to enable user interaction with the UE 2000. The user interface 2016 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes (LEDs) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays (LCDs) , LED displays, quantum dot displays, and projectors) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 2000.

[0147] The sensors 2020 may include devices, modules, or subsystems whose purpose is to detect events or changes in their environment and send the information (sensor data) about the detected events to some other device, module, or subsystem. Examples of such sensors include inertia measurement units comprising accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors) ; pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other like audio capture devices.

[0148] The driver circuitry 2022 may include software and hardware elements that operate to control particular devices that are embedded in the UE 2000, attached to the UE 2000, or otherwise communicatively coupled with the UE 2000. The driver circuitry 2022 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 2000. For example, driver circuitry 2022 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 2020 and control and allow access to  sensors 2020, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0149] The PMIC 2024 may manage power provided to various components of the UE 2000. In particular, with respect to the processors 2004, the PMIC 2024 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0150] A battery 2028 may power the UE 2000, although in some examples the UE 2000 may be mounted deployed in a fixed location and may have a power supply coupled to an electrical grid. The battery 2028 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 2028 may be a typical lead-acid automotive battery.

[0151] FIG. 21 illustrates a network device 2100 in accordance with some embodiments. The network device 2100 may be similar to, and substantially interchangeable with, the base station 108, DMF 230, DPF 232, DCF 234, DNFs 236a-c, and / or a component of the CN 112.

[0152] The network device 2100 may include processors 2104, RF interface circuitry 2108 (if implemented as a base station) , core network (CN) interface circuitry 2114, memory / storage circuitry 2112, and antenna structure 2126.

[0153] The components of the network device 2100 may be coupled with various other components over one or more interconnects 2128.

[0154] The processors 2104, RF interface circuitry 2108, memory / storage circuitry 2112 (including communication protocol stack 2110) , antenna structure 2126, and interconnects 2128 may be similar to like-named elements shown and described with respect to FIG. 20.

[0155] The processors 2104 may include processor circuitry such as, for example, baseband processor circuitry (BB) 2104A, central processor unit circuitry (CPU) 2104B, and graphics processor unit circuitry (GPU) 2104C. The processors 2104 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from  memory / storage circuitry 2112 to cause the network device 2100 to perform operations as described herein (e.g., operations associated with task-based data services) . The processors 2104 may also include interface circuitry 2104D to communicatively couple the processor circuitry with one or more other components of the network device 2100.

[0156] The CN interface circuitry 2114 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the network device 2100 via a fiber optic or wireless backhaul. The CN interface circuitry 2114 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 2114 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0157] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0158] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, or network element as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

[0159] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize  risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0160] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, or network element as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

[0161] Examples

[0162] Example 1 may include a method comprising: receiving a task setup request associated with a user equipment (UE) , wherein the task setup request includes task information for a task; generating a task configuration for the task, wherein the task configuration includes a task identifier (ID) and is associated with one or more data network functions (DNFs) ; and encoding the task configuration for transmission to the UE to establish a data service path between the UE and the one or more DNFs to service the task.

[0163] Example 2 may include the method of example 1, wherein the one or more DNFs include a plurality of DNFs, and wherein the further comprises: providing the task information to a data coordination function (DCF) to split the task into multiple sub-tasks to be performed by respective DNFs of the plurality of DNFs; and receiving, from the DCF, sub-task configurations for the respective sub-tasks, wherein the task configuration is generated based on the sub-task configurations.

[0164] Example 3 may include the method of example 1, further comprising providing the task configuration to a data plane function (DPF) to establish the data service path between the UE and the one or more DNFs.

[0165] Example 4 may include the method of example 1, wherein the task information includes one or more data service types.

[0166] Example 5 may include the method of example 1, wherein the task setup request is received from an access and mobility management function (AMF) .

[0167] Example 6 may include the method of example 1, wherein the data service path is separate from a communication path of the UE that is used to communicate user data via a user plane.

[0168] Example 7 may include the method of example 1, wherein the method is performed by a data management function (DMF) .

[0169] Example 8 may include the method of example 7, wherein the DMF is co-located with a session management function (SMF) .

[0170] Example 9 may include the method of example 1, wherein the task is a radio access network (RAN) -level task or an area-level task.

[0171] Example 10 may include a method comprising: receiving, from a data management function (DMF) , task information associated with a task; splitting the task into multiple sub-tasks to be performed by respective data network functions (DNFs) ; determining sub-task configurations for the respective DNFs; and outputting the sub-task configurations for transmission to the DMF.

[0172] Example 11 may include the method of example 10, wherein the task information includes a plurality of data service types, and wherein the task is split into the multiple sub-tasks based on the data service types.

[0173] Example 12 may include the method of example 10, further comprising: receiving subtask data associated with the respective subtasks; processing the subtask data to generate task data; and outputting the task data.

[0174] Example 13 may include the method of example 12, wherein the subtask data is received from the respective DNFs.

[0175] Example 14 may include the method of example 12, wherein the subtask data is received from a radio access network (RAN) .

[0176] Example 15 may include a method comprising: receiving, from a data management function (DMF) , a task configuration associated with a task, wherein the task configuration includes a task identifier (ID) and indicates a data network function (DNF) to provide a service for the task; and establishing, based on the task configuration, a data service path between a user equipment (UE) and the DNF for transmission of task data.

[0177] Example 16 may include the method of example 15, wherein the DNF is a first DNF, wherein the data service path is a first data service path, wherein the task configuration includes a first sub-task configuration associated with the first DNF and a second sub-task configuration associated with a second DNF, and wherein the method further includes establishing a second data service path between the UE and the second DNF based on the second sub-task configuration.

[0178] Example 17 may include the method of example 16, wherein the first and second data service paths are associated with a same tunnel.

[0179] Example 18 may include the method of example 16, wherein the first and second data service paths have different quality of service (QoS) profiles.

[0180] Example 19 may include the method of example 15, wherein the data service path is separate from a communication path of the UE that is used to communicate user data via a user plane.

[0181] Example 20 may include the method of example 15, wherein the data service path is a point-to-point interface or a service-based architecture interface.

[0182] Example 21 may include a method comprising: encoding, for transmission to a network, a task setup request that includes task information; receiving, based on the task setup request, a task configuration that includes a task identifier (ID) associated with a data service path between the UE and a data network function (DNF) to service the task; and encoding task data to or receiving task data from the DNF via the data service path.

[0183] Example 22 may include the method of example 21, wherein the data service path is separate from a communication path of the UE that is used to communicate user data via a user plane.

[0184] Example 23 may include the method of example 21, wherein the task configuration includes multiple sub-task configurations associated with respective sub-tasks of the task, wherein the sub-task configurations include respective sub-task IDs.

[0185] Example 24 may include the method of example 21, wherein the task setup request indicates one or more task types and one or more quality of service (QoS) configurations associated with the task.

[0186] Example 25 may include the method of example 21, wherein the task is a radio access network (RAN) -level task or an area-level task.

[0187] Another example may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-25, or any other method or process described herein.

[0188] Another example may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-25, or any other method or process described herein.

[0189] Another example may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-25, or any other method or process described herein.

[0190] Another example may include a method, technique, or process as described in or related to any of examples 1-25, or portions or parts thereof.

[0191] Another example may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-25, or portions thereof.

[0192] Another example may include a signal as described in or related to any of examples 1-25, or portions or parts thereof.

[0193] Another example may include a datagram, information element, packet, frame, segment, PDU, or message as described in or related to any of examples 1-25, or portions or parts thereof, or otherwise described in the present disclosure.

[0194] Another example may include a signal encoded with data as described in or related to any of examples 1-25, or portions or parts thereof, or otherwise described in the present disclosure.

[0195] Another example may include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described in or related to any of examples 1-25, or portions or parts thereof, or otherwise described in the present disclosure.

[0196] Another example may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-25, or portions thereof.

[0197] Another example may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1-25, or portions thereof.

[0198] Another example may include a signal in a wireless network as shown and described herein.

[0199] Another example may include a method of communicating in a wireless network as shown and described herein.

[0200] Another example may include a system for providing wireless communication as shown and described herein.

[0201] Another example may include a device for providing wireless communication as shown and described herein.

[0202] Any of the above-described examples may be combined with any other example (or combination of examples) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0203] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

A method comprising:receiving a task setup request associated with a user equipment (UE) , wherein the task setup request includes task information for a task;generating a task configuration for the task, wherein the task configuration includes a task identifier (ID) and is associated with one or more data network functions (DNFs) ; andencoding the task configuration for transmission to the UE to establish a data service path between the UE and the one or more DNFs to service the task.The method of claim 1, wherein the one or more DNFs include a plurality of DNFs, and wherein the further comprises:providing the task information to a data coordination function (DCF) to split the task into multiple sub-tasks to be performed by respective DNFs of the plurality of DNFs; andreceiving, from the DCF, sub-task configurations for the respective sub-tasks, wherein the task configuration is generated based on the sub-task configurations.The method of claim 1, further comprising providing the task configuration to a data plane function (DPF) to establish the data service path between the UE and the one or more DNFs.The method of claim 1, wherein the task information includes one or more data service types.The method of claim 1, wherein the task setup request is received from an access and mobility management function (AMF) .The method of claim 1, wherein the data service path is separate from a communication path of the UE that is used to communicate user data via a user plane.The method of claim 1, wherein the method is performed by a data management function (DMF) .The method of claim 7, wherein the DMF is co-located with a session management function (SMF) .The method of claim 1, wherein the task is a radio access network (RAN) -level task or an area-level task.A method comprising:receiving, from a data management function (DMF) , task information associated with a task;splitting the task into multiple sub-tasks to be performed by respective data network functions (DNFs) ;determining sub-task configurations for the respective DNFs; andoutputting the sub-task configurations for transmission to the DMF.The method of claim 10, wherein the task information includes a plurality of data service types, and wherein the task is split into the multiple sub-tasks based on the data service types.The method of claim 10, further comprising:receiving subtask data associated with the respective subtasks;processing the subtask data to generate task data; andoutputting the task data.The method of claim 12, wherein the subtask data is received from the respective DNFs.The method of claim 12, wherein the subtask data is received from a radio access network (RAN) .A method comprising:receiving, from a data management function (DMF) , a task configuration associated with a task, wherein the task configuration includes a task identifier (ID) and indicates a data network function (DNF) to provide a service for the task; andestablishing, based on the task configuration, a data service path between a user equipment (UE) and the DNF for transmission of task data.The method of claim 15, wherein the DNF is a first DNF, wherein the data service path is a first data service path, wherein the task configuration includes a first sub-task configuration associated with the first DNF and a second sub-task configuration associated with a second DNF, and wherein the method further includes establishing a second data service path between the UE and the second DNF based on the second sub-task configuration.The method of claim 16, wherein the first and second data service paths are associated with a same tunnel.The method of claim 16, wherein the first and second data service paths have different quality of service (QoS) profiles.The method of claim 15, wherein the data service path is separate from a communication path of the UE that is used to communicate user data via a user plane.The method of claim 15, wherein the data service path is a point-to-point interface or a service-based architecture interface.A method comprising:encoding, for transmission to a network, a task setup request that includes task information;receiving, based on the task setup request, a task configuration that includes a task identifier (ID) associated with a data service path between the UE and a data network function (DNF) to service the task; andencoding task data to or receiving task data from the DNF via the data service path.The method of claim 21, wherein the data service path is separate from a communication path of the UE that is used to communicate user data via a user plane.The method of claim 21, wherein the task configuration includes multiple sub-task configurations associated with respective sub-tasks of the task, wherein the sub-task configurations include respective sub-task IDs.The method of claim 21, wherein the task setup request indicates one or more task types and one or more quality of service (QoS) configurations associated with the task.The method of claim 21, wherein the task is a radio access network (RAN) -level task or an area-level task.

Images