Data unit in wireless system

Abstract

A user plane function (UPF) sends a universal packet radio service tunneling protocol (GTP) container to an access node, the GTP container comprising a first packet and a GTP header, the GTP header comprising a field indicating that the first packet is one of one or more packets associated with a first data unit of a data stream.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 294,713, filed on December 29, 2021, the entire content of which is hereby incorporated by reference. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Examples of several embodiments of the present disclosure are described herein with reference to the drawings.

[0004] Figure 1A and Figure 1B show an example communication network including an access network and a core network.

[0005] Figure 2A 、 Figure 2B 、 Figure 2C and Figure 2D show various examples of a framework of a service - based architecture within the core network.

[0006] Figure 3 show an example communication network including core network functions.

[0007] Figure 4A and Figure 4B show an example of a core network architecture with multiple user plane functions and untrusted access.

[0008] Figure 5 show an example of a core network architecture for a roaming scenario.

[0009] Figure 6 show an example of a network slice.

[0010] Figure 7A 、 Figure 7B and Figure 7C show a user plane protocol stack, a control plane protocol stack, and services provided between protocol layers of the user plane protocol stack.

[0011] Figure 8 show an example of a quality - of - service model for data exchange.

[0012] Figure 9A 、 Figure 9B 、 Figure 9C and Figure 9D show example states and state transitions of a wireless device.

[0013] Figure 10 show an example of a registration procedure of a wireless device.

[0014] Figure 11 show an example of a service request procedure of a wireless device.

[0015] Figure 12 Shows an example of a protocol data unit session establishment procedure for a wireless device.

[0016] Figure 13 Shows an example of the components of an element in a communication network.

[0017] Figure 14A 、 Figure 14B 、 Figure 14C and Figure 14D Shows various examples of physical core network deployments each having one or more network functions or portions thereof.

[0018] Figure 15 is a diagram of an aspect of an example embodiment of the present disclosure.

[0019] Figure 16 is a diagram of an aspect of an example embodiment of the present disclosure.

[0020] Figure 17 is a diagram of an aspect of an example embodiment of the present disclosure.

[0021] Figure 18 is a diagram of an aspect of an example embodiment of the present disclosure.

[0022] Figure 19 is a diagram of an aspect of an example embodiment of the present disclosure.

[0023] Figure 20 is a diagram of an aspect of an example embodiment of the present disclosure.

[0024] Figure 21 is a diagram of an aspect of an example embodiment of the present disclosure.

[0025] Figure 22 is a diagram of an aspect of an example embodiment of the present disclosure.

[0026] Figure 23 is a diagram of an aspect of an example embodiment of the present disclosure.

[0027] Figure 24 is a diagram of an aspect of an example embodiment of the present disclosure.

[0028] Figure 25 is a diagram of an aspect of an example embodiment of the present disclosure.

[0029] Figure 26 is a diagram of an aspect of an example embodiment of the present disclosure.

[0030] Figure 27 is a diagram of an aspect of an example embodiment of the present disclosure.

[0031] Figure 28 is a diagram of an aspect of an example embodiment of the present disclosure.

[0032] Figure 29A and Figure 29B and Figure 29C are diagrams of aspects of example embodiments of the present disclosure.

[0033] Figure 30 are diagrams of aspects of example embodiments of the present disclosure.

[0034] Figure 31 are diagrams of aspects of example embodiments of the present disclosure.

[0035] Figure 32 are diagrams of aspects of example embodiments of the present disclosure.

[0036] Figure 33 are diagrams of aspects of example embodiments of the present disclosure. Detailed Description

[0037] In the present disclosure, various embodiments are presented in the form of examples of how the disclosed technology can be implemented and / or how the disclosed technology can be practiced in an environment and scenario. It will be apparent to those skilled in the relevant art that various changes in form and detail can be made without departing from the scope of the invention. In fact, after reading the specification, it will be apparent to those skilled in the relevant art how to implement alternative embodiments. The embodiments of the present invention should not be limited by any of the described example embodiments. The embodiments of the present disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments can be combined to create additional embodiments within the scope of the present disclosure. Any diagrams highlighting functionality and advantages are given for illustrative purposes only. The disclosed architecture is flexible and configurable enough such that it can be utilized in a manner different from the way shown. For example, the actions listed in any flowchart can be reordered or used only optionally in certain embodiments.

[0038] Embodiments can be configured to operate as needed. For example, in a wireless device, a base station, a radio environment, a network, a combination of the above, etc., when certain criteria are met, the disclosed mechanisms can be executed. Example criteria can be at least partially based on, for example, wireless device or network node configuration, traffic load, initial system settings, packet size, traffic characteristics, a combination of the above, etc. When one or more criteria are met, various example embodiments can be applied. Thus, example embodiments that selectively implement the disclosed protocol can be implemented.

[0039] A base station can communicate with a mixture of wireless devices. The wireless devices and / or the base station can support multiple technologies and / or multiple versions of the same technology. The wireless devices can have one or more specific capabilities. When the present disclosure refers to a base station communicating with multiple wireless devices, the present disclosure can mean a subset of the total wireless devices in a coverage area. For example, the present disclosure can mean multiple wireless devices having a given capability and a given LTE or 5G version in a given sector of the base station. The multiple wireless devices in the present disclosure can refer to a selected multiple wireless devices, and / or a subset of the total wireless devices in the coverage area that execute according to the disclosed method, etc. There may be multiple base stations or multiple wireless devices in the coverage area that may not conform to the disclosed method. For example, these wireless devices or base stations may execute based on an older version of LTE or 5G technology.

[0040] In the present disclosure, the terms "a" and "an" and similar phrases refer to a single instance of a particular element, but should not be construed as excluding other instances of that element. For example, a bicycle with two wheels can be described as having "a wheel". Any term ending with the suffix "(s)" will be construed as "at least one" and / or "one or more". In the present disclosure, the term "may" is construed as "may, for example". In other words, the term "may" indicates that the phrase following the term "may" is an example of one of the various suitable possibilities that may or may not be used in one or more of the various embodiments. As used herein, the terms "comprising" and "consisting of" enumerate one or more components of the element being described. The term "comprising" is interchangeable with "including" and does not exclude components not enumerated from being included in the element being described. In contrast, "consisting of" provides a complete enumeration of the one or more components of the element being described.

[0041] Phrases such as "based on", "responsive to", "depending on", "employing", "using" and similar phrases indicate the presence and / or influence of a particular factor and / or condition on an event and / or action, but do not exclude the presence and / or influence of uncounted factors and / or conditions on the event and / or action. For example, if action X is performed "based on" condition Y, this is interpreted as performing action X "at least based on" condition Y. For example, if action X is performed when both conditions Y and Z are satisfied, the performance of action X can be described as "based on Y".

[0042] The term "configured" can relate to the capabilities of a device, whether the device is in an operating state or a non-operating state. "Configured" can also mean specific settings within the device that affect the operating characteristics of the device, whether the device is in an operating state or a non-operating state. In other words, hardware, software, firmware, registers, memory values, etc. can be "configured" within the device to provide the device with specific characteristics, whether the device is in an operating state or a non-operating state. The term such as "control message induced in the device" can mean that the control message has parameters that can be used to configure specific characteristics in the device or parameters that can be used to implement certain actions in the device, whether the device is in an operating state or a non-operating state.

[0043] In the present disclosure, a parameter can include one or more information objects, and an information object can include one or more other objects. For example, if parameter J includes parameter K, and parameter K includes parameter L, and parameter L includes parameter M, then J includes L, and J includes M. A parameter can be referred to as a field or an information element. In an exemplary embodiment, when one or more messages include a plurality of parameters, it means that the parameters among the plurality of parameters are in at least one of the one or more messages, but not necessarily in each of the one or more messages.

[0044] The present disclosure can relate to listing possible combinations of elements. For the sake of brevity and readability, the present disclosure does not explicitly recite every permutation that can be obtained by selecting from the group of optional features. The present disclosure should be construed as explicitly disclosing all such permutations. For example, seven possible combinations of listing elements A, B, and C consist of: (1) "A"; (2) "B"; (3) "C"; (4) "A and B"; (5) "A and C"; (6) "B and C"; and (7) "A, B, and C". For the sake of brevity and readability, these seven possible combinations can be described using any of the following interchangeable expressions: "at least one of A, B, and C"; "at least one of A, B, or C"; "one or more of A, B, and C"; "one or more of A, B, or C"; "A, B, and / or C". It should be understood that impossible combinations are excluded. For example, "X and / or non-X" should be construed as "X or non-X". It should also be understood that these expressions can describe alternative phrasings of overlapping and / or synonymous concepts, for example, "identifier, identification, and / or ID number".

[0045] The present disclosure may relate to sets and / or subsets. As an example, a set X may be a collection of elements including one or more elements. If every element of X is also an element of Y, then X may be referred to as a subset of Y. In the present disclosure, only non-empty sets and subsets are considered. For example, if Y consists of the elements Y1, Y2, and Y3, then the possible subsets of Y are {Y1, Y2, Y3}, {Y1, Y2}, {Y1, Y3}, {Y2, Y3}, {Y1}, {Y2}, and {Y3}.

[0046] Figure 1A FIG. shows an example of a communication network 100 in which embodiments of the present disclosure may be implemented. The communication network 100 may include, for example, a public land mobile network (PLMN) operated by a network operator. As Figure 1A shown, the communication network 100 includes a wireless device 101, an access network (AN) 102, a core network (CN) 105, and one or more data networks (DN) 108.

[0047] The wireless device 101 may communicate with the DN 108 via the AN 102 and the CN 105. In the present disclosure, the term wireless device may refer to and encompass any mobile device or fixed (non-mobile) device for which wireless communication is required or may be used. By way of example, the wireless device may be a telephone, a smartphone, a tablet computer, a computer, a laptop computer, a sensor, a meter, a wearable device, an Internet of Things (IoT) device, a vehicle roadside unit (RSU), a relay node, an automobile, a drone, urban air mobility, and / or any combination thereof. The term "wireless device" encompasses other terms including user equipment (UE), user terminal (UT), access terminal (AT), mobile station, handset, wireless transmit and receive unit (WTRU), and / or wireless communication device.

[0048] The AN 102 may connect the wireless device 101 to the CN 105 in any suitable manner. The communication direction from the AN 102 to the wireless device 101 is referred to as the downlink, while the communication direction from the wireless device 101 to the AN 102 is referred to as the uplink. The downlink transmission may be separated from the uplink transmission using frequency division duplexing (FDD), time division duplexing (TDD), and / or some combination of these two duplexing techniques. The AN 102 may be connected to the wireless device 101 via a radio communication connection over an air interface. An access network that operates at least partially via an air interface may be referred to as a radio access network (RAN). The CN 105 may establish one or more end-to-end connections between the wireless device 101 and the one or more DNs 108. The CN 105 may authenticate the wireless device 101 and provide billing functionality.

[0049] In the present disclosure, the term base station may refer to and encompass any element of the AN 102 that facilitates communication between the wireless device 101 and the AN 102. Access networks and base stations have many different names and implementations. A base station may be a land-based base station fixed to the ground. A base station may be a mobile base station with a mobile coverage area. A base station may be in space, such as on a satellite. For example, WiFi and other standards may use the term access point. As another example, the Third Generation Partnership Project (3GPP) has produced specifications for three generations of mobile networks, each of which uses different terms. The third generation (3G) and / or Universal Mobile Telecommunications System (UMTS) standards may use the term Node B. The 4G, Long Term Evolution (LTE), and / or Evolved Universal Terrestrial Radio Access (E-UTRA) standards may use the term evolved Node B (eNB). The 5G and / or New Radio (NR) standards may describe the AN 102 as a Next Generation Radio Access Network (NG-RAN), and may refer to the base station as a Next Generation eNB (ng-eNB) and / or gNB (Generation Node B). Future standards (e.g., 6G, 7G, 8G) may use new terms to refer to the elements that implement the methods described in the present disclosure (e.g., wireless devices, base stations, ANs, CNs, and / or their components). A base station may be implemented as a repeater or relay node for extending the coverage area of a donor node. A repeater node may amplify and rebroadcast a radio signal received from a donor node. A relay node may perform the same / similar function as a repeater node, but may decode the radio signal received from the donor node to remove noise before amplifying and rebroadcasting the radio signal.

[0050] The AN 102 may include one or more base stations, each having one or more coverage areas. The geographical size and / or extent of a coverage area may be defined according to the range within which a recipient of the AN 102 can successfully receive a transmission from a transmitter (e.g., the wireless device 101) operating within the coverage area (and / or vice versa). A coverage area may be referred to as a sector or cell (although in some contexts, the term cell refers to the carrier frequency used in a particular coverage area rather than the coverage area itself). A base station with a large coverage area may be referred to as a macrocell base station. Other base stations cover smaller areas to provide coverage, for example, in areas with weak macrocell coverage or to provide additional coverage in areas with high traffic (sometimes referred to as hotspots). Examples of small cell base stations, in decreasing order of coverage area, include: microcell base stations, picocell base stations, and femtocell base stations or home base stations. The coverage areas of the base stations may together provide wireless coverage to the wireless device 101 over a wide geographical area to support the movement of the wireless device.

[0051] The base station may include one or more sets of antennas for communicating with the wireless device 101 via an air interface. Each set of antennas may be controlled individually by the base station. Each set of antennas may have a corresponding coverage area. As an example, the base station may include three sets of antennas to control three coverage areas on three different sides of the base station, respectively. The entire base station (and its corresponding antennas) may be deployed at a single location. Alternatively, a controller at a central location may control one or more sets of antennas at one or more distributed locations. The controller may be, for example, a baseband processing unit, which is part of a centralized or cloud RAN architecture. The baseband processing unit may be centralized in a pool of baseband processing units or virtualized. A set of antennas at a distributed location may be referred to as a remote radio head (RRH).

[0052] Figure 1B Another example communication network 150 in which embodiments of the present disclosure may be implemented is shown. The communication network 150 may include, for example, a PLMN operated by a network operator. As Figure 1B shown, the communication network 150 includes a UE 151, a Next Generation Radio Access Network (NG-RAN) 152, a 5G Core Network (5G-CN) 155, and one or more DNs 158. The NG-RAN 152 includes one or more base stations, shown as a Next Generation Node B (gNB) 152A and a Next Generation evolved Node B (ng eNB) 152B. The 5G-CN 155 includes one or more network functions (NFs), which include a control plane function 155A and a user plane function 155B. The one or more DNs 158 may include a public DN (e.g., the Internet), a private DN, and / or an in-operator DN. With respect to Figure 1A the corresponding components shown, these components may represent specific embodiments and / or terms.

[0053] The base stations of the NG-RAN 152 may be connected to the UE 151 via the Uu interface. The base stations of the NG-RAN 152 may be connected to each other via the Xn interface. The base stations of the NG-RAN 152 may be connected to the 5G CN 155 via the NG interface. The Uu interface may include an air interface. The NG and Xn interfaces may include an air interface, or may consist of direct physical connections and / or indirect connections via a underlying transport network (e.g., an Internet Protocol (IP) transport network).

[0054] Each of the Uu, Xn, and NG interfaces can be associated with a protocol stack. The protocol stack can include a user plane (UP) and a control plane (CP). Generally, user plane data can include data of the user of UE 151, such as Internet content downloaded via a web browser application, sensor data uploaded via a tracking application, or email data transmitted to or from an email server. In contrast, control plane data can include signaling and messages that facilitate the packaging and routing of user plane data such that it can be exchanged with the DN. For example, the NG interface can be divided into an NG user plane interface (NG-U) and an NG control plane interface (NG-C). The NG-U interface can provide the delivery of user plane data between the base station and the one or more user plane network functions 155B. The NG-C interface can be used for control signaling between the base station and the one or more control plane network functions 155A. The NG-C interface can provide, for example, NG interface management, UE context management, UE mobility management, transmission of NAS messages, paging, PDU session management, and configuration delivery and / or warning message transmission. In some cases, the NG C interface can support the transmission of user data (e.g., small data transmission for IoT devices).

[0055] One or more of the base stations of the NG-RAN 152 can be split into a central unit (CU) and one or more distributed units (DU). The CU can be connected to the one or more DUs via the F1 interface. The CU can process one or more upper layers in the protocol stack, and the DU can process one or more lower layers in the protocol stack. For example, the CU can process RRC, PDCP, and SDAP, and the DU can process RLC, MAC, and PHY. The one or more DUs can be in geographically distinct locations relative to the CU and / or relative to each other. Accordingly, the CU / DU split architecture can allow for increased coverage and / or achieve better coordination.

[0056] The gNB 152A and the ng-eNB 152B can provide different user plane and control plane protocol terminations towards the UE 151. For example, the gNB 154A can provide New Radio (NR) protocol termination via the Uu interface associated with the first protocol stack. The ng eNB 152B can provide Evolved UMTS Terrestrial Radio Access (E-UTRA) protocol termination via the Uu interface associated with the second protocol stack.

[0057] The 5G-CN 155 authenticates the UE 151, sets up an end-to-end connection between the UE 151 and the one or more DNs 158, and provides charging functionality. The 5G-CN 155 may be based on a service-based architecture, where the NFs that make up the 5G-CN 155 provide services to each other via interfaces and provide services to other elements of the communication network 150. The 5G-CN 155 may include any number of other NFs and any number of instances of each NF.

[0058] Figure 2A , Figure 2B , Figure 2C and Figure 2D show various examples of a framework of a service-based architecture within a core network. In a service-based architecture, a service consumer may seek a service, and the service is provided by a service producer. Before obtaining a particular service, an NF may determine where this service can be obtained. To discover a service, an NF may communicate with a Network Repository Function (NRF). As an example, an NF that provides one or more services may register with the Network Repository Function (NRF). The NRF may store data related to the one or more services that the NF is ready to provide to other NFs in the service-based architecture. A consumer NF may query the NRF to discover a producer NF (e.g., by obtaining a list of NF instances that provide a particular service from the NRF).

[0059] In Figure 2A 's example, the NF 211 (in this example, the consumer NF) may send a request 221 to the NF 212 (the producer NF). The request 221 may be a request for a particular service and may be sent based on the discovery that the NF 212 is the producer of the service. The request 221 may include data related to the NF 211 and / or the requested service. The NF 212 may receive the request 221, perform one or more actions associated with the requested service (e.g., retrieve data), and provide a response 222. The one or more actions performed by the NF212 may be based on the request data included in the request 221, the data stored by the NF 212, and / or the data retrieved by the NF 212. The response 222 may notify the NF 211 that the one or more actions have been completed. The response 222 may include response data related to the NF 212, the one or more actions, and / or the requested service.

[0060] In Figure 2B 's example, the NF 231 sends a request 241 to the NF 232. In this example, part of the service produced by the NF 232 will be to send a request 242 to the NF 233. The NF 233 may perform one or more actions and provide a response 243 to the NF 232. Based on the response 243, the NF 232 may send a response 244 to the NF 231. FromFigure 2B It will be understood that a single NF may perform the role of a service producer, a service consumer, or both. A particular NF service may include any number of nested NF services produced by one or more other NFs.

[0061] Figure 2C An example of a subscription-notification interaction between a consumer NF and a producer NF is shown. In Figure 2C , NF 251 sends subscription 261 to NF 252. NF 253 sends subscription 262 to NF 252. For illustrative purposes, two NFs are shown in Figure 2C (to show that NF 252 may provide multiple subscription services to different NFs), but it should be understood that the subscription-notification interaction only requires one subscriber. NF 251 and 253 may be independent of each other. For example, NF 251 and 253 may independently discover NF 252 and / or independently determine to subscribe to the services provided by NF 252. In response to receiving the subscription, NF 252 may provide a notification to the subscribing NF. For example, NF 252 may send notification 263 to NF 251 based on subscription 261, and may send notification 264 to NF 253 based on subscription 262.

[0062] As Figure 2C shown in the example illustration of, the sending of notifications 263 and 264 may be based on determining that a certain condition has occurred. For example, notifications 263 and 264 may be based on determining that a specific event has occurred, determining that a specific condition is pending, and / or determining that a duration associated with the subscription has elapsed (e.g., the period associated with a subscription for periodic notifications). As Figure 2C shown in the example illustration of, NF 252 may send notifications 263 and 264 to NF 251 and 253 simultaneously and / or in response to the same condition. However, it should be understood that NF 252 may provide notifications at different times and / or in response to different notification conditions. In the example, NF 251 may request a notification when a specific parameter measured by NF 252 exceeds a first threshold, and NF 252 may request a notification when the parameter exceeds a second threshold different from the first threshold. In the example, the parameter of interest and / or the corresponding threshold may be indicated in subscriptions 261 and 262.

[0063] Figure 2D Another example of a subscription-notification interaction is shown. Figure 2D In, NF 271 sends subscription 281 to NF 272. In response to receiving subscription 281 and / or determining that a notification condition has occurred, NF 272 may send notification 284. Notification 284 may be sent to NF 273. Different from the example in Figure 2C (where the notification is sent to the subscribing NF), Figure 2DIt is shown that subscriptions and their corresponding notifications can be associated with different NFs. For example, NF 271 can represent that NF 273 subscribes to the service provided by NF 272.

[0064] Figure 3 Another example communication network 300 in which embodiments of the present disclosure can be implemented is shown. Communication network 300 includes a user equipment (UE) 301, an access network (AN) 302, and a data network (DN) 308. Figure 3 The remaining elements depicted therein can be included in and / or associated with the core network. Each element of the core network can be referred to as a network function (NF).

[0065] Figure 3 The NFs depicted therein include a user plane function (UPF) 305, an access and mobility management function (AMF) 312, a session management function (SMF) 314, a policy control function (PCF) 320, a network repository function (NRF) 330, a network exposure function (NEF) 340, a unified data management (UDM) 350, an authentication server function (AUSF) 360, a network slice selection function (NSSF) 370, a charging function (CHF) 380, a network data analytics function (NWDAF) 390, and an application function (AF) 399. UPF 305 can be a user plane core network function, while NFs 312, 314, and 320 - 390 can be control plane core network functions. Although Figure 3 not illustrated in the example of, the core network can include the depicted NFs and / or additional instances of any of one or more different NF types that provide different services. Other examples of NF types include a gateway mobile location center (GMLC), a location management function (LMF), an operation, administration, and maintenance function (OAM), a public warning system (PWS), a short message service function (SMSF), a unified data repository (UDR), and an unstructured data storage function (UDSF).

[0066] Figure 3 Each element depicted therein has an interface with at least one other element. The interface can be a logical connection, rather than, for example, a direct physical connection. Any interface can be identified using a reference point representation and / or a service - based representation. In a reference point representation, a letter 'N' followed by a number indicates the interface between two specific elements. For example, as Figure 3As shown, AN 302 and UPF 305 are interfaced via 'N3', while UPF 305 and DN 308 are interfaced via 'N6'. In contrast, in the service-based representation, the letter 'N' is followed by a letter. The letter identifies the NF that provides services to the core network. For example, PCF 320 can provide services via the interface 'Npcf'. PCF 320 can provide services to any NF in the core network via 'Npcf'. Accordingly, the service-based representation can correspond to a set of reference point representations. For example, the Npcf interface between PCF 320 and the core network generally corresponds to the N7 interface between PCF 320 and SMF 314, the N30 interface between PCF 320 and NEF 340, and so on.

[0067] UPF 305 can act as a gateway for user plane traffic between AN 302 and DN 308. UE 301 can be connected to UPF 305 via the Uu interface and the N3 interface (also described as the NG U interface). UPF 305 can be connected to DN308 via the N6 interface. UPF 305 can be connected to one or more other UPFs (not shown) via the N9 interface. UE 301 can be configured to receive services via a protocol data unit (PDU) session, which is a logical connection between UE 301 and DN 308. UPF 305 (or, as needed, multiple UPFs) can be selected by SMF 314 to handle a specific PDU session between UE 301 and DN 308. SMF 314 can control the functions of UPF 305 with respect to the PDU session. SMF 314 can be connected to UPF305 via the N4 interface. UPF 305 can handle any number of PDU sessions associated with any number of UEs (via any number of ANs). For the purpose of handling the one or more PDU sessions, UPF 305 can be controlled by any number of SMFs via any number of corresponding N4 interfaces.

[0068] Figure 3 The AMF 312 depicted in can control the access of the UE to the core network. UE 301 can register with the network via AMF 312. UE 301 may have to register before establishing a PDU session. AMF 312 can manage the registration area of UE 301, enabling the network to track the physical location of UE 301 within the network. For a UE in the connected mode, AMF 312 can manage UE mobility, such as a handover from one AN or a part thereof to another AN. For a UE in the idle mode, AMF 312 can perform a registration update and / or page the UE to transition the UE to the connected mode.

[0069] The AMF 312 can receive non-access stratum (NAS) messages transmitted according to the NAS protocol from the UE 301. The NAS messages relate to the communication between the UE 301 and the core network. Although the NAS messages can be relayed to the AMF 312 via the AN 302, they can be described as communication via the N1 interface. The NAS messages can facilitate UE registration and mobility management, for example, by authenticating, identifying, configuring, and / or managing the connection of the UE 301. The NAS messages can support session management procedures for maintaining user plane connectivity and quality of service (QoS) for the session between the UE 301 and the DN 309. If the NAS message relates to session management, the AMF 312 can send the NAS message to the SMF 314. The NAS messages can be used to convey messages between the UE 301 and other components of the core network (e.g., core network components other than the AMF 312 and the SMF 314). The AMF 312 can act on a particular NAS message itself or forward the NAS message to an appropriate core network function (e.g., the SMF 314, etc.).

[0070] Figure 3 The SMF 314 depicted in can establish, modify, and / or release PDU sessions based on the message traffic received at the UE 301. The SMF 314 can, for example, allocate, manage, and / or assign an IP address to the UE 301 after establishing a PDU session. There can be multiple SMFs in the network, each of which can be associated with a corresponding group of wireless devices, base stations, and / or UPFs. A UE with multiple PDU sessions can be associated with a different SMF for each PDU session. As described above, the SMF 314 can select one or more UPFs to handle the PDU session and can control the handling of the PDU session by the selected UPF by providing rules for packet handling (PDR, FAR, QER, etc.). Rules related to the QoS and / or charging of a particular PDU session can be obtained from the PCF 320 and provided to the UPF 305.

[0071] The PCF 320 can provide services related to policy rules to other NFs. The PCF 320 can use subscription data and information about network conditions to determine policy rules and then provide the policy rules to a particular NF that can be responsible for enforcing those rules. The policy rules can relate to policy control for access and mobility and can be enforced by the AMF. The policy rules can relate to session management and can be enforced by the SMF 314. The policy rules can be (e.g.) network-specific, wireless device-specific, session-specific, or data flow-specific.

[0072] The NRF 330 can provide service discovery. The NRF 330 can belong to a specific PLMN. The NRF 330 can maintain an NF profile related to other NFs in the communication network 300. The NF profile can include, for example, the address of the NF, the PLMN and / or type, a slice identifier, a list of the one or more services provided by the NF, and the authorization required for access services.

[0073] Figure 3 The NEF 340 depicted in can provide an interface to an external domain, allowing the external domain to selectively access the control plane of the communication network 300. The external domain can include, for example, third-party network functions, application functions, etc. The NEF 340 can act as a proxy between an external element and network functions such as the AMF 312, SMF 314, PCF 320, UDM 350, etc. As an example, the NEF 340 can determine the location or reachability status of the UE 301 based on a report from the AMF 312 and provide the status information to an external element. As an example, an external element can provide information via the NEF 340 to facilitate setting parameters for establishing a PDU session. The NEF 340 can determine which data and capabilities of the control plane are open to the external domain. The NEF 340 can provide secure openings that authenticate and / or authorize external entities to which data or capabilities of the communication network 300 are opened. The NEF 340 can selectively control the openings such that the internal architecture of the core network is hidden from the external domain.

[0074] The UDM 350 can provide data storage for other NFs. The UDM 350 can allow a consolidated view of network information, which can be used to ensure that most relevant information is available to different NFs from a single resource. The UDM 350 can store and / or retrieve information from a Unified Data Repository (UDR). For example, the UDM 350 can obtain user subscription data related to the UE 301 from the UDR.

[0075] The AUSF 360 can support mutual authentication of the core network to the UE 301 and authentication of the UE 301 to the core network. The AUSF 360 can execute a key agreement procedure and provide key material that can be used to improve security.

[0076] The NSSF 370 can select one or more network slices to be used by the UE 301. The NSSF 370 can select slices based on slice selection information. For example, the NSSF 370 can receive a single Network Slice Selection Assistance Information (S-NSSAI) and map the S-NSSAI to a Network Slice Instance Identifier (NSI).

[0077] CHF 380 can control charging-related tasks associated with UE 301. For example, UPF 305 can report service usage associated with UE 301 to SMF 314. SMF 314 can collect usage data from UPF 305 and one or more other UPFs. The usage data can indicate how much data is exchanged, with what DN the data is exchanged, the network slice associated with the data, or any other information that may affect charging. SMF 314 can share the collected usage data with CHF. CHF can use the collected usage data to perform charging-related tasks associated with UE 301. CHF can instruct SMF 314 to restrict or affect the access of UE 301 and / or provide charging-related notifications to UE 301 depending on the charging status of UE 301.

[0078] NWDAF 390 can collect and analyze data from other network functions and provide data analysis services to other network functions. As an example, NWDAF 390 can collect data related to the load levels of specific network slice instances from UPF 305, AMF 312, and / or SMF 314. Based on the collected data, NWDAF 390 can provide load level data to PCF 320 and / or NSSF 370, and / or notify PC220 and / or NSSF 370 whether the load level of the slice has reached and / or exceeded the load level threshold.

[0079] AF 399 can be external to the core network but can interact with the core network to provide information about QoS requirements or service routing preferences associated with a specific application. AF 399 can access the core network based on open constraints imposed by NEF 340. However, the operator of the core network can consider AF 399 as a trusted domain that can directly access the network.

[0080] Figure 4A 、 4B and 5 show other examples of core network architectures that are in some aspects similar to Figure 3 the core network architecture 300 depicted in Figure 3 . For the sake of brevity, some core network elements depicted in Figure 4A 、 4B and 5 are in some aspects similar to Figure 3 the elements depicted in . For the sake of brevity, some details related to their functions or operations are omitted.

[0081] Figure 4AAn example of a core network architecture 400A showing an arrangement including multiple UPFs is presented. The core network architecture 400A includes a UE 401, an AN 402, an AMF 412, and an SMF 414. Different from the previous examples of the core network architecture described above, Figure 4A depicts multiple UPFs including UPF 405, UPF 406, and UPF 407, and multiple DNs including DN 408 and DN 409. Each of the multiple UPFs 405, 406, 407 can communicate with the SMF 414 via the N4 interface. The DNs 408, 409 communicate with the UPFs 405, 406 via the N6 interface respectively. As Figure 4A shown, the multiple UPFs 405, 406, 407 can communicate with each other via the N9 interface.

[0082] The UPFs 405, 406, 407 can perform traffic detection, where the UPF identifies and / or classifies packets. Packet identification can be performed based on the packet detection rules (PDRs) provided by the SMF 414. The PDR can contain packet detection information including one or more of the following: source interface, UE IP address, core network (CN) tunnel information (e.g., the CN address corresponding to the N3 / N9 tunnel of the PDU session), network instance identifier, quality of service flow identifier (QFI), filtering set (e.g., IP packet filtering set or Ethernet packet filtering set), and / or application identifier.

[0083] In addition to indicating how a specific packet will be detected, the PDR can further indicate rules for processing the packet after it is detected. The rules can include (for example) a forwarding action rule (FAR), a multi-access rule (MAR), a usage reporting rule (URR), a QoS enforcement rule (QER), etc. For example, the PDR can include one or more FAR identifiers, MAR identifiers, URR identifiers, and / or QER identifiers. These identifiers can indicate the rules specified for processing the detected specific packet.

[0084] The UPF 405 can perform traffic forwarding according to the FAR. For example, the FAR can indicate that packets associated with a specific PDR will be forwarded, copied, discarded, and / or buffered. The FAR can indicate the destination interface, such as "access" for the downlink or "core" for the uplink. If a packet is to be buffered, the FAR can indicate a buffering action rule (BAR). As an example, the UPF 405 can perform data buffering of a specific number of downlink packets in the case of releasing a PDU session.

[0085] The UPF 405 may perform QoS enforcement according to the QER. For example, the QER may indicate an authorized guaranteed bit rate and / or a maximum bit rate to be enforced for packets associated with a specific PDR. The QER may indicate that a specific guaranteed and / or maximum bit rate may be used for uplink packets and / or downlink packets. The UPF 405 may mark packets belonging to a specific QoS flow with a corresponding QFI. The marking may enable the recipient of the packet to determine the QoS of the packet.

[0086] The UPF 405 may provide usage reports to the SMF 414 according to the URR. The URR may indicate one or more trigger conditions for the generation and reporting of usage reports, such as immediate reporting, periodic reporting, a threshold for incoming uplink traffic, or any other suitable trigger condition. The URR may indicate methods for measuring the usage of network resources, such as data volume, duration, and / or events.

[0087] As described above, the DNs 408, 409 may include a public DN (e.g., the Internet), a private DN (e.g., a private, internally company-owned DN), and / or an in-operator DN. Each DN may provide operator services and / or third-party services. The services provided by the DN may be the Internet, an IP Multimedia Subsystem (IMS), an augmented or virtual reality network, an edge computing or Mobile Edge Computing (MEC) network, etc. Each DN may be identified using a Data Network Name (DNN). The UE 401 may be configured to establish a first logical connection (first PDU session) with the DN 408, a second logical connection (second PDU session) with the DN 409, or both (first and second PDU sessions) simultaneously.

[0088] Each PDU session may be associated with at least one UPF configured to operate as a PDU session anchor (PSA or "anchor"). The anchor may be a UPF that provides the N6 interface to the DN.

[0089] In Figure 4AIn the example, UPF 405 can be the anchor for the first PDU session between UE 401 and DN 408, while UPF 406 can be the anchor for the second PDU session between UE 401 and DN 409. The core network can use the anchor to provide service continuity (e.g., IP address continuity) of a specific PDU session as UE 401 moves from one access network to another. For example, assume that UE 401 establishes a PDU session using a data path to DN 408 using an access network other than AN 402. The data path can include UPF 405 acting as the anchor. Further assume that UE 401 later moves into the coverage area of AN 402. In this scenario, SMF 414 can select a new UPF (UPF 407) to bridge the gap between the newly entered access network (AN 402) and the anchor UPF (UPF 405). The continuity of the PDU session can be maintained as any number of UPFs are added or removed from the data path. When a UPF is added to the data path, as Figure 4A shown, it can be described as an intermediate UPF and / or a cascaded UPF.

[0090] As described above, UPF 406 can be the anchor for the second PDU session between UE 401 and DN 409. Although Figure 4A the anchors for the first and second PDU sessions are associated with different UPFs in the example, it should be understood that this is only an example. It will also be understood that multiple PDU sessions with a single DN can correspond to any number of anchors. When there are multiple UPFs, the UPF at the branching point (UPF 407 in Figure 4) can operate as an uplink classifier (UL-CL). The UL-CL can divert uplink user plane traffic to different UPFs.

[0091] The SMF 414 may, for example, allocate, manage, and / or assign IP addresses to the UE 401 after the establishment of a PDU session. The SMF 414 may maintain an internal pool of IP addresses to be assigned. When necessary, the SMF 414 may assign IP addresses provided by a Dynamic Host Configuration Protocol (DHCP) server or an Authentication, Authorization, and Accounting (AAA) server. IP address management may be performed according to the Session and Service Continuity (SSC) mode. In SSC mode 1, the IP address of the UE 401 may be maintained as the wireless device moves within the network (and the same anchored UPF may be used). In SSC mode 2, the IP address of the UE 401 changes as the UE 401 moves within the network (e.g., the old IP address and UPF may be discarded, and a new IP address and anchored UPF may be established). In SSC mode 3, it is possible to temporarily maintain the old IP address (similar to SSC mode 1) when establishing a new IP address (similar to SSC mode 2), thus combining the characteristics of SSC mode 1 and 2. Applications sensitive to IP address changes may operate according to SSC mode 1.

[0092] The UPF selection may be controlled by the SMF 414. For example, after the establishment and / or modification of a PDU session between the UE 401 and the DN 408, the SMF 414 may select the UPF 405 as the anchor for the PDU session and / or select the UPF 407 as an intermediate UPF. The criteria for UPF selection include the path efficiency and / or speed between the AN 402 and the DN 408. The reliability, load status, location, slice support, and / or other capabilities of candidate UPFs may also be considered.

[0093] Figure 4B An example of a core network architecture 400B adapted to untrusted access is shown. Similar to Figure 4A , as Figure 4B depicted, the UE 401 is connected to the DN 408 via the AN 402 and the UPF 405. The AN 402 and the UPF 405 constitute a trusted (e.g., 3GPP) access to the DN 408. In contrast, the UE 401 may also access the DN 408 using an untrusted access network, the AN 403, and a Non-3GPP Network Interworking Function (N3IWF) 404.

[0094] AN 403 can be, for example, a Wireless Local Area Network (WLAN) operating according to the IEEE 802.11 standard. The UE401 can be connected to the AN 403 via interface Y1 in whatever way specified by the AN 403. The connection to the AN 403 may or may not involve authentication. The UE 401 can obtain an IP address from the AN 403. The UE 401 can determine to connect to the core network 400B and for this purpose select untrusted access. The AN 403 can communicate with the N3IWF 404 via the Y2 interface. After selecting untrusted access, the UE 401 can provide the N3IWF 404 with sufficient information to select an AMF. The selected AMF can be, for example, the same AMF (in the current example, AMF 412) used by the UE 401 for 3GPP access. The N3IWF 404 can communicate with the AMF 412 via the N2 interface. A UPF 405 can be selected, and the N3IWF 404 can communicate with the UPF 405 via the N3 interface. The UPF 405 can be a PDU session anchor (PSA) and remains the anchor for the PDU session even as the UE 401 transitions between trusted and untrusted access.

[0095] Figure 5 An example of a core network architecture 500 in which the UE 501 is in a roaming scenario is shown. In the roaming scenario, the UE 501 is a subscriber of a first PLMN (home PLMN or HPLMN) but is attached to a second PLMN (visiting PLMN or VPLMN). The core network architecture 500 includes the UE 501, the AN 502, the UPF 505, and the DN 508. The AN 502 and the UPF 505 can be associated with the VPLMN. The VPLMN can manage the AN 502 and the UPF 505 using core network elements associated with the VPLMN, the core network elements including the AMF 512, the SMF 514, the PCF 520, the NRF 530, the NEF 540, and the NSSF 570. The AF 599 can be adjacent to the core network of the VPLMN.

[0096] The UE 501 may not be a subscriber of the VPLMN. The AMF 512 can authorize the UE 501 to access the network based on, for example, roaming restrictions imposed on the UE 501. To obtain network services provided by the VPLMN, the core network of the VPLMN may have to interact with core network elements of the HPLMN of the UE 501, specifically the PCF 521, the NRF 531, the NEF 541, the UDM 551, and / or the AUSF 561. The VPLMN and the HPLMN can communicate using the N32 interface connecting the respective Secure Edge Protection Proxy (SEPP). In Figure 5Among them, the corresponding SEPPs are depicted as VSEPP 590 and HSEPP 591.

[0097] VSEPP 590 and HSEPP 591 communicate via the N32 interface for the defined purposes while hiding information about each PLMN from another PLMN. The SEPP can apply roaming policies based on the communication via the N32 interface. PCF 520 and PCF 521 can communicate via the SEPP to exchange policy-related signaling. NRF 530 and NRF 531 can communicate via the SEPP to enable service discovery of NFs in the corresponding PLMN. The VPLMN and HPLMN can independently maintain NEF 540 and NEF 541. NSSF 570 and NSSF 571 can communicate via the SEPP to coordinate slice selection for UE 501. The HPLMN can handle all authentication and subscription-related signaling. For example, when UE 501 registers or requests services via the VPLMN, the VPLMN can authenticate UE 501 and / or obtain the subscription data of UE 501 by accessing UDM 551 and AUSF 561 of the HPLMN via the SEPP.

[0098] Figure 5 The core network architecture 500 depicted in it can be referred to as a local breakout configuration, where UE 501 uses one or more UPFs (i.e., UPF 505) of the VPLMN to access the DN 508. However, other configurations are possible. For example, in a home-routed configuration ( Figure 5 not shown in it), UE 501 can use one or more UPFs of the HPLMN to access the DN. In the home-routed configuration, the N9 interface can operate in parallel with the N32 interface, crossing the boundary between the VPLMN and HPLMN to carry user plane data. One or more SMFs of the corresponding PLMN can communicate via the N32 interface to coordinate session management for UE 501. The SMF can control its corresponding UPF on either side of the boundary.

[0099] Figure 6 An example of a network slice is shown. A network slice can refer to dividing a shared infrastructure (e.g., physical infrastructure) into different logical networks. These different logical networks can be controlled independently, isolated from each other, and / or associated with dedicated resources.

[0100] Network architecture 600A shows a non-sliced physical network corresponding to a single logical network. Network architecture 600A includes a user plane, where UEs 601A, 601B, 601C (collectively referred to as UEs 601) have physical and logical connections via AN 602 and UPF 605 to DN 608. Network architecture 600A includes a control plane, where AMF 612 and SMF 614 control various aspects of the user plane.

[0101] Network architecture 600A can have a specific set of characteristics (e.g., related to maximum bit rate, reliability, latency, bandwidth usage, power consumption, etc.). This set of characteristics can be affected by the nature of the network elements themselves (e.g., processing power, availability of free memory, proximity to other network elements, etc.) or their management (e.g., optimized to maximize bit rate or reliability, reduce latency or power bandwidth usage, etc.). The characteristics of network architecture 600A can change over time, for example, by upgrading the equipment or by modifying the program to target specific characteristics. However, at any given time, network architecture 600A will have a single set of characteristics that may or may not be optimized for a specific use case. For example, UEs 601A, 601B, 601C may have different requirements, but network architecture 600A can be optimized for only one of the three.

[0102] Network architecture 600B is an example of a sliced physical network divided into multiple logical networks. Figure 6 In it, the physical network is divided into three logical networks, called slice A, slice B, and slice C. For example, UE 601A can be served by AN 602A, UPF 605A, AMF 612, and SMF 614A. UE 601B can be served by AN 602B, UPF 605B, AMF 612, and SMF 614B. UE 601C can be served by AN 602C, UPF 605C, AMF 612, and SMF 614C. Although from a logical perspective, the corresponding UEs 601 communicate with different network elements, these network elements can be deployed by the network operator using the same physical network elements.

[0103] Each network slice can be customized for network services with different sets of characteristics. For example, slice A can correspond to enhanced mobile broadband (eMBB) services. Mobile broadband can refer to Internet access by mobile users typically associated with smartphones. Slice B can correspond to ultra-reliable low-latency communication (URLLC), which focuses on reliability and speed. Relative to eMBB, URLLC can improve the feasibility of use cases such as autonomous driving and remote surgery. Slice C can correspond to massive machine-type communication (mMTC), which focuses on low-power services delivered to a large number of users. For example, slice C can be optimized for a dense network of battery-powered sensors that provide a small amount of data at regular intervals. Many mMTC use cases would be prohibitively expensive when operating over an eMBB or URLLC network.

[0104] If the service requirements for one of the UEs 601 change, the network slice serving the UE can be updated to provide better service. In addition, the sets of network characteristics corresponding to eMBB, URLLC, and mMTC can vary such that different varieties of eMBB, URLLC, and mMTC are provided. Alternatively, the network operator can provide entirely new services in response to, for example, customer demand.

[0105] Figure 6 In, each of the UEs 601 has its own network slice. However, it should be understood that a single slice can serve any number of UEs, and a single UE can operate using any number of slices. In addition, in the example network architecture 600B, the AN602, UPF 605, and SMF 614 are divided into three separate slices, while the AMF 612 is non-sliced. However, it should be understood that the network operator can deploy any architecture that selectively utilizes any mix of sliced and non-sliced network elements, where different network elements are divided into different numbers of slices. Although Figure 6 only three core network functions are depicted, it should be understood that other core network functions can also be sliced. A PLMN that supports multiple network slices can maintain a separate network repository function (NRF) for each slice, enabling other NFs to discover the network services associated with the slice.

[0106] The network slice selection may be controlled by the AMF or by a separate network slice selection function (NSSF). For example, a network operator may define and implement distinct network slice instances (NSIs). Each NSI may be associated with a single network slice selection assistance information (S NSSAI). The S NSSAI may include a specific slice / service type (SST) indicator (indicating eMBB, URLLC, mMTC, etc.). As an example, a specific tracking area may be associated with one or more configured S-NSSAIs. The UE may identify one or more requested and / or subscribed S NSSAIs (e.g., during registration). The network may indicate one or more allowed and / or rejected S NSSAIs to the UE.

[0107] The S NSSAI may further include a slice differentiator (SD) to distinguish different tenants of a particular slice and / or service type. For example, a tenant may be a customer (e.g., a vehicle manufacturer, a service provider, etc.) of a network operator that obtains (e.g., purchases) guaranteed network resources and / or specific policies for handling its subscribers. The network operator may configure different slices and / or slice types and use the SD to determine which tenant is associated with a particular slice.

[0108] Figure 7A , Figure 7B and Figure 7C A user plane (UP) protocol stack, a control plane (CP) protocol stack, and services provided between protocol layers of the UP protocol stack are shown.

[0109] The layers may be associated with an open systems interconnection (OSI) model of computer networking functionality. In the OSI model, layer 1 may correspond to the bottom layer, with higher layers on top of the bottom layer. Layer 1 may correspond to the physical layer, which is related to the physical infrastructure (e.g., cables, optical fibers, and / or radio frequency transceivers) used to transmit signals. In a new radio (NR), layer 1 may include a physical layer (PHY). Layer 2 may correspond to a data link layer. Layer 2 may be related to packaging data (e.g., into data frames) for transmission between nodes of a network using the physical infrastructure of layer 1. In NR, layer 2 may include a media access control layer (MAC), a radio link control layer (RLC), a packet data convergence layer (PDCP), and a service data application protocol layer (SDAP).

[0110] Layer 3 may correspond to the network layer. Layer 3 may be related to the routing of data encapsulated in layer 2. Layer 3 may handle the prioritization of data and traffic avoidance. In NR, layer 3 may include a Radio Resource Control layer (RRC) and a Non-Access Stratum layer (NAS). Layers 4 through 7 may correspond to the transport layer, session layer, presentation layer, and application layer. The application layer interacts with the end user to provide data associated with the application. In an example, the end user implementing the application may generate data associated with the application and initiate the transmission of the information to a target data network (e.g., the Internet, an application server, etc.). Starting at the application layer, each layer in the OSI model may manipulate and / or repackage the information and deliver it to the lower layer. At the lowest layer, the manipulated and / or repackaged information may be exchanged via a physical infrastructure (e.g., electrically, optically, and / or electromagnetically). As it approaches the target data network, the information will be unpackaged and provided to increasingly higher layers until it reaches the application layer again in a form available to the target data network (e.g., the same form as when it was provided by the end user). In response to the end user, the data network may perform this procedure in reverse.

[0111] Figure 7A Illustrates a user plane protocol stack. The user plane protocol stack may be a New Radio (NR) protocol stack for the Uu interface between UE 701 and gNB 702. In layer 1 of the UP protocol stack, UE 701 may implement PHY 731 and gNB 702 may implement PHY 732. In layer 2 of the UP protocol stack, UE 701 may implement MAC 741, RLC 751, PDCP 761, and SDAP 771. gNB 702 may implement MAC 742, RLC 752, PDCP 762, and SDAP 772.

[0112] Figure 7B Illustrates a control plane protocol stack. The control plane protocol stack may be an NR protocol stack for the Uu interface between UE 701 and gNB 702 and / or the N1 interface between UE 701 and AMF 712. In layer 1 of the CP protocol stack, UE 701 may implement PHY 731 and gNB 702 may implement PHY 732. In layer 2 of the CP protocol stack, UE 701 may implement MAC 741, RLC 751, PDCP 761, RRC 781, and NAS 791. gNB 702 may implement MAC 742, RLC 752, PDCP 762, and RRC 782. AMF 712 may implement NAS 792.

[0113] The NAS may be related to the non-access stratum, specifically, the communication between the UE 701 and the core network (e.g., the AMF 712). The lower layer may be related to the access stratum, such as the communication between the UE 701 and the gNB 702. The messages sent between the UE 701 and the core network may be referred to as NAS messages. In the example, the NAS messages may be relayed by the gNB 702, but the content of the NAS messages (e.g., the information elements of the NAS messages) may be invisible to the gNB 702.

[0114] Figure 7C Shows a setting in Figure 7A An example of a service between protocol layers of the NR user plane protocol stack shown in. The UE 701 may receive services via a PDU session, which may be a logical connection between the UE 701 and a data network (DN). The UE 701 and the DN may exchange data packets associated with the PDU session. The PDU session may include one or more quality of service (QoS) flows. The SDAP 771 and the SDAP 772 may perform mapping and / or demapping between the one or more QoS flows of the PDU session and one or more radio bearers (e.g., data radio bearers). The mapping between the QoS flow and the data radio bearer may be determined by the gNB 702 in the SDAP 772, and the UE 701 may be notified of the mapping (e.g., based on control signaling and / or reflective mapping). For reflective mapping, the SDAP 772 of the gNB 220 may mark the downlink packet with a QoS flow identifier (QFI) and deliver the downlink packet to the UE 701. The UE 701 may determine the mapping based on the QFI of the downlink packet.

[0115] The PDCP 761 and the PDCP 762 may perform header compression and / or decompression. Header compression may reduce the amount of data transmitted on the physical layer. The PDCP 761 and the PDCP 762 may perform encryption and / or decryption. Encryption may reduce the unauthorized decoding of the data transmitted on the physical layer (e.g., intercepted on the air interface) and protect data integrity (e.g., to ensure control messages from a given source). The PDCP 761 and the PDCP 762 may perform retransmission of undelivered packets, in-order delivery and reordering of packets, duplication of packets, and / or identification and removal of duplicate packets. In a dual connectivity scenario, the PDCP 761 and the PDCP 762 may perform mapping between split radio bearers and RLC channels.

[0116] RLC 751 and RLC 752 can perform segmentation and retransmission via automatic repeat request (ARQ). RLC 751 and RLC 752 can respectively perform removal of duplicate data units received from MAC 741 and MAC 742. RLC 213 and 223 can respectively provide the RLC channels as services to PDCP 214 and 224.

[0117] MAC 741 and MAC 742 can perform multiplexing and / or demultiplexing of logical channels. MAC 741 and MAC 742 can map logical channels to transport channels. In an example, UE 701 can multiplex data units of one or more logical channels into transport blocks in MAC 741. UE 701 can use PHY 731 to transmit the transport blocks to gNB 702. gNB 702 can use PHY 732 to receive the transport blocks and demultiplex the data units of the transport blocks back into logical channels. MAC 741 and MAC742 can perform error correction via hybrid automatic repeat request (HARQ), logical channel prioritization, and / or padding.

[0118] PHY 731 and PHY 732 can perform mapping of transport channels to physical channels. PHY 731 and PHY 732 can perform digital and analog signal processing functions (e.g., encoding / decoding and modulation / demodulation) for sending and receiving information (e.g., transmission via the air interface). PHY 731 and PHY 732 can perform multi-antenna mapping.

[0119] Figure 8 An example of a quality of service (QoS) model for differentiated data exchange is shown. In Figure 8 the QoS model, there are UE 801, AN 802, and UPF 805. The QoS model facilitates prioritization of certain packets or protocol data units (PDUs) (also referred to as packets). For example, higher-priority packets can be exchanged faster and / or more reliably compared to lower-priority packets. The network can allocate more resources to exchange high-QoS packets.

[0120] In Figure 8In the example of, a PDU session 810 is established between the UE 801 and the UPF 805. The PDU session 810 can be a logical connection that enables the UE 801 to exchange data with a specific data network (such as the Internet). The UE 801 may request the establishment of the PDU session 810. When establishing the PDU session 810, the UE 801 can identify the target data network based on, for example, its data network name (DNN). The PDU session 810 can be managed by, for example, a session management function (SMF, not shown). To facilitate the exchange of data associated with the PDU session 810 between the UE 801 and the data network, the SMF can select the UPF 805 (and optionally, one or more other UPFs, not shown).

[0121] One or more applications associated with the UE 801 can generate uplink packets 812A - 812E associated with the PDU session 810. To operate within the QoS model, the UE 801 can apply QoS rules 814 to the uplink packets 812A - 812E. The QoS rules 814 can be associated with the PDU session 810 and can be determined and / or provided to the UE 801 when establishing and / or modifying the PDU session 810. Based on the QoS rules 814, the UE 801 can classify the uplink packets 812A - 812E, map each of the uplink packets 812A - 812E to a QoS flow, and / or mark the uplink packets 812A - 812E with a QoS flow indicator (QFI). As the packets travel through the network and potentially mix with other packets from other UEs with potentially different priorities, the QFI indicates how the packets should be processed according to the QoS model. In the current illustration, the uplink packets 812A, 812B are mapped to the QoS flow 816A, the uplink packet 812C is mapped to the QoS flow 816B, and the remaining packets are mapped to the QoS flow 816C.

[0122] A QoS flow can be the finest granularity of QoS differentiation within a PDU session. In the figure, three QoS flows 816A - 816C are shown. However, it should be understood that any number of QoS flows can exist. Some QoS flows can be associated with a guaranteed bit rate (GBR QoS flow), and other QoS flows can have an unguaranteed bit rate (non - GBR QoS flow). QoS flows can also be subject to per - UE and per - session aggregate bit rates. One of the QoS flows can be a default QoS flow. QoS flows can have different priorities. For example, QoS flow 816A can have a higher priority than QoS flow 816B, and QoS flow 816B can have a higher priority than QoS flow 816C. The different priorities can be reflected by different QoS flow characteristics. For example, a QoS flow can be associated with a flow bit rate. A particular QoS flow can be associated with a guaranteed flow bit rate (GFBR) and / or a maximum flow bit rate (MFBR). A QoS flow can be associated with a particular packet delay budget (PDB), packet error rate (PER), and / or maximum packet loss rate. QoS flows can also be subject to per - UE and per - session aggregate bit rates.

[0123] To operate within the QoS model, the UE 801 can apply resource mapping rules 818 to the QoS flows 816A - 816C. The air interface between the UE 801 and the AN 802 can be associated with resources 820. In the current illustration, QoS flow 816A is mapped to resource 820A, while QoS flows 816B, 816C are mapped to resource 820B. The resource mapping rules 818 can be provided by the AN 802. To meet the QoS requirements, the resource mapping rules 818 can specify more resources for relatively high - priority QoS flows. In the case of more resources, high - priority QoS flows such as QoS flow 816A are more likely to obtain a high flow bit rate, a low packet delay budget, or other characteristics associated with the QoS rule 814. The resources 820 can include, for example, radio bearers. A radio bearer (e.g., a data radio bearer) can be established between the UE 801 and the AN 802. The 5G radio bearer between the UE 801 and the AN 802 can be different from the LTE bearer, such as the evolved packet system (EPS) bearer between the UE and the packet data network gateway (PGW), the S1 bearer between the eNB and the serving gateway (SGW), and / or the S5 / S8 bearer between the SGW and the PGW.

[0124] Once a packet associated with a specific QoS flow is received at the AN 802 via resource 820A or resource 820B, the AN 802 can separate the packet into the corresponding QoS flows 856A - 856C based on the QoS profile 828. The QoS profile 828 can be received from the SMF. Each QoS profile can correspond to a QFI, such as the QFI marked on the uplink packets 812A - 812E. Each QoS profile can contain QoS parameters such as, for example, a 5G QoS identifier (5QI) and an allocation and retention priority (ARP). The QoS profile for a non - GBR QoS flow can further contain additional QoS parameters such as, for example, a reflected QoS attribute (RQA). The QoS profile for a GBR QoS flow can further contain additional QoS parameters such as, for example, a guaranteed flow bit rate (GFBR), a maximum flow bit rate (MFBR), and / or a maximum packet loss rate. The 5QI can be a standardized 5QI, which has a one - to - one mapping of each well - known service to a standardized combination of 5G QoS characteristics. The 5QI can be a dynamically assigned 5QI, whose standardized 5QI value is not defined. The 5QI can represent 5G QoS characteristics. The 5QI can include a resource type, a default priority, a packet delay budget (PDB), a packet error rate (PER), a maximum data burst volume, and / or an average window. The resource type can indicate a non - GBR QoS flow, a GBR QoS flow, or a latency - critical GBR QoS flow. The average window can represent the duration over which the GFBR and / or MFBR are calculated. The ARP can be a priority that includes a pre - emption capability and a pre - empted capability. Based on the ARP, the AN 802 can apply admission control for the QoS flow in case of resource constraints.

[0125] The AN 802 can select one or more N3 tunnels 850 for transmitting the QoS flows 856A - 856C. After the packet is partitioned into the QoS flows 856A - 856C, the packet can be sent to the UPF 805 (e.g., towards the DN) via the selected one or more N3 tunnels 850. The UPF 805 can verify that the QFI of the uplink packets 812A - 812E aligns with the QoS rules 814 provided to the UE 801. The UPF 805 can measure the packet and / or count the packet and / or provide the packet metrics to, for example, the PCF.

[0126] The figure also shows the process for the downlink. Specifically, one or more applications may generate downlink packets 852A - 852E. The UPF 805 may receive the downlink packets 852A - 852E from one or more DNs and / or one or more other UPFs. According to the QoS model, the UPF 805 may apply a packet detection rule (PDR) 854 to the downlink packets 852A - 852E. Based on the PDR 854, the UPF 805 may map the packets 852A - 852E into QoS flows. In the current illustration, the downlink packets 852A, 852B are mapped to the QoS flow 856A, the downlink packet 852C is mapped to the QoS flow 856B, and the remaining packets are mapped to the QoS flow 856C.

[0127] The QoS flows 856A - 856C may be sent to the AN 802. The AN 802 may apply a resource mapping rule to the QoS flows 856A - 856C. In the current illustration, the QoS flow 856A is mapped to the resource 820A, while the QoS flows 856B, 856C are mapped to the resource 820B. To meet the QoS requirements, the resource mapping rule may specify more resources for the high - priority QoS flows.

[0128] Figures 9A to 9D Examples of the states and state transitions of a wireless device (e.g., UE) are shown. At any given time, a wireless device may have a radio resource control (RRC) state, a registration management (RM) state, and a connection management (CM) state.

[0129] Figure 9A It is an example schema showing the RRC state transition of a wireless device (e.g., UE). The UE may be in one of the following three RRC states: RRC idle 910 (e.g., RRC_IDLE), RRC inactive 920 (e.g., RRC_INACTIVE), or RRC connected 930 (e.g., RRC_CONNECTED). The UE may implement different RAN - related control plane procedures depending on its RRC state. Other elements of the network (e.g., base stations) may track the RRC state of one or more UEs and implement RAN - related control plane procedures suitable for the RRC state of each UE.

[0130] In the RRC connection 930, it is possible for the UE to exchange data with the network (e.g., a base station). The parameters necessary for establishing the data exchange can be established, and these parameters are known to both the UE and the network. The parameters can be mentioned and / or included in the RRC context of the UE (sometimes referred to as the UE context). These parameters can include, for example: one or more AS contexts; one or more radio link configuration parameters; bearer configuration information (e.g., related to data radio bearers, signaling radio bearers, logical channels, QoS flows, and / or PDU sessions); security information; and / or PHY, MAC, RLC, PDCP, and / or SDAP layer configuration information. The base station connected to the UE can store the RRC context of the UE.

[0131] When in the RRC connection 930, the mobility of the UE can be managed by the access network, while the UE itself can manage mobility when in RRC idle 910 and / or RRC inactive 920. When in the RRC connection 930, the UE can manage mobility by measuring the signal levels (e.g., reference signal levels) from the serving cell and neighboring cells and reporting these measurements to the base station currently serving the UE. The network can initiate a handover based on the reported measurements. The RRC state can transition from the RRC connection 930 to the RRC idle 910 via the connection release procedure 930, and to the RRC inactive 920 via the connection suspension procedure 932.

[0132] In the RRC idle 910, no RRC context is established for the UE. In the RRC idle 910, the UE does not have an RRC connection with the base station. When in the RRC idle 910, the UE can be in a dormant state most of the time (e.g., to save battery power). The UE can wake up periodically (e.g., once per discontinuous reception cycle) to monitor paging messages from the access network. The mobility of the UE can be managed by the UE through a procedure called cell reselection. The RRC state can transition from the RRC idle 910 to the RRC connection 930 via the connection establishment procedure 913, which can involve a random access procedure, as discussed in more detail below.

[0133] In the RRC inactive 920, the previously established RRC context is maintained in both the UE and the base station. This can allow for a faster transition to the RRC connection 930 with reduced signaling overhead compared to a transition from the RRC idle 910 to the RRC connection 930. The RRC state can transition to the RRC connection 930 via the connection resume procedure 923. The RRC state can transition to the RRC idle 910 via a connection release procedure 921 that can be the same as or similar to the connection release procedure 931.

[0134] The RRC state can be associated with the mobility management mechanism. In RRC idle 910 and RRC inactive 920, mobility can be managed by the UE via cell reselection. The purpose of mobility management in RRC idle 910 and / or RRC inactive 920 is to allow the network to be able to notify the UE of an event via a paging message without having to broadcast the paging message across the entire mobile communication network. The mobility management mechanism used in RRC idle 910 and / or RRC inactive 920 can allow the network to track the UE at the cell-group level such that the paging message can be broadcast on the cells of the cell group where the UE is currently camped rather than across the entire communication network. The tracking can be based on different packet granularities. For example, there can be three levels of cell packet granularity: an individual cell; cells within a RAN area identified by a RAN area identifier (RAI); and cells within a group of RAN areas called a tracking area and identified by a tracking area identifier (TAI).

[0135] The tracking area can be used to track the UE at the CN level. The CN can provide the UE with a list of TAIs associated with the UE's registration area. If the UE moves to a cell associated with a TAI that is not included in the list of TAIs associated with the UE's registration area via cell reselection, the UE can perform a registration update to the CN to allow the CN to update the UE's location and provide the UE with a new UE registration area.

[0136] The RAN area can be used to track the UE at the RAN level. For a UE in the RRC inactive 920 state, a RAN notification area can be assigned to the UE. The RAN notification area can include a list of one or more cell identities, RAI, and / or TAI. In an example, a base station can belong to one or more RAN notification areas. In an example, a cell can belong to one or more RAN notification areas. If the UE moves to a cell not included in the RAN notification area assigned to the UE via cell reselection, the UE can perform a notification area update to the RAN to update the UE's RAN notification area.

[0137] The base station that stores the RRC context for the UE or the UE's last serving base station can be referred to as the anchor base station. The anchor base station can maintain the RRC context of the UE at least for the time period during which the UE remains in the RAN notification area of the anchor base station and / or for the time period during which the UE remains in RRC inactive 920.

[0138] Figure 9B is an example diagram showing the registration management (RM) state transitions of a wireless device (e.g., UE). The states are RM deregistration 940 (e.g., RM-DEREGISTERED) and RM registration 950 (e.g., RM-REGISTERED).

[0139] In RM de-registration 940, the UE is not registered with the network and the network is not reachable to the UE. To be reachable by the network, the UE must perform an initial registration. As an example, the UE may register with the AMF of the network. If the registration is rejected (registration rejection 944), the UE remains in RM de-registration 940. If the registration is accepted (registration acceptance 945), the UE transitions to RM registration 950. When the UE is in RM registration 950, the network may store, hold, and / or maintain the UE context of the UE. The UE context may be referred to as the radio device context. The UE context corresponding to network registration (maintained by the core network) may be different from the RRC context corresponding to the RRC state (maintained by the access network such as a base station, etc.). The UE context may include the UE identifier and a record of various information related to the UE, such as UE capability information, policy information for access and mobility management of the UE, a list of allowed or established slices or PDU sessions, and / or the registration area of the UE (i.e., a list of tracking areas covering the geographical area where the radio device is likely to be found).

[0140] When the UE is in RM registration 950, the network may store the UE context of the UE and use the UE context to reach the UE when necessary. In addition, some services cannot be provided by the network unless the UE is registered. The UE may update its UE context (registration update acceptance 955) while remaining in RM registration 950. For example, if the UE leaves one tracking area and enters another tracking area, the UE may provide the tracking area identifier to the network. The network may de-register the UE, or the UE may de-register itself (deregistration 954). For example, the network may automatically de-register the radio device if the radio device has been in an inactive state for a specific amount of time. After deregistration, the UE may transition to RM de-registration 940.

[0141] Figure 9C It is an example diagram showing the connection management (CM) state transition of a radio device (e.g., UE) from the perspective of the radio device. The UE may be in CM idle 960 (e.g., CM-idle (CM-IDLE)) or CM connected 970 (e.g., CM-connected (CM-CONNECTED)).

[0142] In CM Idle 960, the UE does not have a non-access stratum (NAS) signaling connection with the network. Thus, the UE may not communicate with core network functions. The UE may transition to CM Connected 970 by establishing an AN signaling connection (AN Signaling Connection Establishment 967). This transition may be initiated by sending an initial NAS message. The initial NAS message may be a registration request (e.g., if the UE is in RM Deregistered 940) or a service request (e.g., if the UE is in RM Registered 950). If the UE is in RM Registered 950, the UE may initiate AN signaling connection establishment by sending a service request, or the network may send a paging, thereby triggering the UE to send a service request.

[0143] In CM Connected 970, the UE may communicate with core network functions using NAS signaling. As an example, the UE may exchange NAS signaling with the AMF for registration management purposes, service request procedures, and / or authentication procedures. As another example, the UE may exchange NAS signaling with the SMF to establish and / or modify a PDU session. The network may disconnect the UE, or the UE may disconnect itself (AN Signaling Connection Release 976). For example, if the UE transitions to RM Deregistered 940, the UE may also transition to CM Idle 960. When the UE transitions to CM Idle 960, the network may release the user plane connection of the UE's PDU session.

[0144] Figure 9D is an example schema showing the CM state transitions of a wireless device (e.g., UE) from the network perspective (e.g., AMF). The CM state of the UE tracked by the AMF may be in CM Idle 980 (e.g., CM-IDLE) or CM Connected 990 (e.g., CM-CONNECTED). When the UE transitions from CM Idle 980 to CM Connected 990, the AMF may establish the UE's N2 context (N2 Context Establishment 989). When the UE transitions from CM Connected 990 to CM Idle 980, the AMF may release the UE's N2 context (N2 Context Release 998).

[0145] Figures 10 - 12 shows example procedures for UE registration, service request, and PDU session establishment.

[0146] Figure 10 shows an example of the registration procedure of a wireless device (e.g., UE). Based on the registration procedure, the UE may transition from, for example, RM Deregistered 940 to RM Registered 950.

[0147] Registration may be initiated by the UE for purposes such as obtaining authorization for receiving services, enabling mobility tracking, enabling reachability, or other purposes. The UE may perform an initial registration as the first step to connect to the network (e.g., when the UE is powered on, the flight mode is disconnected, etc.). Registration may also be performed periodically to keep the network aware of the UE's presence (e.g., when in the CM-IDLE state), or in response to changes in UE capabilities or the registration area. Deregistration ( Figure 10 not shown in

[0148] may be performed to stop network access. At 1010, the UE transmits a registration request to the AN. As an example, the UE may have moved from the coverage area of a previous AMF (shown as AMF#1) to the coverage area of a new AMF (shown as AMF#2). The registration request may be a NAS message. The registration request may contain a UE identifier. The AN may select an AMF for the UE's registration. For example, the AN may select the default AMF. For example, the AN may select the AMF that has been mapped to the UE (e.g., the previous AMF). The NAS registration request may contain a network slice identifier, and the AN may select an AMF based on the requested slice. After selecting the AMF, the AN may send the registration request to the selected AMF.

[0149] At 1020, the AMF (AMF#2) that receives the registration request performs context transfer. The context may be a UE context, such as the RRC context of the UE. As an example, AMF#2 may send a message requesting the context of the UE to AMF#1. The message may contain a UE identifier. The message may be a Namf_Communication_UEContextTransfer message. AMF#1 may send a message containing the requested UE context to AMF#2. This message may be a Namf_Communication_UEContextTransfer message. After receiving the UE context, AMF#2 may coordinate the authentication of the UE. After the authentication is completed, AMF#2 may send a message indicating the completion of the UE context transfer to AMF#1. This message may be a Namf_Communication_UEContextTransfer response message.

[0150] Authentication may require the participation of the UE, AUSF, UDM, and / or UDR (not shown). For example, the AMF may request the AUSF to authenticate the UE. For example, the AUSF may perform the authentication of the UE. For example, the AUSF may obtain authentication data from the UDM. For example, the AUSF may send the Subscription Permanent Identifier (SUPI) to the AMF based on successful authentication. For example, the AUSF may provide an intermediate key to the AMF. The intermediate key can be used to derive the access-specific security key of the UE, enabling the AMF to perform security context management (SCM). The AUSF may obtain subscription data from the UDM. The subscription data may be based on information obtained from the UDM (and / or UDR). The subscription data may include a subscription identifier, security credentials, access and mobility-related subscription data, and / or session-related data.

[0151] At 1030, the new AMF (AMF#2) registers and / or subscribes to the UDM. AMF#2 may use the UE context management service of the UDM (Nudm_UECM) to perform the registration. AMF#2 may use the subscriber data management service of the UDM (Nudm_SDM) to obtain the subscription information of the UE. AMF#2 may further request the UDM to notify AMF#2 whether the subscription information of the UE has changed. As the new AMF registers and subscribes, the old AMF (AMF#1) may deregister and unsubscribe. After deregistration, AMF#1 has no responsibility for the mobility management of the UE.

[0152] At 1040, AMF#2 retrieves the access and mobility (AM) policy from the PCF. As an example, AMF#2 may provide the subscription data of the UE to the PCF. The PCF may determine the access and mobility policy for the UE based on the subscription data, network operator data, current network conditions, and / or other suitable information. For example, the owner of the first UE may purchase a higher level of service than the owner of the second UE. The PCF may provide rules associated with different service levels. Based on the subscription data of the corresponding UE, the network may apply different policies to facilitate different service levels.

[0153] For example, the access and mobility policies may relate to service area restrictions, RAT / frequency selection priorities (RFSP, where RAT stands for radio access technology), authorization and prioritization of access types (e.g., LTE versus NR), and / or selection of non-3GPP access (e.g., access network discovery and selection policy (ANDSP)). The service area restrictions may include a list of tracking areas in which serving the UE is allowed (not allowed). The access and mobility policies may include a UE routing selection policy (URSP) that affects the routing of an established or new PDU session. As described above, different policies may be obtained and / or enforced based on the UE's subscription data, the UE's location (i.e., the location of the AN and / or AMF), or other suitable factors.

[0154] At 1050, AMF#2 may update the context of the PDU session. For example, if the UE has an existing PDU session, AMF#2 may coordinate with the SMF to activate the user plane connection associated with the existing PDU session. The SMF may update and / or release the session management context of the PDU session (Nsmf_PDUSession_UpdateSMContext, Nsmf_PDUSession_ReleaseSMContext).

[0155] At 1060, AMF#2 sends a registration acceptance message to the AN, and the AN forwards the registration acceptance message to the UE. The registration acceptance message may include a new UE identifier and / or a new configured slice identifier. The UE may transmit a registration complete message to the AN, and the AN forwards the registration complete message to AMF#2. The registration complete message may confirm receipt of the new UE identifier and / or the new configured slice identifier.

[0156] At 1070, AMF#2 may obtain UE policy control information from the PCF. The PCF may provide an access network discovery and selection policy (ANDSP) for non-3GPP access. The PCF may provide a UE routing selection policy (URSP) for mapping specific data traffic to specific PDU session connectivity parameters. As an example, the URSP may indicate that data traffic associated with a specific application should be mapped to a specific SSC mode, network slice, PDU session type, or preferred access type (3GPP or non-3GPP).

[0157] Figure 11 An example of a service request procedure for a wireless device (e.g., a UE) is shown. Figure 11 The service request procedure depicted is a network-triggered service request procedure for a UE in the CM-IDLE state. However, reference may also be made to Figure 11Understanding other service request procedures (e.g., UE-triggered service request procedures) will be discussed in more detail below.

[0158] At 1110, the UPF receives data. The data can be downlink data for transmission to the UE. The data can be associated with an existing PDU session between the UE and the DN. The data can be received, for example, from the DN and / or another UPF. The UPF can buffer the received data. In response to receiving the data, the UPF can notify the SMF of the received data. The identity of the SMF to be notified can be determined based on the received data. The notification can be, for example, an N4 session report. The notification can indicate that the UPF has received data associated with the UE and / or a specific PDU session associated with the UE. In response to receiving the notification, the SMF can send PDU session information to the AMF. The PDU session information can be sent in an N1N2 messaging for forwarding to the AN. The PDU session information can include, for example, UPF tunnel endpoint information and / or QoS information.

[0159] At 1120, the AMF determines that the UE is in the CM-IDLE state. The determination at 1120 can be in response to receiving the PDU session information. Based on the determination that the UE is in CM-IDLE, the service request procedure can proceed to 1130 and 1140, as Figure 11 depicted. However, if the UE is not in CM-IDLE (e.g., the UE is in CM-CONNECTED), then 1130 and 1140 can be skipped, and the service request procedure can proceed directly to 1150.

[0160] At 1130, the AMF pages the UE. The paging at 1130 can be performed based on the UE being in CM-IDLE. To perform the paging, the AMF can send the paging to the AN. The paging can be referred to as a paging or a paging message. The paging can be an N2 request message. The AN can be one of multiple ANs in the RAN notification area of the UE. The AN can send the paging to the UE. The UE can be in the coverage area of the AN and can receive the paging.

[0161] At 1140, the UE can request service. The UE can transmit a service request to the AMF via the AN. As Figure 11 depicted, the UE can request service at 1140 in response to receiving the paging at 1130. However, as described above, this is a specific case for a network-triggered service request procedure. In some scenarios (e.g., if uplink data becomes available at the UE), the UE can initiate a UE-triggered service request procedure. The UE-triggered service request procedure can start at 1140.

[0162] At 1150, the network may authenticate the UE. The authentication may require the participation of the UE, AUSF, and / or UDM, for example, similar to the authentication described elsewhere in this disclosure. In some cases (e.g., if the UE has been recently authenticated), the authentication at 1150 may be skipped.

[0163] At 1160, the AMF and SMF may perform a PDU session update. As part of the PDU session update, the SMF may provide one or more UPF tunnel endpoint identifiers to the AMF. In some cases ( Figure 11 not illustrated), the SMF may have to coordinate with one or more other SMFs and / or one or more other UPFs to set up the user plane.

[0164] At 1170, the AMF may send the PDU session information to the AN. The PDU session information may be included in an N2 request message. Based on the PDU session information, the AN may configure the user plane resources for the UE. To configure the user plane resources, the AN may, for example, perform an RRC reconfiguration of the UE. The AN may confirm to the AMF that the PDU session information has been received. The AN may notify the AMF that the user plane resources have been configured, and / or provide information related to the user plane resource configuration.

[0165] In the case of a UE-triggered service request procedure, the UE may receive a NAS service acceptance message from the AMF via the AN at 1170. After the user plane resources are configured, the UE may transmit uplink data (e.g., the uplink data that caused the UE to trigger the service request procedure).

[0166] At 1180, the AMF may update the session management (SM) context of the PDU session. For example, the AMF may notify the SMF (and / or one or more other associated SMFs) that the user plane resources have been configured, and / or provide information related to the user plane resource configuration. The AMF may provide one or more AN tunnel endpoint identifiers of the AN to the SMF (and / or one or more other associated SMFs). After the SM context update is complete, the SMF may send an updated SM context response message to the AMF.

[0167] Based on the update of the session management context, the SMF may update the PCF for policy control purposes. For example, if the location of the UE has changed, the SMF may notify the PCF of the new location of the UE.

[0168] Based on the update of the session management context, the SMF and the UPF can perform session modification. The session modification can be performed using the N4 session modification message. After the session modification is completed, the UPF can transmit downlink data (e.g., downlink data that causes the UPF to trigger a network-triggered service request procedure) to the UE. The transmission of the downlink data can be based on the one or more AN tunnel endpoint identifiers of the AN.

[0169] Figure 12 An example of a protocol data unit (PDU) session establishment procedure for a wireless device (e.g., a UE) is shown. The UE can determine to transmit a PDU session establishment request to create a new PDU session, handover an existing PDU session to a 3GPP network, or for any other suitable reason.

[0170] At 1210, the UE initiates a PDU session establishment. The UE can transmit the PDU session establishment request to the AMF via the AN. The PDU session establishment request can be a NAS message. The PDU session establishment request can indicate: the PDU session ID; the requested PDU session type (new or existing); the requested DNN (DNN); the requested network slice (S NSSAI); the requested SSC mode; and / or any other suitable information. The PDU session ID can be generated by the UE. The PDU session type can be (for example) an Internet Protocol (IP)-based type (e.g., IPv4, IPv6, or dual-stack IPv4 / IPv6), an Ethernet type, or an unstructured type.

[0171] The AMF can select the SMF based on the PDU session establishment request. In some scenarios, the requested PDU session may already be associated with a specific SMF. For example, the AMF can store the UE context of the UE, and the UE context can indicate that the PDU session ID of the requested PDU session is already associated with a specific SMF. In some scenarios, the AMF can select the SMF based on determining that the SMF is ready to handle the requested PDU session. For example, the requested PDU session may be associated with a specific DNN and / or S NSSAI, and the SMF can be selected based on determining that the SMF can manage the PDU session associated with the specific DNN and / or S NSSAI.

[0172] At 1220, the context of the network management PDU session. After selecting the SMF at 1210, the AMF sends a PDU session context request to the SMF. The PDU session context request may include the PDU session establishment request received from the UE at 1210. The PDU session context request can be an Nsmf_PDUSession_CreateSMContext request and / or an Nsmf_PDUSession_UpdateSMContext request. The PDU session context request may indicate the identifier of the UE; the requested DN; and / or the requested network slice. Based on the PDU session context request, the SMF may retrieve the subscription data from the UDM. The subscription data can be the session management subscription data of the UE. The SMF may subscribe to updates of the subscription data so that the PCF will send new information in case the subscription data of the UE changes. After obtaining the subscription data of the UE, the SMF may transmit a PDU session context response to the AMG. The PDU session context response can be an Nsmf_PDUSession_CreateSMContext response and / or an Nsmf_PDUSession_UpdateSMContext response. The PDU session context response may include the session management context ID.

[0173] At 1230, secondary authorization / authentication may be performed if necessary. The secondary authorization / authentication may involve the UE, the AMF, the SMF, and the DN. The SMF may access the DN via a Data Network Authentication, Authorization, and Accounting (DN AAA) server.

[0174] At 1240, the network sets up the data path for the uplink data associated with the PDU session. The SMF may select the PCF and establish a session management policy association. Based on the association, the PCF may provide an initial set of Policy and Charging Control (PCC) rules for the PDU session. When targeting a specific PDU session, the PCF may indicate to the SMF the method for allocating an IP address to the PDU session, the default charging method for the PDU session, the address of the corresponding charging entity, the triggers for requesting new policies, etc. The PCF may also target a Service Data Flow (SDF) that includes one or more PDU sessions. When targeting the SDF, the PCF may indicate to the SMF the policies for applying QoS requirements, monitoring traffic (e.g., for charging purposes), and / or diverting traffic (e.g., by using one or more specific N6 interfaces).

[0175] The SMF may determine and / or allocate an IP address for the PDU session. The SMF may select one or more UPFs (at Figure 12In the example, a single UPF is used to handle the PDU session. The SMF may send N4 session messages to the selected UPF. The N4 session messages may be N4 session establishment requests and / or N4 session modification requests. The N4 session messages may contain packet detection, enforcement, and reporting rules associated with the PDU session. In response, the UPF may confirm by sending an N4 session establishment response and / or an N4 session modification response.

[0176] The SMF may send PDU session management information to the AMF. The PDU session management information may be a session service request (e.g., Namf_Communication_N1N2MessageTransfer) message. The PDU session management information may contain the PDU session ID. The PDU session management information may be a NAS message. The PDU session management information may contain N1 session management information and / or N2 session management information. The N1 session management information may contain a PDU session establishment acceptance message. The PDU session establishment acceptance message may contain tunneling endpoint information of the UPF and quality of service (QoS) information associated with the PDU session.

[0177] The AMF may send an N2 request to the AN. The N2 request may contain a PDU session establishment acceptance message. Based on the N2 request, the AN may determine AN resources for the UE. The AN resources may be used by the UE to establish a PDU session with the DN via the AN. The AN may determine the resources to be used for the PDU session and indicate the determined resources to the UE. The AN may send a PDU session establishment acceptance message to the UE. For example, the AN may perform RRC reconfiguration of the UE. After setting the AN resources, the AN may send an N2 request confirmation to the AMF. The N2 request confirmation may contain N2 session management information, such as the PDU session ID and tunneling endpoint information of the AN.

[0178] After setting the data path for uplink data at 1240, the UE may optionally send uplink data associated with the PDU session. As Figure 12 shown, the uplink data may be sent via the AN and the UPF to the DN associated with the PDU session.

[0179] At 1250, the network may update the PDU session context. The AMF may transmit a PDU session context update request to the SMF. The PDU session context update request may be an Nsmf_PDUSession_UpdateSMContext request. The PDU session context update request may contain N2 session management information received from the AN. The SMF may confirm the PDU session context update. The confirmation may be an Nsmf_PDUSession_UpdateSMContext response. The confirmation may contain a subscription to request the SMF to notify any UE mobility events. Based on the PDU session context update request, the SMF may send an N4 session message to the UPF. The N4 session message may be an N4 session modification request. The N4 session message may contain the tunneling endpoint information of the AN. The N4 session message may contain the forwarding rules associated with the PDU session. In response, the UPF may confirm by sending an N4 session modification response.

[0180] After the UPF receives the tunneling endpoint information of the AN, the UPF may relay the downlink data associated with the PDU session. As Figure 12 shown, the downlink data may be received from the DN associated with the PDU session via the AN and the UPF.

[0181] Figure 13 An example of a component showing the elements in a communication network. Figure 13 Includes a physical deployment 1330 of a wireless device 1310, a base station 1320, and one or more network functions (hereinafter "deployment 1330"). Any wireless device described in this disclosure may have similar components and may be implemented in a manner similar to the wireless device 1310. Any other base station (or any part thereof, depending on the architecture of the base station) described in this disclosure may have similar components and may be implemented in a manner similar to the base station 1320. Any physical core network deployment (or any part thereof, depending on the architecture of the base station) in this disclosure may have similar components and may be implemented in a manner similar to the deployment 1330.

[0182] The wireless device 1310 may communicate with the base station 1320 via the air interface 1370. The communication direction from the wireless device 1310 to the base station 1320 via the air interface 1370 is referred to as the uplink, and the communication direction from the base station 1320 to the wireless device 1310 via the air interface 1370 is referred to as the downlink. The downlink transmission may be separated from the uplink transmission using a certain combination of FDD, TDD, and / or duplex technologies. Figure 13 Shows a single wireless device 1310 and a single base station 1320, but it should be understood that the wireless device 1310 may communicate with any number of base stations or other access network components via the air interface 1370, and the base station 1320 may communicate with any number of wireless devices via the air interface 1370.

[0183] The wireless device 1310 may include a processing system 1311 and a memory 1312. The memory 1312 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. The memory 1312 may contain instructions 1313. The processing system 1311 may process and / or execute the instructions 1313. The processing and / or execution of the instructions 1313 may cause the wireless device 1310 and / or the processing system 1311 to perform one or more functions or activities. The memory 1312 may contain data (not shown). One of the functions or activities performed by the processing system 1311 may be to store data in the memory 1312 and / or retrieve previously stored data from the memory 1312. In an example, downlink data received from the base station 1320 may be stored in the memory 1312, and uplink data to be transmitted to the base station 1320 may be retrieved from the memory 1312. As Figure 13 shown, the wireless device 1310 may communicate with the base station 1320 using a transmission processing system 1314 and / or a reception processing system 1315. Alternatively, the transmission processing system 1314 and the reception processing system 1315 may be implemented as a single processing system, or both may be omitted, and all processing in the wireless device 1310 may be performed by the processing system 1311. Although Figure 13 not shown, the transmission processing system 1314 and / or the reception processing system 1315 may be coupled to a dedicated memory, which is similar to the memory 1312 but separate from the memory 1312, and includes instructions that may be processed and / or executed to implement one or more of its corresponding functions. The wireless device 1310 may include one or more antennas 1316 to access the air interface 1370.

[0184] The wireless device 1310 may include one or more other elements 1319. The one or more other elements 1319 may include software and / or hardware that provides features and / or functionality, such as speakers, microphones, keypads, displays, touch pads, satellite transceivers, universal serial bus (USB) ports, hands-free headsets, frequency modulation (FM) radio units, media players, Internet browsers, electronic control units (e.g., for motor vehicles), and / or one or more sensors (e.g., accelerometers, gyroscopes, temperature sensors, radar sensors, lidar sensors, ultrasonic sensors, light sensors, cameras, global positioning sensors (GPS), etc.). The wireless device 1310 may receive user input data from the one or more other elements 1319 and / or provide user output data to the one or more other elements. The one or more other elements 1319 may include a power source. The wireless device 1310 may receive power from the power source and may be configured to distribute the power to other components in the wireless device 1310. The power source may include one or more power sources, such as batteries, solar cells, fuel cells, or any combination thereof.

[0185] The wireless device 1310 may transmit uplink data to the base station 1320 via the air interface 1370 and / or receive downlink data from the base station. To perform the transmission and / or reception, one or more of the processing system 1311, the transmission processing system 1314, and / or the reception system 1315 may implement open systems interconnection (OSI) functionality. As an example, the transmission processing system 1314 and / or the reception system 1315 may perform layer 1 OSI functionality, and the processing system 1311 may perform higher layer functionality. The wireless device 1310 may transmit and / or receive data via the air interface 1370 using one or more antennas 1316. For scenarios in which the one or more antennas 1316 include multiple antennas, the multiple antennas may be used to perform one or more multi-antenna techniques, such as spatial multiplexing (e.g., single-user multiple input multiple output (MIMO) or multi-user MIMO), transmit / receive diversity, and / or beamforming.

[0186] Base station 1320 may include a processing system 1321 and a memory 1322. The memory 1322 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. The memory 1322 may contain instructions 1323. The processing system 1321 may process and / or execute the instructions 1323. The processing and / or execution of the instructions 1323 may cause the base station 1320 and / or the processing system 1321 to perform one or more functions or activities. The memory 1322 may contain data (not shown). One of the functions or activities performed by the processing system 1321 may be to store data in the memory 1322 and / or retrieve previously stored data from the memory 1322. The base station 1320 may communicate with the wireless device 1310 using a transmission processing system 1324 and a reception processing system 1325. Although Figure 13 not shown in the figure, the transmission processing system 1324 and / or the reception processing system 1325 may be coupled to a dedicated memory, which is similar to the memory 1322 but separate from the memory 1322, and includes instructions that may be processed and / or executed to implement one or more of its corresponding functions. The wireless device 1320 may include one or more antennas 1326 to access the air interface 1370.

[0187] The base station 1320 may transmit downlink data to the wireless device 1310 via the air interface 1370 and / or receive uplink data from the wireless device. To perform the transmission and / or reception, one or more of the processing system 1321, the transmission processing system 1324, and / or the reception system 1325 may implement OSI functionality. As an example, the transmission processing system 1324 and / or the reception system 1325 may perform layer 1 OSI functionality, and the processing system 1321 may perform higher layer functionality. The base station 1320 may transmit and / or receive data via the air interface 1370 using one or more antennas 1326. For a scenario in which the one or more antennas 1326 include multiple antennas, the multiple antennas may be used to perform one or more multi-antenna techniques, such as spatial multiplexing (e.g., single-user multiple-input multiple-output (MIMO) or multi-user MIMO), transmit / receive diversity, and / or beamforming.

[0188] The base station 1320 may include an interface system 1327. The interface system 1327 may communicate with one or more elements of one or more base stations and / or a core network via an interface 1380. The interface 1380 may be wired and / or wireless, and the interface system 1327 may include one or more components adapted to communicate via the interface 1380. In Figure 13In [the figure], interface 1380 connects base station 1320 to a single deployment 1330. However, it should be understood that wireless device 1310 can communicate with any number of base stations and / or CN deployments via interface 1380, and deployment 1330 can communicate with any number of base stations and / or other CN deployments via interface 1380. Base station 1320 can include one or more other elements 1329 similar to one or more of the one or more other elements 1319.

[0189] Deployment 1330 can include any number of parts of any number of instances of one or more network functions (NFs). Deployment 1330 can include a processing system 1331 and a memory 1332. Memory 1332 can include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1332 can contain instructions 1333. Processing system 1331 can process and / or execute instructions 1333. The processing and / or execution of instructions 1333 can cause deployment 1330 and / or processing system 1331 to perform one or more functions or activities. Memory 1332 can contain data (not shown). One of the functions or activities performed by processing system 1331 can be storing data in memory 1332 and / or retrieving previously stored data from memory 1332. Deployment 1330 can access interface 1380 using interface system 1337. Deployment 1330 can include one or more other elements 1339 similar to one or more of the one or more other elements 1319.

[0190] One or more of systems 1311, 1314, 1315, 1321, 1324, 1325, and / or 1331 can include one or more controllers and / or one or more processors. The one or more controllers and / or one or more processors can include, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or other programmable logic devices, discrete gates and / or transistor logic, discrete hardware components, an on-board unit, or any combination thereof. One or more of systems 1311, 1314, 1315, 1321, 1324, 1325, and / or 1331 can perform signal decoding / processing, data processing, power control, input / output processing, and / or any other functionality that enables wireless device 1310, base station 1320, and / or deployment 1330 to operate in a mobile communication system.

[0191] Many of the elements described in the disclosed embodiments may be implemented as modules. A module is defined herein as an element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure may be implemented in hardware, software in combination with hardware, firmware, wetware (e.g., hardware with biological elements), or a combination thereof, all of which may be behaviorally equivalent. For example, a module may be implemented as a software routine written in a computer language that is configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript. It is possible to implement the module using physical hardware incorporating discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include computers, microcontrollers, microprocessors, DSPs, ASICs, FPGAs, and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors may be programmed using languages such as assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are often programmed using hardware description languages (HDLs), such as VHSIC hardware description language (VHDL) or Verilog, which configure the connections between less functional internal hardware modules on the programmable device. The techniques mentioned are often used in combination to achieve the result of a functional module.

[0192] The wireless device 1310, the base station 1320, and / or the deployment 1330 may implement timers and / or counters. The timer / counter may be started at an initial value. As used herein, starting may include restarting. Once started, the timer / counter may run. The running of the timer / counter may be associated with an event. When the event occurs, the value of the timer / counter may change (e.g., increment or decrement). The event may be (e.g.) an exogenous event (e.g., received signal, measurement condition, etc.), an endogenous event (e.g., transmitted signal, calculation, comparison, performing an action or making a decision so performed, etc.), or any combination thereof. In the case of a timer, the event may be the elapse of a specific amount of time. However, it should be understood that a timer may be described and / or implemented as a counter that counts the elapse of a specific time unit. The timer / counter may run in the direction of a final value until it reaches the final value. The reaching of the final value may be referred to as the expiration of the timer / counter. The final value may be referred to as a threshold. The timer / counter may be paused, where the current value of the timer / counter is held, maintained, and / or continued, even after one or more events occur that would otherwise cause the value of the timer / counter to change. The timer / counter may be unpaused or continued, where the held, maintained, and / or continued value begins to change again when the one or more events occur. The timer / counter may be set and / or reset. As used herein, setting may include resetting. When the timer / counter is set and / or reset, the value of the timer / counter may be set to the initial value. The timer / counter may be started and / or restarted. As used herein, starting may include restarting. In some embodiments, when the timer / counter is restarted, the value of the timer / counter may be set to the initial value and the timer / counter may begin to run.

[0193] Figure 14A , 14B , 14C, and 14D illustrate various example arrangements of physical core network deployments each having one or more network functions or portions thereof. The core network deployments include deployment 1410, deployment 1420, deployment 1430, deployment 1440, and / or deployment 1450. Each deployment may, for example, be similar to Figure 13The deployment 1330 depicted. Specifically, each deployment may include a processing system for performing one or more functions or activities, a memory for storing data and / or instructions, and an interface system for communicating with other network elements (e.g., other core network deployments). Each deployment may include one or more network functions (NFs). The term NF may refer to a specific set of functionality and / or one or more physical elements configured to perform that functionality (e.g., a processing system and memory including instructions that, when executed by the processing system, cause the processing system to perform the functionality). For example, in this disclosure, when a network function is described as performing X, Y, and Z, it should be understood that this refers to the one or more physical elements being configured to perform X, Y, and Z, regardless of how or where the one or more physical elements are deployed. The term NF may refer to a network node, network element, and / or network device.

[0194] As will be discussed in more detail below, there are many different types of NFs, and each type of NF may be associated with a different set of functionality. Multiple different NFs may be flexibly deployed at different locations (e.g., in different physical core network deployments) or in the same location (e.g., co-located in the same deployment). A single NF may be flexibly deployed at different locations (implemented using different physical core network deployments) or in the same location. In addition, a physical core network deployment may also implement one or more base stations, application functions (AFs), data networks (DNs), or any portion thereof. An NF may be implemented in many ways, including as a network element on dedicated or shared hardware, as a software instance running on dedicated or shared hardware, or as a virtual function instantiated on a platform (e.g., a cloud-based platform).

[0195] Figure 14A An example arrangement of core network deployments is shown, where each deployment includes one network function. Deployment 1410 includes NF 1411, deployment 1420 includes NF 1421, and deployment 1430 includes NF 1431. Deployments 1410, 1420, 1430 communicate via interface 1490. Deployments 1410, 1420, 1430 may have different physical locations with different signal propagation delays relative to other network elements. The diversity of the physical locations of deployments 1410, 1420, 1430 may enable services to be provided to a wide area with improved speed, coverage, security, and / or efficiency.

[0196] Figure 14B An example arrangement is shown where a single deployment includes more than one NF. Different from Figure 14A (where each NF is deployed in a separate deployment), Figure 14BShows multiple NFs in deployments 1410, 1420. In an example, deployments 1410, 1420 may implement software-defined networking (SDN) and / or network function virtualization (NFV).

[0197] For example, deployment 1410 includes additional network function NF 1411A. NFs 1411, 1411A may be composed of multiple instances of the same NF type co-located at the same physical location within the same deployment 1410. NFs 1411, 1411A may be implemented independently of each other (e.g., isolated and / or controlled independently). For example, NFs 1411, 1411A may be associated with different network slices. The processing system and memory associated with deployment 1410 may perform all the functionality associated with NF 1411 in addition to all the functionality associated with NF 1411A. In an example, NFs 1411, 1411A may be associated with different PLMNs, but the deployment 1410 implementing NFs 1411, 1411A may be owned and / or operated by a single entity.

[0198] In Figure 14B elsewhere, deployment 1420 includes NF 1421 and additional network function NF 1422. NFs 1421, 1422 may be of different NF types. Similar to NFs 1411, 1411A, NFs 1421, 1422 may be co-located within the same deployment 1420 but implemented separately. As an example, a first PLMN may own and / or operate deployment 1420 with NFs 1421, 1422. As another example, a first PLMN may implement NF 1421, and a second PLMN may obtain (e.g., lease, rent, acquire, etc.) at least a portion of the capabilities of deployment 1420 (e.g., processing power, data storage, etc.) from the first PLMN in order to implement NF 1422. As yet another example, the deployment may be owned and / or operated by one or more third parties, and the first PLMN and / or the second PLMN may obtain corresponding portions of the capabilities of deployment 1420. When multiple NFs are provided at a single deployment, the network may operate at greater speed, coverage, security, and / or efficiency.

[0199] Figure 14C Shows an example arrangement of a core network deployment where a single instance of an NF is implemented using multiple different deployments. Specifically, a single instance of NF 1422 is implemented at deployments 1420, 1440. As an example, the functionality provided by NF 1422 may be implemented as a bundle or series of sub-services. Each sub-service may be implemented independently, e.g., at different deployments. Each sub-service may be implemented in different physical locations. By distributing the implementation of the sub-services of a single NF across different physical locations, the mobile communication network may operate at greater speed, coverage, security, and / or efficiency.

[0200] Figure 14D Shows an example arrangement of a core network deployment, where one or more network functions are implemented using data processing services. In Figure 14D , the NFs 1411, 1411A, 1421, 1422 are included in a deployment 1450 implemented as a data processing service. The deployment 1450 may include, for example, a cloud network and / or a data center. The deployment 1450 may be owned and / or operated by a PLMN or by a non-PLMN third party. The NFs 1411, 1411A, 1421, 1422 implemented using the deployment 1450 may belong to the same PLMN or to different PLMNs. A PLMN may obtain (e.g., lease, rent, acquire, etc.) at least a part of the capabilities of the deployment 1450 (e.g., processing power, data storage, etc.). By providing one or more NFs using data processing services, a mobile communication network can operate with greater speed, coverage, security, and / or efficiency.

[0201] As shown in the figure, different network elements (e.g., NFs) may be located in different physical deployments or co-located in a single physical deployment. It should be understood that in this disclosure, the sending and receiving of messages between different network elements is not limited to inter-deployment transmission or intra-deployment transmission, unless explicitly indicated.

[0202] In an example, a deployment may be a 'black box' that is pre-configured with one or more NFs and pre-configured to communicate with other 'black box' deployments (e.g., via an interface 1490) in a prescribed manner. Additionally or alternatively, a deployment may be configured to operate according to open source instructions (e.g., software) designed to implement NFs and communicate with other deployments in a transparent manner. A deployment may operate according to the Open RAN (O-RAN) standard.

[0203] Figure 15The example embodiments depicted show how an Application Data Unit (ADU) is delivered from a sender to a receiver. The ADU can include, for example, a picture file, a video frame, a text file, and so on. For example, the ADU can include data units generated by one or more protocols (e.g., RTP, DASH, TCP, UDP, etc.). The ADU can be generated and / or created, for example, by a first instance of a specific application, used and / or consumed by a second instance of the application, or processed by an application server of the application. The middle layer can be responsible for encapsulating and / or formatting the ADU for delivery from the sender to the receiver. For example, the middle layer can provide the functionality of one or more protocols (e.g., IP, etc.). After formatting the ADU into one or more packets based on one or more protocols, the middle layer can forward the one or more packets to the lower layer. One or more packets of the ADU can be a set of PDUs of the ADU. The packets in the one or more packets can be PDUs. The lower layer can provide the functionality of forwarding one or more packets from one node to another node, for example, through a specific interface. The second instance of the application can be located at another node.

[0204] As Figure 15 depicted, for example, an upper layer (e.g., an application) in a UE can generate ADU 1. The upper layer in the UE can deliver ADU 1 to the middle layer of the UE. For the delivered ADU 1, the middle layer of the UE can process ADU 1 and can encapsulate ADU 1 into one or more packets based on one or more protocols. For example, the one or more packets can include Packet 1 and / or Packet 2. For example, if the IP protocol is used, ADU 1 can be processed into one or more IP packets. Each IP packet can include at least a part of ADU 1.

[0205] The middle layer can deliver the generated one or more packets to the lower layer. The lower layer can be the Access Stratum (AS). For example, the SDAP entity of the AS layer can receive Packet 1 and / or Packet 2 from the middle layer as SDU 1 and SDU 2. The AS layer of the UE can process and send SDU 1 and SDU 2. For example, the AS layer of the UE can send SDU 1 and SDU 2 to the AS layer of the NG-RAN. For example, the RLC entity of the AS layer of the UE can generate one or more PDUs from SDU 1 and SDU 2. For example, based on the amount of radio resources allocated by the NG-RAN, the RLC layer of the AS layer can segment SDU 1 into PDU 1 and PDU 2, and segment SDU 2 into PDU 3 and PDU 4. The MAC entity of the AS layer can receive one or more PDUs from the RLC entity. The MAC entity can transmit the received one or more PDUs to the NG-RAN.

[0206] Each layer has different functions, such as those described above in Figure 7CThe functions described in. The data constituting the ADU 1 can be partitioned, subdivided, compressed, encrypted, reordered, multiplexed, encoded, etc. After the ADU 1 passes through these layers, the final result (e.g., one or more PDUs) can be suitable for transmission. However, the PDU may be undecipherable (literally) for the application associated with the ADU 1. After the transmission described in more detail below, the process can be reversed, and the ADU 1 can be reconstructed at the other side (e.g., Figure 15 the application server in

[0207] Return Figure 15 , the MAC entity of the NG-RAN can receive one or more PDUs sent by the UE. The received one or more PDUs can be reassembled into one or more SDUs. For example, using the received PDU 1 and PDU 2, the AS layer of the NG-RAN can reassemble SDU 1. For example, using the received PDU 3 and PDU 4, the AS layer of the NG-RAN can reassemble SDU2. Packet 1 of SDU 1 and packet 2 of SDU 2 can be delivered from the NG-RAN to the core network (e.g., UPF). The core network can send packet 1 and packet 2 to the recipient (e.g., the application server associated with the ADU) via the Internet. After receiving packet 1 and packet 2, the intermediate layer of the application server can recover the ADU 1 and deliver the ADU 1 to the upper layer. The upper layer can perform application-specific processing using the received ADU1.

[0208] In the prior art, one or more protocol entities and / or one or more layers can be agnostic to the differentiated characteristics of differentiated applications. In the prior art, one or more protocol entities and / or one or more layers can be unaware of the differentiated characteristics of one or more types of ADUs of an application. For example, the AS layer may not consider the different characteristics of different applications. For example, the AS layer may not consider the differences and / or similarities and / or relationships between one or more ADUs of an application. For example, the data units in the lower layer (e.g., Figure 15 packet 1, SDU 1, PDU 2 in Figure 15is associated with a part of the ADU 1) in. However, within the lower layer, the data unit may not be recognizable as being associated with a specific application data unit or even a specific application. At the lower layer, the data unit can simply be a series of ones and zeros encapsulated for delivery. This application-agnostic approach (e.g., an approach that ignores the ADU) can help support independent enhancements of one or more layers and / or one or more entities. For example, by not binding the operations of the AS layer to a certain application feature, the AS layer can evolve without changing the behavior of one or more applications. Due to this application-agnostic approach, the AS layer can support the introduction of newly developed later applications. However, as new advanced use cases emerge and the QoS requirements of applications are strengthened to provide an enhanced experience for users, the application-agnostic approach of the AS layer may not support the efficient use of radio resources and network resources, as will be discussed in more detail below.

[0209] Figure 16 shows an example of data delivery where one or more PDUs are not delivered from the UE to the NG-RAN. For one or more generated PDUs (e.g., PDU 1, PDU 2, PDU 3, PDU 4), the lower-layer RLC entity and / or the lower-layer MAC entity can transmit one or more PDUs. When the transmission of a PDU fails, the RLC and / or MAC entity can perform a retransmission of the PDU. For example, if the RLC entity of the sender receives a negative acknowledgment for one or more PDUs from the RLC entity of the receiver, the RLC entity of the sender can perform a retransmission of one or more PDUs. For example, if the MAC entity of the sender receives a negative HARQ acknowledgment for the HARQ process from the receiver, the MAC entity of the sender can perform a HARQ retransmission of the HARQ process.

[0210] In Figure 16 example, at time t = t1, the RLC entity of the sender can transmit PDU 1 and can receive an acknowledgment for PDU 1. At time t = t2, the RLC entity can transmit the next PDU, i.e., PDU 2. After detecting the failure of the transmission of PDU 2, the RLC entity can perform a retransmission of PDU 2 at times t = t2' and t = t2". After several failed transmissions of PDU 2, the RLC entity can stop the transmission of PDU 2 and can start the transmission of PDU 3 at t = t3 and the transmission of PDU 4 at t = t4. For the received PDUs (e.g., PDU 1, PDU 3, and PDU 4), the receiver can perform the assembly of one or more SDUs using the received one or more PDUs. The receiver can deliver one or more assembled SDUs to the next hop (e.g., UPF, NG-RAN, UE, Internet router, upper layer).

[0211] AsFigure 15 As shown, in order to deliver an ADU from a sender to a receiver, it may be necessary to deliver all PDUs associated with the ADU from the UE to the NG-RAN. If one of the PDUs is not successfully delivered, the ADU may not be recoverable. For example, in Figure 16 the example, ADU 1 is associated with PDU 1, PDU 2, PDU 3, and PDU 4. In the example, since PDU 2 is not successfully delivered from the UE to the NG-RAN, the NG-RAN may not be able to reassemble SDU 1 (e.g., packet 1). In the example, since PDU 3 and PDU 4 are successfully delivered from the UE to the NG-RAN, the NG-RAN may be able to reassemble SDU 2 (e.g., packet 2). The NG-RAN may forward packet 2 of SDU 2 to the application server via the core network. Since packet 1 is not received, the application server cannot recover ADU 1 with the received packet 2.

[0212] However, as Figure 16 shown in the example of

[0213] the prior art inefficient operation causes the sender to continue to send PDUs that the application cannot use. For example, at t = t'', the RLC entity of the sender may realize the transmission failure of PDU 2. Due to the failure, ADU 1 associated with PDU 2 cannot be recovered by the application. However, the RLC entity of the sender may initiate the transmission of PDU 3 and PDU 4 associated with ADU 1. Even if PDU 3 and PDU 4 are successfully delivered, the lost PDU 2 will make PDU 3 and PDU 4 less useful because the application server may not be able to use ADU 1. Therefore, the operation of the prior art results in a waste of valuable radio resources and network resources.

[0213] One possible way to solve this problem may be not to transmit other associated PDUs of the ADU when at least one PDU of the ADU is not successfully transmitted. However, this may pose another challenge, as shown in the example of Figure 17

[0214] As Figure 17As shown, an application function (AF) of a running application can generate an ADU. The ADU can be packaged into one or more IP packets (e.g., IP packet 1 and IP packet 2), and the AF can send one or more IP packets to the UE. These packets can be routed via the Internet and can reach the UPF serving the UE. The UPF can encapsulate the received one or more IP packets into GTP-U packets and can send the GTP-U packets to the NG-RAN. The NG-RAN can extract one or more IP packets from the received GTP-U packets. The NG-RAN can initiate the transmission of one or more IP packets. The NG-RAN can use one or more IP packets to generate one or more PDUs. For example, PDU 1 can be associated with IP packet 1, and PDU 2 can be associated with IP packet 2. The NG-RAN can transmit PDU 1 to the UE. If the radio conditions deteriorate temporarily, e.g., when the UE can pass through a tunnel, the transmission of PDU 1 may fail. Thereafter, the NG-RAN can initiate the transmission of the next PDU, e.g., PDU 2. The transmission of PDU 2 may succeed. Since PDU 1 and PDU 2 are associated with the same ADU, in order for the application to resume the ADU, the receiving party may need to receive both PDU 1 and PDU 2. If the transmission of PDU 1 fails, PDU 2 may not be used for the reassembly of the ADU. If the transmission of PDU 1 fails, the success or failure of the transmission of PDU 2 may be different from the operation of the application. However, the NG-RAN may not know whether PDU 1 and PDU 2 are associated with the same ADU. Therefore, the NG-RAN may waste radio resources by transmitting PDU 2.

[0215] Example embodiments of the present disclosure improve system efficiency through enhancements in the operations of the network and / or the UE. In an example embodiment, based on the interaction between the network and the application function, the network can determine whether enhanced processing (e.g., ADU-aware processing of lower-layer data units) can be applied. The network can perform the identification of one or more associated ADUs for one or more incoming packets. The network can support information distribution based on the identification of one or more associated ADUs for one or more incoming packets. For example, a network function (e.g., UPF) can send an indication to another network node (e.g., NG-RAN) that a received or incoming packet is one of one or more packets associated with a data unit (e.g., ADU) of a data stream of a wireless device. In an example embodiment, the indication is within the GTP header. In other example embodiments, different network nodes can convey configuration and / or auxiliary information for determining whether a packet is associated with a data unit of a data stream of a wireless device. This can reduce the waste of radio and / or network resources by enabling one or more network nodes to perform advanced processing on one or more incoming packets. This can support an enhanced QoS experience for the user.

[0216] In this specification, the term NG-RAN may be interpreted as a base station, which may include at least one of gNB, eNB, ng-eNB, NodeB, access node, access point, N3IWF, relay node, base station central unit (e.g., gNB-CU), base station distributed unit (e.g., gNB-DU), etc.

[0217] In this specification, the term AMF may be interpreted as a core network device, which may include at least one of mobility management function / entity, access management function, etc. In this specification, the term SMF may be interpreted as a core network device, which may include at least one of session management function / entity, serving gateway, PDN gateway, etc.

[0218] In the specification, the term core network node may be interpreted as a core network device, which may include at least one of AMF, SMF, NSSF, UPF, NRF, UDM, PCF, etc. The term core network may be interpreted as core network nodes. In the specification, the term access node may be interpreted as a base station that may include NG-RAN, etc. In the specification, the term network node may be interpreted as a core network node and / or an access node and / or a UE, etc.

[0219] In this specification, the term AF (Application Function) may be interpreted as an AS (Application Server), which may host and / or run one or more applications.

[0220] In this specification, the term ADU may be interpreted as a unit of data exchanged between one or more hosts serving an application. In an example, an application (e.g., Internet browser, instant messaging application, video player application, etc.) may run on a first host (e.g., smartphone, computer, application server, etc.), and the same application may run on a second host (e.g., another smartphone, computer, application server, etc.). The application on the first host may generate application data (e.g., picture file, text message, etc.) including one or more ADUs. To deliver the application data from the first host to the second host, the application on the first host may deliver the application data to a first protocol entity (e.g., HTTP entity, etc.). To deliver the application data to the second host, the first protocol entity on the first host may process the application data and generate one or more protocol data units of a first type (e.g., HTTP request message, HTTP response message, etc.).

[0221] A first protocol entity may deliver one or more protocol data units of a first type to an access protocol layer of the first type (e.g., an LTE access layer, an NR access layer, a WIFI access layer, etc.). The access protocol layer of the first type of the first host may process one or more protocol data units of the first type and may generate one or more access protocol data units of the first type (e.g., an SDAP PDU, a PDCP PDU, an RLC PDU, a MAC PDU, etc.). The access protocol layer of the first type of the first host may transmit one or more access protocol data units of the first type. The access protocol layer of the first type of a third host (e.g., an NG-RAN, a UE, etc.) may receive one or more access protocol data units of the first type. The third host may reassemble one or more protocol data units of the first type and may deliver one or more protocol data units of the first type to an access protocol layer of the second type of the third host (e.g., an LTE access layer, an NR access layer, a WIFI access layer, an Ethernet layer, an ATM layer, a GTP layer, etc.).

[0222] The access protocol layer of the second type of the third host may process one or more protocol data units of the first type and may generate one or more access protocol data units of the second type (e.g., an Ethernet frame, an ATM cell, an LTE access layer PDU, an NR access layer PDU, a WIFI access layer packet, etc.). The access protocol layer of the second type of the third host may transmit one or more access protocol data units of the second type. The access protocol layer of the second type of a second host may receive one or more access protocol data units of the second type. The access protocol layer of the second type of the second host may use one or more access protocol data units of the second type to reassemble one or more protocol data units of the first type. The access protocol layer of the second type of the second host may deliver the reassembled one or more protocol data units of the first type to a first type protocol entity of the second host. The first type protocol entity of the second host may use one or more protocol data units of the first type to reassemble application data. The first type protocol entity of the second host may deliver the application data to an application of the second host.

[0223] In the example, one or more protocol entities (e.g., TCP entity, UDP entity, RTP entity, etc.) may exist between the application and the access protocol layer. In the above description, for the purpose of simple illustration, only one protocol entity (e.g., the first type of protocol entity) is described. In the example, one or more protocol entities (e.g., the second type of protocol entity, the third type of protocol entity, etc.) may exist between the first type of protocol entity and the access protocol layer. Similarly, in one example, one or more hosts (e.g., NG-RAN, UPF, Internet router, etc.) may exist between the first host and the second host. In the above description, for the purpose of simple illustration, only one host (e.g., the third host) is described. In the example, one or more additional hosts (e.g., the fourth host (e.g., UPF), the fifth host (e.g., Internet router), etc.) may exist between the third host and the second host. In the example, a pair of hosts may use the same or different types of access protocol layers. For example, to communicate between the third host and the fourth host, a third type of access protocol layer (e.g., optical fiber, satellite, etc.) may be used.

[0224] In the example, the ADU may be interpreted as application data. In the example, the ADU may be interpreted as a first type of protocol data unit. In the example, the ADU may be interpreted as a second type of protocol data unit, etc. In the example, the ADU may be interpreted as a unit of protocol data and / or a unit of layer data. In the example, the first host and the second host may maintain one or more contexts of the protocol and / or the layer. For example, the application of the first host may communicate with the application of the second host. The application of the first host may have the context of the second host. The application of the second host may have the context of the first host. Thus, the application data may be the ADU. For example, the first type of protocol entity of the first host may communicate with the first type of protocol entity of the second host. The first type of protocol entity of the first host may have the context of the second host. The first type of protocol of the second host may have the context of the first host. Thus, the first type of protocol data unit may be the ADU. For example, the first type of access protocol layer of the first host may not communicate with the second type of access protocol layer of the second host. The first type of access protocol entity of the first host may not have the context of the second type of access protocol of the second host. The second type of access protocol layer of the second host may not have the context of the first type of access protocol of the first host. Thus, the first type of access protocol data unit may not be the ADU. Thus, the second type of access protocol data unit may not be the ADU.

[0225] In this specification, the term service data flow may be interpreted as a collection of data units exchanged between one or more hosts. For example, a first service data flow may be interpreted as a collection of one or more data units from a second host to a first host. For example, a second service data flow may be interpreted as a collection of one or more data units from a third host to a first host. For example, one or more data units of a service data flow may share one or more attributes (e.g., the same source IP address, the same destination IP address, the same UDP port, etc.).

[0226] In the specification, ADU-aware delivery may be interpreted as a mechanism and / or process performed by one or more network nodes. For example, the mechanism and / or process may be to process one or more protocol data units based on information of one or more ADUs associated with one or more protocol data units. For example, the mechanism and / or process may be to identify information associated with one or more ADUs of one or more protocol data units. For example, the mechanism and / or process may be to configure one or more network nodes to use information of one or more associated ADUs of one or more protocol data units.

[0227] Figure 18 An example of one or more ADUs and / or packets may be shown. For example, a host may include one or more levels of protocol / application entities. An entity (e.g., a first entity) in one or more protocol / application entities may receive one or more data units from an entity (e.g., a second entity) in one or more protocol / application entities. An entity (e.g., a first entity) in one or more protocol / application entities may send one or more data units to an entity (e.g., a third entity) in one or more protocol / application entities.

[0228] In the example, a level 1 protocol / application entity may generate one or more level 1 ADUs. The level 1 protocol / application entity may send one or more level 1 ADUs to a level 2 protocol / application entity. The level 2 protocol / application entity may generate one or more level 2 ADUs. One or more level 2 ADUs may include one or more level 2 ADU headers and / or one or more level 2 ADU payloads. One or more level 2 ADU payloads may include at least a portion of one or more level 1 ADUs. A portion of one or more level 1 ADUs may include one or more bytes of one or more level 1 ADUs. The level 2 protocol / application entity may deliver one or more level 2 ADUs to the next-level ADU protocol / application entity (e.g., a level 3 ADU protocol / application entity).

[0229] The level 3 protocol / application entity can receive one or more level 2 ADUs from the level 2 protocol / application entity. The level 3 protocol / application entity can generate one or more level 3 ADUs. One or more level 3 ADUs can include one or more level 3 ADU headers and / or one or more level 3 ADU payloads. One or more level 3 ADU payloads can include at least a part of one or more level 2 ADUs. A part of one or more level 2 ADUs can include one or more bytes of one or more level 2 ADUs. The level 3 protocol / application entity can deliver one or more level 3 ADUs to the next-level ADU protocol / application entity (e.g., the level 4 ADU protocol / application entity).

[0230] Depending on the number of protocol / application entities, the above operations can be repeated. Depending on the number of protocol / application entities, the level 2 protocol / application entity and / or the level 3 protocol / application entity may not be used.

[0231] In the example, the packet protocol entity (e.g., the IP protocol entity) can receive one or more level H ADUs from the level H protocol / application entity. The packet protocol entity can generate one or more packets. One or more packets can include one or more packet ADU headers and / or one or more packet payloads. One or more packet payloads can include at least a part of one or more level H ADUs. A part of one or more level H ADUs can include one or more bytes of one or more level H ADUs. The packet protocol entity can deliver one or more packets to the access layer (e.g., the Internet, the 3GPP protocol stack, the LTE access layer, the NR access layer, the WIFI access layer). In the example, the packet protocol entity can be interpreted as one of the protocol / application entities.

[0232] In the example, the level 1 / application entity can be an application (e.g., a video application). The level 2 protocol / application entity can be an HTTP protocol entity. The level 3 protocol / application entity can be an RTP protocol entity. The level 4 protocol / application entity can be a UDP protocol entity. The level 5 protocol / application entity and / or the packet protocol entity can be an IP protocol entity.

[0233] Figure 19Example embodiments of the present disclosure may be depicted. In an example, the AF may perform signaling with the core network to request activation of ADU-aware delivery. In an example, the UE may perform signaling with the core network to request activation of ADU-aware delivery. In an example, based on the request to activate ADU-aware delivery, one or more network nodes may execute one or more procedures to configure one or more network nodes to support ADU-aware delivery. In an example, based on the configuration for ADU-aware delivery, one or more network nodes may perform identification of one or more associated ADUs for one or more incoming packets. In an example, based on the identification of one or more associated ADUs for one or more incoming packets, one or more network nodes perform delivery of ADU-related information.

[0234] Figure 20 An example embodiment of the present disclosure may be depicted.

[0235] In an example, the AF may determine that ADU-aware delivery is required over the network. For example, to reduce unnecessary packet delivery, the AF may determine to request the network to activate ADU-aware delivery. Based on the determination, the AF may invoke a NEF service request from a first network node. For example, the first network node may be an NMF, etc. The invoked NEF service may be Nnef_ParameterProvision_Create and / or Nnef_ServiceParameter_Create and / or Nnef_ApplyPolicy_Create, etc. The NEF service request may include at least one of the following:

[0236] - Target UE or UE information group: This may indicate the target UE or UE group to which ADU-aware delivery applies. An individual UE may be identified by GPSI or IP address / prefix or MAC address. The UE group may be identified by an external group identifier. Instead of the identifier of the target UE or UE group, any UE using the service identified by the service description may be used.

[0237] - ADU service request information: This may include information related to ADU-aware delivery.

[0238] - Expected UE behavior parameters: This may include information related to the potential mobility of the UE.

[0239] - Network configuration parameter information: This may include information related to the communication availability and / or reachability of the UE.

[0240] - External group Id and 5G VN group data: This may include information related to the UE group belonging to the group.

[0241] - Service description information: This can be information that identifies a service. This can include DNN and / or S-NSSAI and / or AF-Service-Identifier or application identifier. This can indicate the AF that sends a request for ADU-aware delivery and / or the application and / or service data flow to which ADU-aware delivery applies.

[0242] - Service parameter information: Service parameter information is service-specific information that needs to be provisioned in the network and / or UE for the service identified by the service description.

[0243] In an example, the ADU service request information can include at least one of the following:

[0244] - A request to activate ADU-aware delivery: This can indicate that the AF requests the network to provide ADU-aware delivery service.

[0245] - AF's capabilities for ADU-aware delivery: This can indicate the capabilities of the AF. For example, this can indicate which mechanisms the AF supports to indicate ADU-related information.

[0246] - ADU identification assistance information: This can indicate information on how the AF can deliver information about the associated ADU information of a packet. This can indicate one or more fields of the ADU that can be used to determine the ADU information associated with a packet.

[0247] - Information on S-NSSAI: This can indicate the network slice to which ADU-aware delivery applies.

[0248] - Information on DNN: This can indicate the network to which ADU-aware delivery applies.

[0249] In an example, the ADU identification assistance information (e.g., information on ADU identification) can include information on how a network node can identify the ADU-related information of a packet. In an example, the ADU identification assistance information can include information on how to determine whether one or more packets are associated with the same ADU. In an example, the ADU identification assistance information can include information on how to determine whether a packet and the previous packet are associated with the same ADU. For example, the ADU identification assistance information can indicate one or more fields of the ADU and / or the packet. For example, the ADU identification assistance information can indicate one or more values of one or more fields of the ADU and / or the packet. For example, the ADU identification assistance information can include information on the following:

[0250] - How to detect and / or identify and / or classify one or more ADUs associated with one or more packets.

[0251] - Which or which fields of one or more ADUs are used to detect and / or identify and / or classify one or more packets.

[0252] - One or more values of one or more fields of one or more ADUs for detecting and / or identifying and / or classifying one or more packets.

[0253] - The associated ADU of how to detect and / or identify a packet.

[0254] - The identity of the associated ADU of how to detect and / or identify a packet.

[0255] - How to detect the relationship between one or more packets.

[0256] - How to determine which or which packets are associated with an ADU.

[0257] - How to determine the location of one or more parts of an ADU included in one or more packets.

[0258] - How to determine the location of one or more parts of different ADUs included in one or more packets.

[0259] - One or more protocols / applications used in a packet.

[0260] - One or more filter information for identifying and / or classifying one or more packets in a service data stream.

[0261] - One or more packet detection rules for identifying and / or classifying one or more packets in a service data stream.

[0262] In an example, one or more packets can be one or more IP packets. For example, one or more packets can belong to the same service data stream and / or different service data streams. One or more packets can include a first packet, a second packet, and a third packet. For example, the ADU identification auxiliary information can indicate the use of one or more fields in one or more packets. For example, the ADU identification auxiliary information can indicate the DSCP field of the IP protocol. Figure 30 An example can be shown. The first packet can include a first ADU. The second packet can include a first ADU. The third packet can include a second ADU. For example, the DSCP field of the first packet can be set to the value 1. For example, the DSCP field of the second packet can be set to the value 1. For example, the DSCP field of the third packet can be set to the value 2. By observing the difference in the values of the DSCP fields of the first packet and the third packet, the network node can determine that the first packet and the third packet are associated with different ADUs. By observing the difference in the values of the DSCP fields of the first packet and the second packet, the network node can determine that the first packet and the second packet are associated with the same ADU. The ADU-related information can include the determined information.

[0263] In an example, one or more packets may be one or more IP packets. For example, one or more packets may belong to the same service data flow and / or different service data flows. One or more packets may include a first packet, a second packet, and a third packet. For example, the ADU identification auxiliary information may indicate the use of one or more specific fields in one or more ADUs. Figure 31 An example may be shown. The first packet may include a first ADU. The second packet may include a first ADU. The third packet may include a second ADU. For example, the ADU identification auxiliary information may indicate the timestamp field of the ADU. For example, the ADU identification auxiliary information may indicate the timestamp field of the RTP protocol. For example, one or more ADUs may be one or more RTP protocol packets. One or more RTP protocol packets may include one or more timestamp fields. For example, the timestamp field of the first packet may be set to the value 1. For example, the timestamp field of the second packet may be set to the value 1. For example, the timestamp field of the third packet may be set to the value 2. By observing the match of the values of the timestamp fields in the first packet and the second packet, the network node may determine that the first packet and the second packet are related to the same ADU. By observing the mismatch of the values of the timestamp fields in the first packet and the third packet, the network node may determine that the first packet and the third packet are related to different ADUs.

[0264] In an example, for a called NEF service request, a first network node (e.g., NEF, etc.) may determine whether the NEF service request called from the AF is authorized. If the NEF service request called from the AF is authorized, the first network node (e.g., NEF, etc.) may call a UDM service request from a second network node. For example, the second network node may be a UDM, etc. For example, the called UDM service may be Nudm_ParameterProvision_Create and / or Nudm_ServiceSpecificAuthorization_Create, etc.

[0265] In an example, the called UDM service request may include:

[0266] - ADU service request information: This may include information related to ADU-aware delivery.

[0267] - Expected UE behavior parameters: This may include information related to the potential mobility of the UE.

[0268] - Network configuration parameters: This may include information related to the communication availability and / or reachability of the UE.

[0269] - External group Id and 5G VN group data: This may include information related to a group of UEs belonging to the group.

[0270] - Service description: This can be information identifying the service. This can include DNN and / or S-NSSAI and / or AF-Service-Identifier or application identifier. This can indicate the AF that sends the request for ADU-aware delivery and / or the application to which ADU-aware delivery applies and / or the service data flow to which ADU-aware delivery applies.

[0271] - Service parameters: Service parameters are service-specific information that needs to be provisioned in the network and / or UE for the service identified by the service description.

[0272] In an example, for an invoked UDM service request, a second network node can process the information conveyed by the UDM service request. Based on the processing result, the second network node can invoke a UDR service request from a third network node. For example, the UDM can process the received ADU service request information into a packet flow description and / or AF traffic impact request information and / or session management subscription data, etc. For example, the third network node can be a UDR, etc. For example, the invoked UDR service can be Nudr_DM_Create, etc.

[0273] In an example, the invoked UDR service request can include at least one of the following:

[0274] - Packet Flow Description (PFD): This can be information indicating a description of a service flow and / or a packet flow.

[0275] - AF traffic impact request information: This can contain information about the traffic orientation of service data.

[0276] - Service-specific information.

[0277] - Access and mobility subscription data: This can contain information related to the handling of the UE's access and mobility.

[0278] - UE context in SMF data: This can contain information related to the UE context in the SMF serving the UE.

[0279] - SMS management subscription data: This can contain information related to the handling of packet data sessions.

[0280] - Group data: This can contain information about the group.

[0281] - Service description.

[0282] - ADU service request information: This can include information related to ADU-aware delivery.

[0283] In an example, for a UDR service request being invoked, a third network node may store information delivered together with the invoked UDR service request. If the third network node stores the information, the third network node may respond to the second network node with a UDR service response.

[0284] In an example, if the second network node receives a UDR service response from the third network node, the second network node may send a response to the first network node with a UDM service response.

[0285] In an example, if the first network node receives a UDM service response from the second network node, the first network node may send a response to the AF with a NEF service response. The NEF service response may indicate that the request from the AF has been successfully processed.

[0286] Figure 21 Example embodiments of the present disclosure may be depicted.

[0287] In an example, to establish a PDU session to exchange data for an application using an application function, a UE may initiate a procedure for establishing a PDU session. For example, the procedure may be a PDU session establishment procedure. The NAS entity of the UE may compose a first NAS message (e.g., a PDU session establishment request message), and may deliver the first NAS message to the RRC entity of the UE. For example, the first NAS message may include information associated with ADU-aware delivery. For example, to indicate whether the UE supports ADU-aware delivery, the first NAS message may include ADU-aware delivery UE capability information. For example, to request a PDU session that supports ADU-aware delivery, the first NAS message may include ADU service request information (e.g., ADU-aware delivery request information). To deliver the first NAS message to the network, the RRC entity may establish an RRC connection with the NG-RAN. Through the established RRC connection, the UE may send an RRC message including the first NAS message to the NG-RAN. The NG-RAN may send an N2 message (e.g., an initial UE message) to a network node (e.g., an AMF). The N2 message may include the first NAS message. Based on the first NAS message being related to a PDU session, the network node (e.g., an AMF) may invoke an SMF service request (e.g., an Nsmf_PDUSession_CreateSMContext request) from the SMF.

[0288] In the example, for a called SMF service request, the SMF may call a UDM service request (e.g., Nudm_SDM_Get request). By using the UDM service request, the SMF may retrieve information associated with the ADU-aware delivery of the UE. If the UDM does not have information associated with the ADU-aware delivery of the UE, the UDM may call a UDR service request (e.g., Nudr_DM_Query request). For the called UDR service request, the UDR may respond to the UDM with a UDR service response (e.g., Nudr_DM_Query response). The UDM may respond to the SMF with a UDM service response (e.g., Nudm_SDM_Get response) including information associated with the ADU-aware delivery.

[0289] In the example, for a called UDM service request, the UDM may determine whether it is necessary to provide information related to the ADU-aware delivery. For example, the UDM service request may include an S-NSSAI. For the service request, the UDM may determine whether the S-NSSAI is configured to use the ADU-aware delivery. In another example, the UDM service request may contain the identity of the UE (e.g., SUPI, SUCI, GPSI, IP address, etc.). For the service request, the UDM may determine whether the UE or the group to which the UE belongs is configured to use the ADU-aware delivery. In another example, the UDM service request may contain a DNN. For the service request, the UDM may determine whether the DNN is configured to use the ADU-aware delivery. If the UDM determines that it is necessary to use the ADU-aware delivery, the UDM may send a UDM service response including information associated with the ADU-aware delivery.

[0290] In the example, for a PDU session establishment request, the SMF may request a policy decision from the PCF. For example, the SMF may invoke a PCF service request (e.g., Npcf_SMPolicyControl_Create request). For example, the invoked PCF service request may include information associated with ADU-aware delivery. For the invoked PCF service request, the PCF may decide to apply the ADU-aware delivery policy to the PDU session. If the PCF needs to retrieve policy-related subscription data from the UDR, the PCF may trigger a UDR service request (e.g., Nudr_DM_Query request). For the invoked UDR service request, the UDR may respond to the UDM with a UDR service response (e.g., Nudr_DM_Query response). The response from the UDR may include information associated with ADU-aware delivery. Based on the information associated with ADU-aware delivery from the SMF and / or the information associated with ADU-aware delivery from the UDR, the PCF may determine the ADU-aware delivery policy for the PDU session. The PCF may respond to the SMF with a PCF service response (e.g., Npcf_SMPolicyControl_Create response). The PCF service response may include the ADU-aware delivery policy.

[0291] In the example, for ADU-aware delivery, the SMF may determine the associated configuration parameters for the ADU-aware delivery of the PDU session based on the information associated with ADU-aware delivery from the UDM. In the example, for ADU-aware delivery, the PCF may determine the ADU-aware delivery policy for the PDU session based on the information delivered from the UDR and / or the SMF and / or the NEF. In the example, for ADU-aware delivery, the SMF may request the PCF to provide the ADU-aware delivery policy for the PDU session. Based on the ADU-aware delivery policy, the SMF may determine the associated configuration parameters for the ADU-aware delivery of the PDU session.

[0292] For example, the ADU-aware delivery policy may include:

[0293] - Information on ADU authorization. This may include information on whether ADU-aware delivery of the PDU session is allowed and / or whether ADU-aware delivery of one or more service data flows is allowed and / or information on whether ADU-aware delivery of one or more applications is allowed.

[0294] - Information on ADU identification.

[0295] - ADU identification auxiliary information.

[0296] - Information associated with ADU-aware delivery.

[0297] For example, the associated configuration parameters for ADU-aware delivery may include:

[0298] - Information on ADU authorization.

[0299] - Information on ADU identification.

[0300] - ADU identification assistance information.

[0301] - Information on whether PDU session ADU-aware delivery is supported.

[0302] - Information on whether the ADU-aware delivery request for the PDU session is accepted

[0303] - Parameters for the PDU session that the UE uses to configure ADU-aware delivery

[0304] - Parameters for the PDU session that the UPF uses to configure ADU-aware delivery

[0305] - Parameters for the PDU session that the NG-RAN uses to configure ADU-aware delivery

[0306] - Information associated with ADU-aware delivery

[0307] For example, the information associated with ADU-aware delivery may include:

[0308] - ADU service request information

[0309] - Target UE or UE information group

[0310] - Network configuration parameter information

[0311] - Service description information

[0312] - ADU information

[0313] - Configuration of ADU-aware delivery

[0314] - ADU service request information

[0315] - ADU identification assistance information

[0316] - ADU-related information

[0317] - ADU-aware delivery request information.

[0318] For example, a PCF service request (e.g., an Npcf_SMPolicyControl_Create request) may include at least one of the following:

[0319] - SUPI: This may indicate the identity of the UE.

[0320] - PDU Session ID: This can indicate the identity of the PDU session.

[0321] - DNN: This can identify the network to which the PDU session is connected.

[0322] - S-NSSAI: This can identify the network slice in which the PDU session is established.

[0323] - Address: This can include an IPv4 address and / or an IPv6 address.

[0324] - ADU-Aware Delivery UE Capability: This can include information on whether the UE supports ADU-Aware Delivery and / or a list of support methods for ADU-Aware Delivery.

[0325] - QoS Information: This can indicate the subscribed QoS information of the UE and / or the requested QoS information.

[0326] - Information associated with ADU-Aware Delivery.

[0327] - Subscription Data: This can include at least a portion of the subscription data delivered from the UDM.

[0328] For example, a PCF service response (e.g., Npcf_SMPolicyControl_Create response) can include at least one of the following:

[0329] - SM Policy Association ID: This can indicate the identity of the policy information.

[0330] - ADU-Aware Delivery Policy Information: This can include the policy determined by the PCF for ADU-Aware Delivery.

[0331] - Information associated with ADU-Aware Delivery.

[0332] For example, a UDM service request (e.g., Nudm_SDM_Get request) can include at least one of the following:

[0333] - NF ID: This can indicate the identity of the network function (e.g., network node) that sends the UDM service request.

[0334] - Subscription Data Type: This can indicate the type of the requested subscription data.

[0335] - Key: This can indicate the target of the requested subscription data type.

[0336] For example, a UDM service response (e.g., a Nudm_SDM_Get response) may include at least one of the following: - Subscription data: This may include the subscription data requested by a network function. This may include information based on the ADU service request information. - Information associated with ADU-aware delivery.

[0337] For example, an SMF service request may include:

[0338] - SUPI: This may indicate the identity of the UE associated with the SMF service request.

[0339] - DNN: This may indicate the identity of the network associated with the SMF service request.

[0340] - PDU session ID: This may indicate the identity of the PDU session.

[0341] - NF ID: This may indicate the identity of the network function that triggered the SMF service request.

[0342] - N1 SM container: This may include the NAS message sent by the UE. For example, this may include a PDU session establishment request.

[0343] - User location information: This may indicate the current location of the UE.

[0344] - Access type: This may indicate which access the UE uses.

[0345] - GPSI: This may indicate the identity of the UE.

[0346] In an example, for ADU-aware delivery, based on the determined associated configuration parameters of ADU-aware delivery, the SMF may send an N4 session message (e.g., an N4 session establishment request, a packet forwarding control protocol message) to the UPF. N4 session message.

[0347] - Packet detection rules: This may indicate one or more rules on how to detect and / or identify and / or classify one or more service data flows. This may also include one or more rules on how to determine one or more ADU-related information of the packets of the service data flow. For example, this may include ADU identification assistance information.

[0348] - Packet execution rules: This may indicate one or more QoS parameters of one or more service data flows.

[0349] - Packet reporting rules: This may indicate one or more criteria for when the UPF reports an event to the SMF.

[0350] - Associated configuration parameters of ADU-aware delivery.

[0351] In an example, the packet detection rule can provide information to the identity service data stream. For example, the packet detection rule can indicate that the first service data stream corresponds to one or more packets with a source IP address of 1.1.1.1 and a destination IP address of 2.2.2.2. For example, the packet detection rule can indicate that the second data service stream corresponds to one or more packets with a source IP address of 3.3.3.3 and a destination IP address of 4.4.4.4. The UPF can receive one or more IP packets. The one or more IP packets can include a first IP packet, a second IP packet, and a third IP packet. Based on the packet detection rule, the UPF can identify one or more service data streams of the received IP packets. If the source IP address of the first IP packet indicates 1.1.1.1 and the destination IP address of the first IP packet indicates 2.2.2.2, the UPF can determine that the first IP packet corresponds to the first service data stream. If the source IP address of the second IP packet indicates 3.3.3.3 and the destination IP address of the second IP packet indicates 4.4.4.4, the UPF can determine that the second IP packet corresponds to the second service data stream. If the source IP address of the third IP packet indicates 1.1.1.1 and the destination IP address of the third IP packet indicates 2.2.2.2, the UPF can determine that the third IP packet corresponds to the first service data stream.

[0352] In an example, the associated configuration parameters for ADU-aware delivery can provide information on how to perform ADU-aware delivery. In an example, the associated configuration parameters for ADU-aware delivery can provide information on how to identify and / or classify and / or process one or more packets of a service data flow. In an example, the first IP packet and the third IP packet can belong to a first service data flow. Based on the ADU identification assistance information, the UPF can determine the ADU-related information of the IP packet. For example, the ADU identification assistance information can indicate that one or more fields in the packet are associated with the identity of the ADU associated with the packet. For example, the ADU identification assistance information can indicate one or more fields in the packet. One or more fields in the packet can be associated with the identity of the ADU associated with the packet. By checking whether the values of one or more fields of one or more packets are the same, the UPF can determine whether one or more packets are associated with the same ADU. For example, the ADU identification assistance information can indicate that the DSCP field of the IP packet is associated with the identity of the ADU associated with the IP packet. If the DSCP field of the first IP packet indicates '0' and the DSCP field of the third IP packet indicates '1', then the UPF can determine that the first IP packet and the third IP packet can be associated with different ADUs. If the DSCP field of the first IP packet indicates '0' and the DSCP field of the third IP packet can indicate '0', then the UPF can determine that the first IP packet and the third IP packet can be associated with the same ADU. For example, if the DSCP field of the first IP packet indicates '0', then the UPF can determine that the identity of the ADU associated with the first IP packet is '0'. For example, if the DSCP field of the third IP packet indicates '1', then the UPF can determine that the identity of the ADU associated with the third IP packet is '1'. For example, the UPF can use one or more fields indicated by the ADU identification assistance information to determine the ADU-related information of the received packet. For example, the ADU-related information can include the information determined by the UPF for the packet.

[0353] In an example, the UPF can determine whether one or more packets belong to the same service data flow based on the packet detection rules. For one or more packets of a service data flow, based on the ADU identification assistance information, the UPF can determine the ADU information associated with the one or more packets. For example, the ADU information associated with one or more packets can indicate the identity of the ADU associated with one or more received packets. For example, the ADU information associated with one or more packets can indicate whether one or more packets are associated with the same ADU and / or different ADUs.

[0354] In an example, similar operations can be performed by the UE and / or other NFs. In other examples, based on the ADU identification assistance information, the UE and / or other NFs can determine one or more ADU information associated with one or more packets.

[0355] In the example, for an N4 session message from the SMF, the UPF can respond to the SMF with another N4 session message (e.g., an N4 session establishment response).

[0356] In the example, after setting up the UPF for ADU-aware delivery, the SMF can invoke an AMF service request (e.g., Namf_Communication_N1N2MessageTransfer) and / or an SMF service response (e.g., an Nsmf_PDUSession_CreateSMcontext response). The AMF service request and / or the SMF service response can include:

[0357] - PDU session ID: This can indicate the identifier of the PDU session.

[0358] - N2 SM information: This can include information for setting up the N3 interface between the NG-RAN and the UPF. For example, the N2 SM information includes the associated configuration parameters for ADU-aware delivery.

[0359] - N1 SM container: This can include a PDU session establishment acceptance message.

[0360] - Associated configuration parameters for ADU-aware delivery

[0361] In the example, if the AMF receives an AMF service request and / or an SMF service response, the AMF can send an N2 message (e.g., an N2 PDU session request) to the NG-RAN. The N2 message can include:

[0362] - N2 SM information. For example, the N2 SM information includes the associated configuration parameters for ADU-aware delivery.

[0363] - NAS message: This can include an N1 SM container.

[0364] - Associated configuration parameters for ADU-aware delivery.

[0365] In an example, if the N2 message includes a NAS message, the NG-RAN may send the NAS message to the UE. If the NG-RAN receives the N2 message, the NG-RAN may configure one or more radio bearers for the UE. For the configuration of one or more radio bearers for the UE, the NG-RAN may use the associated configuration parameters of the ADU-aware delivery. For example, the NG-RAN may configure the PDCP entity and / or the SDAP entity and / or the RLC entity and / or the MAC entity to identify and / or process the ADU information associated with the packet. For example, the NG-RAN may configure the PDCP entity and / or the SDAP entity and / or the RLC entity and / or the MAC entity to include the ADU information associated with one or more protocol data units. For example, the NG-RAN may configure the PDCP entity and / or the SDAP entity and / or the RLC entity and / or the MAC entity to identify and / or process the ADU information associated with the protocol data unit based on the ADU identification assistance information.

[0366] In an example, after configuring one or more radio bearers and / or one or more N3 bearers for the UE, the NG-RAN may send an N2 message (e.g., N2 PDU session response) to the AMF. In an example, after receiving the N2 message (e.g., N2 PDU session response) from the NG-RAN, the AMF may respond to the SMF with an AMF service response and / or an SMF service request.

[0367] Figure 22 An example embodiment of the present disclosure may be depicted.

[0368] In an example, the UE may establish a PDU session for data transfer. Based on the established PDU session, the UE may send data to the AF. Based on the data received from the UE, the AF may determine that the UE requires ADU-aware delivery. For example, in order to reduce the waste of network resources and / or improve the quality of experience of the application, the AF may determine that the UE requires ADU-aware delivery. Based on the determination, the AF may initiate a procedure for requesting ADU-aware delivery to the first network node (e.g., NEF). For example, the AF may invoke a NEF service request (e.g., Nnef_AFsessionWithQoS_Create request). The NEF service request may include:

[0369] - UE address: This may indicate the identification information of the UE. For example, this may indicate the IP address of the UE.

[0370] - AF identifier: This may indicate the identity of the AF.

[0371] - Flow description: This may indicate the service data flow.

[0372] - External application identifier: This can indicate the identity of the application.

[0373] - QoS reference: This can indicate the QoS parameters for the application that the request supports.

[0374] - DNN: This can indicate the network associated with the application.

[0375] - S-NSSAI: This can indicate the network slice associated with the application.

[0376] - ADU service request information.

[0377] In the example, for a received NEF service request, the NEF can determine whether the AF is authorized for the request. If the AF is authorized for the request, the NEF can determine the PCF associated with the NEF service request. For example, the NEF can select the PCF based on the DNN and / or S-NSSAI and / or UE identity and / or IP address. The NEF can invoke a PCF service request (e.g., Npcf_PolicyAuthorization_Create request). The PCF service request can include: - UE address; - AF identifier; - Flow description; - QoS reference; - ADU service request information.

[0378] In the example, based on the UE identity and / or IP address information of the PCF service request, the PCF can identify the UE associated with the PCF service request. For the identified UE, the PCF can determine the UE's QoS parameters and / or QoS policy based on the information conveyed by the PCF service request. For example, based on the information conveyed by the PCF service request, the PCF can determine the ADU-aware delivery policy information and / or information associated with ADU-aware delivery. Based on the determined ADU-aware delivery policy information and / or information associated with ADU-aware delivery, the PCF can invoke a PCF service (e.g., Npcf_SMPolicyControl_UpdateNotify) to the SMF associated with the UE. The PCF service can include the ADU-aware delivery policy information and / or information associated with ADU-aware delivery. Based on the information delivered by the PCF service (e.g., Npcf_SMPolicyControl_UpdateNotify), the SMF can execute procedures to update the configuration of the UPF and / or NG-RAN and / or UE. For example, the SMF can execute as Figure 20 and / or Figure 21The procedures shown in the example. In the example, in response to a PCF service request (e.g., Npcf_PolicyAuthorization_Create request), the PCF can send a response to the NEF. Based on the response from the PCF, the NEF can send a response to the AF. For example, the NEF can trigger an Nnef_AFsessionWithQoS_Create response.

[0379] Figure 23 Example embodiments of the present disclosure can be depicted. In the example, the UE can perform the registration procedure of the AMF. After registration, the AF associated with the application running on the UE can request ADU-aware delivery from the network. To obtain an update on whether the UE requires ADU-aware delivery, the AMF can invoke the UDM service (e.g., Nudm_SDM_Subscribe). After registration, the AF associated with the application running on the UE can request ADU-aware delivery from the network. The request from the AF can trigger the PCF to update the policy for the UE. To receive the updated policy based on the AF's request, the AMF can invoke the PCF service (e.g., Npcf_UEPolicyControl_Create).

[0380] In the example, the UE can perform the PDU session establishment procedure with the SMF to establish a PDU session. After establishing the PDU session, the AF associated with the application running on the PDU session can request ADU-aware delivery from the network. To obtain an update on whether the PDU session requires ADU-aware delivery, the SMF can invoke the UDM service (e.g., Nudm_SDM_Subscribe). After establishing the PDU session, the AF associated with the application running on the UE can request ADU-aware delivery from the network. The request from the AF can trigger the PCF to update the policy for the PDU session. To receive the updated policy based on the AF's request, the SMF can invoke the PCF service (e.g., Npcf_SMPolicyControl_Create).

[0381] In the example, the PCF may need to provide the updated policy for the UE to the AMF. The PCF may need to provide the updated policy for the PDU session to the SMF. To determine whether to determine the updated policy, the PCF can invoke the UDR service (e.g., Nudr_DM_Subscribe, Nudr_DM_Notify).

[0382] In an example, the AF may determine that the requested network provides an ADU-aware delivery service for the UE and / or for a PDU session and / or for a UE group and / or for an application and / or for a service data flow. Based on the determination, the AF may invoke a NEF service request (e.g., Nnef_AFsessionWithQoS_Create request and / or Nnef_ServiceParameter_Create and / or Nnef_ApplyPolicy_Create, etc.). The NEF service request may include ADU service request information. Based on the NEF service request, the NEF may trigger a UDM service (e.g., Nudm_ParameterProvision_Create and / or Nudm_ServiceSpecificAuthorization_Create, etc.) and / or a UDR service (e.g., Nudr_DM_Create, etc.). The UDM service request and / or the UDR service request may include updated information for ADU-aware delivery. For example, the updated information for ADU-aware delivery may include ADU service request information. If the information associated with ADU-aware delivery is updated, the UDM and / or the UDR may determine whether there are one or more network nodes subscribed to the information update notification. For example, the one or more network nodes may be the SMF and / or the PCF and / or the AMF. The SMF may be the SMF that invokes the UDM service (e.g., Nudm_SDM_Subscribe). The AMF may be the AMF that invokes the UDM service (e.g., Nudm_SDM_Subscribe). The PCF may be the PCF that invokes the UDR service (e.g., Nudr_DM_Subscribe). Based on the determination, the UDR and / or the UDM may invoke a UDR service (Nudr_DM_Notify) and / or a UDM service (e.g., Nudm_SDM_Notification). The invoked UDR service and / or the invoked UDM service may include information associated with ADU-aware delivery. Based on the invoked UDR service and / or the invoked UDM service, the AMF and / or the SMF and / or the PCF may update configuration parameters and / or may update the configuration of network nodes (e.g., the UE and / or the UPF and / or the NG-RAN) and / or may update one or more policies.

[0383] Figure 24 Example embodiments of the present disclosure may be depicted.

[0384] In the example, the AF may provide information to the network that describes the service data flow. To help the network support ADU-aware delivery, the AF may further provide ADU identification assistance information. To provide the ADU identification assistance information, the AF may invoke a NEF service request (e.g., Nnef_PFDManagement_Create request). The NEF service request may include:

[0385] - AF identifier: This may indicate the identifier of the AF.

[0386] - One or more PFD sets: This may indicate that one or more packet filter sets are used to identify and / or detect and / or classify one or more service data flows. This can be used to identify and / or detect and / or classify one or more packets of one or more service data flows. This can be used to identify and / or detect and / or classify one or more packets of one or more service applications. This can be used to identify and / or detect and / or classify one or more packets associated with the AF. This can be used to identify and / or detect and / or classify one or more packets of service data flows and / or applications and / or the AF.

[0387] - ADU identification assistance information.

[0388] In the example, after the NEF receives the NEF service request, the NEF checks whether the AF is authorized to execute the NEF service request. If the AF is authorized, the NEF may invoke a UDR service request (e.g., Nudr_DM_Create request). The UDR service request may include an application identifier and / or one or more PFD sets and / or ADU identification assistance information. For example, one or more PFD sets may include ADU identification assistance information. For the received UDR service request, the UDR may store the received information, and the UDR may respond to the NEF with a UDR service response. After receiving the UDR service response from the UDR, the NEF may respond to the AF with a NEF service response.

[0389] In an example, the SMF may invoke the NEF service (e.g., Nnef_PFDManagement_Fetch). For example, the SMF may receive an application identifier during a PDU session establishment procedure and / or during a PDU session modification procedure. For example, if the PCF sends policy information to the SMF, the SMF may receive the application identifier from the PCF. For example, if the SMF receives subscription information from the UDM, the SMF may receive the application identifier from the UDM. If the SMF does not have associated information for the application identifier, the SMF may invoke a NEF service request (e.g., Nnef_PFDManagement_Fetch request). For example, the NEF service request may include the application identifier. For the invoked NEF service, if one or more PFDS for the application identifier are not available, the NEF may invoke a UDR service request (e.g., Nudr_DM_Query request) from the UDR. For the invoked UDR service request, the UDR may respond with a UDR service response (e.g., Nudr_DM_Query response). The UDR service response may include the application identifier and / or one or more PFDS. For the invoked NEF service request, the NEF may respond to the SMF with a NEF service response (e.g., Nnef_PFDManagement_Fetch response). The NEF service response may include one or more PFDS. In an example, if information associated with ADU-aware delivery is available, one or more PFDS may further include information associated with ADU-aware delivery. In an example, based on the received one or more PFDS, if one or more PFDS include information associated with ADU-aware delivery, the SMF may perform a procedure to update the configuration of the UPF and / or the NG-RAN and / or the UE. For example, the SMF may perform the procedure shown in the example of Figure 20 and / or Figure 21 to configure the UPF and / or the NG-RAN and / or the UE to support ADU-aware delivery. The SMF may send an N4 message to the UPF. The N4 message may include information associated with ADU-aware delivery. Based on the information delivered from the SMF, the UPF may determine the associated ADU information for the packet.

[0390] Figure 25 Example embodiments of the present disclosure may be depicted.

[0391] In an example, the network may configure one or more network nodes for ADU-aware delivery. Figure 19 、 Figure 20 、 Figure 21 、 Figure 22 、 Figure 23 、 Figure 24 Examples of may be used to deliver the associated configuration parameters for ADU-aware delivery to one or more network nodes.

[0392] In an example, one or more incoming packets sent by the AF can reach the UPF. For example, one or more packets can be generated by an application of the UE. The UPF, the NG-RAN, and / or the UE can detect and / or identify and / or classify one or more packets based on the associated configuration parameters of ADU-aware delivery. The UPF, the NG-RAN, and / or the UE can process one or more packets based on the associated configuration parameters of ADU-aware delivery. The UPF, the NG-RAN, and / or the UE can send information associated with the ADU of one or more packets.

[0393] Figure 26 Example embodiments of the present disclosure can be depicted.

[0394] In an example, for one or more packets sent by the AF, the UPF can detect and / or identify and / or classify the packets based on the associated configuration parameters of ADU-aware delivery. For example, the UPF can receive one or more packets including a first packet and / or a second packet and / or a third packet. Based on the associated configuration parameters of ADU-aware delivery, the UPF can determine that the first packet and the second packet are associated with a first ADU. Based on the associated configuration parameters of ADU-aware delivery, the UPF can determine that the third packet is associated with a second ADU. The UPF can determine that the first packet is associated with the second packet. The UPF can determine that the first packet is not associated with the third packet. The UPF can determine that the second packet is not associated with the third packet. The UPF can determine that the first packet and the third packet are not associated with the same ADU. The UPF can determine that the first packet and the second packet are associated with the same ADU. For example, the UPF can use Figure 19 and / or Figure 20 as examples.

[0395] In an example, for one or more incoming packets sent by the AF, the UPF may detect and / or identify and / or classify the packets based on the associated configuration parameters of ADU-aware delivery. For example, the UPF may receive one or more packets including a first packet and / or a second packet and / or a third packet. Based on the associated configuration parameters of ADU-aware delivery, the UPF may determine that the first packet and the second packet are associated with a first ADU. Based on the associated configuration parameters of ADU-aware delivery, the UPF may determine that the third packet is associated with a second ADU. The UPF may determine that the first packet is associated with the second packet. The UPF may determine that the first packet is not associated with the third packet. The UPF may determine that the second packet is not associated with the third packet. The UPF may determine that the first packet and the third packet are not associated with the same ADU. The UPF may determine that the first packet and the second packet are associated with the same ADU. The UPF may determine the identity information of the first ADU associated with the first packet. The UPF may determine the identity information of the second ADU associated with the second packet. The UPF may determine the identity information of the third ADU associated with the third first packet. The determined information may be ADU identification information. For example, the UPF may use Figure 19 and / or Figure 20 as an example.

[0396] In an example, based on the determination of one or more packets, the UPF may send one or more GTP-U containers (e.g., GTP-U packets) to the NG-RAN. The one or more GTP-U containers may include a first GTP-U container and / or a second GTP-U container and / or a third GTP-U container. The one or more GTP-U containers may include one or more packets and / or one or more GTP-U headers. The first GTP-U container may include a first packet and a first GTP-U header. The second GTP-U container may include a second packet and a second GTP-U header. The third GTP-U container may include a third packet and a third GTP-U header.

[0397] In an example, one or more GTP-U headers may include one or more extension headers. For example, Figure 27 may show an example of a GTP-U container.

[0398] In an example, one or more extension headers may include:

[0399] - PDU type: This may indicate the structure of the GTP-U container and / or the GTP-U header and / or the GTP-U extension header and / or the UP frame.

[0400] - QoS monitoring packet: This may indicate whether the packet in the GTP-U container is used for QoS monitoring.

[0401] - Serial number presence: This can indicate whether a DL QFI serial number exists in the GTP-U container.

[0402] - Paging policy presence: This can indicate the presence of PPI in the GTP-U container.

[0403] - Reflected QoS indicator: This can indicate whether reflected QoS is activated.

[0404] - QoS flow identifier: This can indicate the identity of the QoS flow associated with the packets in the GTP-U container.

[0405] - Paging policy indicator: This can indicate the paging policy indicator.

[0406] - DL transmission timestamp: This can indicate when the UPF sends the GTP-U container.

[0407] - DL QFI serial number: This can indicate the serial number assigned by the UPF for the QoS flow.

[0408] - ADU identification information: This can indicate information associated with ADU-aware delivery. For example, this can include ADU-related information associated with the packets in the GTP-U container. For example, this can indicate which packet or packets are associated with the same ADU. For example, this can indicate which packet or packets are associated with different ADUs. For example, this can indicate the identity associated with the ADU associated with the packet.

[0409] For example, the first GTP-U header can include first ADU identification information. The first ADU identification information can indicate that the associated ADU identification of the first packet can be 1. For example, the second GTP-U header can include second ADU identification information. The second ADU identification information can indicate that the associated ADU identification of the second packet can be 1. For example, the third GTP-U header can include third ADU identification information. The third ADU identification information can indicate that the associated ADU identification of the third packet can be 2. Based on the ADU identification information of one or more GTP-U headers, the NG-RAN can determine that the first packet and the second packet are associated with the same ADU. Based on the ADU identification information of one or more GTP-U headers, the NG-RAN can determine that the first packet and the third packet are associated with different ADUs.

[0410] In another example, the SMF may determine that the NG-RAN performs the identification of the associated ADU of the packet. For example, the SMF may determine that the UPF does not perform the identification of the associated ADU of the packet. Based on the determination, the SMF may configure the UPF not to perform the identification of the ADU of the packet. Based on the determination, the SMF may configure the NG-RAN to perform the identification of the ADU of the packet. After the configuration, if one or more packets arrive at the UPF, the UPF may send one or more GTP-U containers including one or more packets. The GTP-U containers may not include ADU identification information. If the NG-RAN receives one or more GTP-U containers, the NG-RAN may perform the identification of the ADU associated with one or more packets. One or more GTP-U containers may include the first packet and / or the second packet and / or the third packet. For example, based on the associated configuration parameters of the ADU-aware delivery, the NG-RAN may determine that the first packet and the second packet are associated with the first ADU. Based on the associated configuration parameters of the ADU-aware delivery, the NG-RAN may determine that the third packet is associated with the second ADU. The NG-RAN may determine that the first packet is associated with the second packet. The NG-RAN may determine that the first packet is not associated with the third packet. The NG-RAN may determine that the second packet is not associated with the third packet. The NG-RAN may determine that the first packet and the third packet are not associated with the same ADU. The NG-RAN may determine that the first packet and the second packet are associated with the same ADU. For example, the NG-RAN may use Figure 19 and Figure 20 as examples.

[0411] Figure 28 may depict example embodiments of the present disclosure.

[0412] In an example, based on the associated configuration parameters of the ADU-aware delivery, a transmitting party (e.g., the UE and / or the NG-RAN) may perform the identification of the ADU for one or more packets received from an upper layer (e.g., an application of the UE and / or the UPF). For example, the SDAP entity and / or the PDCP entity of the transmitting party may receive one or more packets from the upper layer. The one or more packets may include the first packet and / or the second packet and / or the third packet. For example, based on the associated configuration parameters of the ADU-aware delivery, the transmitting party may determine that the first packet and the second packet are associated with the first ADU. Based on the associated configuration parameters of the ADU-aware delivery, the transmitting party may determine that the third packet is associated with the second ADU. The transmitting party may determine that the first packet is associated with the second packet. The transmitting party may determine that the first packet is not associated with the third packet. The transmitting party may determine that the second packet is not associated with the third packet. The transmitting party may determine that the first packet and the third packet are not associated with the same ADU. The transmitting party may determine that the first packet and the second packet are associated with the same ADU. For example, the transmitting party may use Figure 19 and / or Figure 20Examples. After the determination, the transmitting side may send one or more PDCP PDUs and / or one or more SDAP PDUs to the receiving side (e.g., NG-RAN and / or UE). For example, one or more PDCP PDUs may include a first PDCP PDU and / or a second PDCP PDU and / or a third PDCP PDU. For example, one or more SDAP PDUs may include a first SDAP PDU and / or a second SDAP PDU and / or a third SDAP PDU. One or more PDCP PDUs and / or one or more SDAP PDUs may include ADU identification information. For example, the first PDCP PDU and / or the first SDAP PDU may include a first packet. The header of the first PDCP PDU and / or the first SDAP PDU may include information about the ADU associated with the first PDCP PDU and / or the first SDAP PDU and / or the first packet. For example, the second PDCP PDU and / or the second SDAP PDU may include a second packet. The header of the second PDCP PDU and / or the second SDAP PDU may include information about the ADU associated with the second PDCP PDU and / or the second SDAP PDU and / or the second packet. For example, the third PDCP PDU and / or the third SDAP PDU may include a third packet. The header of the third PDCP PDU and / or the third SDAP PDU may include information about the ADU associated with the third PDCP PDU and / or the third SDAP PDU and / or the third packet. For example, if the ADU associated with the first PDCP PDU is the same as the ADU associated with the second PDCP PDU, the first PDCP PDU and / or the second PDCP PDU may include information indicating that the first PDU and the second PDU are associated with the same ADU and / or the identity information of the ADU. For example, if the ADU associated with the first PDCP PDU is different from the ADU associated with the third PDCP PDU, the first PDCP PDU and / or the third PDCP PDU may include information indicating that the first PDU and the third PDU are associated with different ADUs and / or the identity information of the ADU.

[0413] In another example, the receiving party may receive one or more PDCP PDUs and / or one or more PDCP SDUs. The one or more PDCP PDUs may include a first PDCP PDU and / or a second PDCP PDU and / or a third PDCP PDU. The one or more SDAP PDUs may include a first SDAP PDU and / or a second SDAP PDU and / or a third SDAP PDU. The one or more PDCP PDUs and / or the one or more SDAP PDUs may include ADU identification information. Based on the ADU identification information, the PDCP entity and / or the SDAP entity of the receiving party may identify one or more ADUs associated with the one or more PDCP PDUs and / or the one or more SDAP PDUs. For example, the PDCP entity and / or the SDAP entity of the receiving party may determine whether the first PDCP PDU and the second PDCP PDU are associated with the same ADU. For example, the PDCP entity and / or the SDAP entity of the receiving party may determine whether the first PDCP PDU and the third PDCP PDU are associated with different ADUs.

[0414] Figure 29 may depict an example embodiment of the present disclosure.

[0415] In other examples, one or more PDCP PDUs may include ADU identification information. For example, the PDCP entity of the UE and / or the NG-RAN may determine the ADU identification information, as Figure 28 shown in the example of. In Figure 29A one or more PDCP PDUs may include:

[0416] - PDCP SN: This may indicate the sequence number of the PDCP SDU.

[0417] - MAC-I: This may indicate the information for checking the integrity of the PDCP PDU.

[0418] - ADU identification: This may indicate the information of the ADU associated with the PDCP SDU.

[0419] - Data: This may indicate the PDCP SDU.

[0420] In an example, one or more SDAP PDUs may include ADU identification information. For example, the SDAP entity of the UE and / or the NG-RAN may determine the ADU identification information, as Figure 28 shown in the example of. In Figure 29B one or more SDAP PDUs may include:

[0421] - RDI (Reflected QoS Flow to DRB Mapping Indication): This can indicate whether the QoS flow to DRB mapping rule should be updated.

[0422] - RQI (Reflected QoS Indication): This can indicate whether the NASS should be notified that the SDF to QoS flow mapping rule has been updated.

[0423] - ADU Identification: This can indicate information about the ADU associated with the SDAP SDU.

[0424] - Data: This can indicate the SDAP SDU.

[0425] In an example, one or more RLC PDUs can include ADU identification information. For example, the RLC entity of the UE and / or the NG-RAN can determine the ADU identification information, as shown in the example of Figure 28 In Figure 29C one or more RLC PDUs can include:

[0426] - D / C (Data / Control): This can indicate whether the RLC PDU is a control PDU or a data PDU.

[0427] - P: This can indicate whether polling is triggered.

[0428] - SI: This can indicate how to align the RLC SDU and the RLC PDU.

[0429] - SN: This can indicate the sequence number associated with the RLC PDU.

[0430] - ADU Identification: This can indicate information about the ADU associated with the SDAP SDU.

[0431] - Data: This can indicate the RLC SDU.

[0432] Figure 30 Example embodiments of the present disclosure can be depicted.

[0433] In an example, the UPF can send one or more GTP-U containers to the NG-RAN. One or more GTP-U containers can include a first GTP-U container and / or a second GTP-U container and / or a third GTP-U container. One or more GTP-U containers can include one or more packets and / or one or more GTP-U headers and / or one or more UPF headers, etc. The first GTP-U container can include a first packet and a first GTP-U header and / or a first UPF header, etc. The second GTP-U container can include a second packet and a second GTP-U header and / or a second UPF header, etc. The third GTP-U container can include a third packet and a third GTP-U header and / or a third UPF header, etc.

[0434] In an example, one or more UPF headers may include information identifying an ADU. For example, the first UPF header may include information that the first packet may be associated with the first ADU. For example, the second UPF header may include information that the second packet may be associated with the second ADU. For example, the third UPF header may include information that the third packet may be associated with the third ADU.

[0435] In an example, the NG-RAN may receive one or more GTP-U containers. Based on the one or more GTP-U containers, the NG-RAN may send one or more PDCP PDUs and / or one or more SDAP PDUs. The one or more PDCP PDUs and / or the one or more SDAP PDUs may include one or more UPF headers and / or packets. For example, the one or more PDCP PDUs may include a first PDCP PDU and / or a second PDCP PDU and / or a third PDCP PDU. For example, the one or more SDAP PDUs may include a first SDAP PDU and / or a second SDAP PDU and / or a third SDAP PDU. The first PDCP PDU and / or the first SDAP PDU may include a first UPF header. The second PDCP PDU and / or the second SDAP PDU may include a second UPF header. The third PDCP PDU and / or the third SDAP PDU may include a third UPF header. The SDAP entity and / or the PDCP entity of the UE may receive the one or more PDCP PDUs and / or the one or more SDAP PDUs. Based on the one or more UPF headers of the one or more PDCP PDUs and / or the one or more SDAP PDUs, the UE may identify one or more ADUs associated with the one or more packets of the one or more PDCP PDUs and / or the one or more SDAP PDUs. For example, based on the one or more UPF headers, the UE may determine that the first packet and the second packet may be associated with the same ADU. For example, based on the one or more UPF headers, the UE may determine that the first packet and the third packet may be associated with different ADUs.

[0436] In an example, the UE may receive one or more packets from an upper layer. Based on the associated configuration parameters of ADU-aware delivery, the UE may identify one or more ADUs associated with the one or more packets. Based on the identification, the UE may send one or more PDCP PDUs and / or one or more SDAP PDUs to the NG-RAN. The one or more PDCP PDUs and / or the one or more SDAP PDUs may include one or more UPF headers and / or packets. For example, the one or more PDCP PDUs may include a first PDCP PDU and / or a second PDCP PDU and / or a third PDCP PDU. For example, the one or more SDAP PDUs may include a first SDAP PDU and / or a second SDAP PDU and / or a third SDAP PDU. The first PDCP PDU and / or the first SDAP PDU may include a first UPF header. The second PDCP PDU and / or the second SDAP PDU may include a second UPF header. The third PDCP PDU and / or the third SDAP PDU may include a third UPF header. The SDAP entity and / or the PDCP entity of the NG-RAN may receive the one or more PDCP PDUs and / or the one or more SDAP PDUs. For the received one or more PDCP PDUs and / or one or more SDAP PDUs, the NG-RAN may deliver the one or more packets and the one or more UPF headers to the UPF. Based on the one or more UPF headers, the UPF may identify one or more ADUs associated with the packets.

[0437] In an example, the UE or the UPF may construct one or more UPF headers. The one or more UPF headers may not be interpreted by the NG-RAN. The UPF headers may be used to directly deliver and exchange one or more information between the UE and the UPF. For example, the UE and the UPF may exchange information on the quality of service of one or more ADUs and / or one or more applications and / or one or more service data flows. For example, the UE and the UPF may exchange configuration information of one or more ADUs and / or one or more applications and / or one or more service data flows.

[0438] Figure 31 Example embodiments of the present disclosure may be depicted.

[0439] In an example, an application layer (e.g., an application, an RTP entity, a TCP entity, a UDP entity, a NAL entity) may generate one or more ADUs. The one or more ADUs may include a first ADU and / or a second ADU. The one or more ADUs may be packed into one or more packets. A first set of the one or more packets may carry the payload (data) of the first ADU. A second set of the one or more packets may carry the payload of the second ADU. The first set may be the (first) packet set among the one or more packet sets. The second set may be the (second) packet set among the one or more packet sets. In other words, the one or more packets of an ADU may be a packet set. Different packet sets may be associated with different ADUs. For example, a packet may be a PDU and / or an ADU may be an information unit generated by an application. A set of PDUs may be constituted by one or more PDUs for an information unit. Different sets of PDUs may be constituted by different PDUs for different information units. For example, the one or more packets may be one or more IP packets. For example, the one or more packets may belong to the same service data flow and / or different service data flows. The one or more packets may include a first packet and / or a second packet and / or a third packet and / or a fourth packet. The one or more packets may include one or more packet headers and / or one or more packet payloads. For example, the first packet may include at least a part of the first ADU. For example, the second packet may include at least a part of the first ADU. The first packet (e.g., the first PDU) and the second packet (e.g., the second PDU) may be associated with the first ADU, and / or carry the payload of the first ADU. Since the first packet and the second packet carry one or more parts of the same ADU, the first packet and the second packet belong to the same packet set (e.g., the first packet set), and / or the first packet and the second packet may be regarded as being associated with the same packet set. In other words, since the first PDU (e.g., the first packet) and the second PDU (e.g., the second packet) include one or more parts of the same data unit of an application, the first PDU and the second PDU belong to (are associated with) the same set of PDUs (e.g., PDU set 1, i.e., the first PDU set). The first PDU set may be constituted by the first PDU and the second PDU. For example, the third packet may include at least a part of the second ADU. For example, the fourth packet may include at least a part of the second ADU. The third packet (e.g., the third PDU) and the fourth packet (e.g., the fourth PDU) may be associated with the second ADU, and / or carry the payload of the second ADU. Since the third packet and the fourth packet carry one or more parts of the same ADU, the third packet and the fourth packet belong to the same packet set (e.g., the second packet set), and / or the third packet and the fourth packet may be regarded as being associated with the same packet set.In other words, since the third PDU (e.g., the third packet) and the fourth PDU (e.g., the fourth packet) include one or more parts of the same data unit of the application, the third PDU and the fourth PDU belong to (are associated with) the same PDU set (e.g., PDU set 2, i.e., the second PDU set). The second PDU set may be constituted by the third PDU and the fourth PDU. One or more packet headers may include one or more fields associated with identifying one or more ADUs. One or more fields associated with one or more ADUs may indicate information for identifying one or more ADUs associated with one or more packets. One or more fields associated with one or more ADUs may indicate information for determining which or which packets are associated with the same ADU. One or more fields associated with one or more ADUs may indicate information for determining which or which packets are associated with different ADUs.

[0440] For example, a field associated with one or more ADUs may be one of the fields in an IP packet. For example, the DSCP field and / or the TOS field of an IP packet may be one of the fields associated with the identification of one or more ADUs. For example, based on this packet including a part of the first ADU, the field (e.g., the DSCP field) of the first packet may be set to 1. For example, based on this packet including a part of the first ADU, the field of the second packet may be set to 1. For example, based on this packet including a part of the second ADU, the field of the third packet may be set to 2. Based on different values of the fields of different packets, the recipient of the packets (e.g., a network node) may determine that the first packet and the second packet are associated with the same ADU. Based on different values of the fields, the recipient of the packets (e.g., a network node) may determine that the second packet and the third packet are associated with different ADUs. Based on the value of the field, the recipient of the packets (e.g., a network node) may determine that the ADU identity associated with the first packet is 1. Based on the value of the field, the recipient of the packets (e.g., a network node) may determine that the ADU identity associated with the second packet is 1. Based on the value of the field, the recipient of the packets (e.g., a network node) may determine that the ADU identity associated with the third packet is 2. The recipient may use the determined information and may include the determined information in the ADU identification information and / or the ADU related information.

[0441] Figure 32 Example embodiments of the present disclosure may be depicted.

[0442] In an example, an application layer (e.g., an application, a NAL entity) may generate one or more first-type ADUs. The one or more first-type ADUs may include a first first-type ADU and / or a second first-type ADU. The one or more first-type ADUs may be delivered to a protocol entity (e.g., an RTP protocol entity). The protocol entity may package the one or more first-type ADUs into one or more second-type ADUs (e.g., RTP packets). For example, the one or more first-type ADUs and / or the one or more second-type ADUs may belong to the same service data stream and / or different service data streams. The one or more second-type ADUs may include a first second-type ADU and / or a second second-type ADU and / or a third second-type ADU and / or a fourth second-type ADU. The one or more second-type ADUs may include one or more second-type ADU headers and / or one or more second-type ADU payloads. For example, the first second-type ADU may include at least a portion of the first first-type ADU. For example, the second second-type ADU may include at least a portion of the first first-type ADU. For example, the third second-type ADU may include at least a portion of the second first-type ADU. For example, the fourth second-type ADU may include at least a portion of the second second-type ADU. The one or more second-type ADU headers may include one or more fields associated with identifying the one or more ADUs. The one or more fields associated with the one or more ADUs may indicate information for identifying the one or more ADUs and / or the one or more second-type ADUs associated with one or more packets. The one or more fields associated with the one or more ADUs may indicate information for determining which packet or packets and / or the one or more second-type ADUs are associated with the same first-type ADU. The one or more fields associated with the one or more ADUs may indicate information for determining which packet or packets and / or the one or more second-type ADUs are associated with different first-type ADUs.

[0443] In an example, one or more second-type ADUs can be delivered to a packet protocol entity (e.g., an IP protocol entity). One or more second-type ADUs can be packed into one or more packets. For example, one or more packets can be one or more IP packets. For example, one or more packets can belong to the same service data flow and / or different service data flows. One or more packets can include a first packet and / or a second packet and / or a third packet and / or a fourth packet. One or more packets can include one or more packet headers and / or one or more packet payloads. For example, the first packet can include at least a part of a first first-level ADU. For example, the first packet can include at least a part of a first second-level ADU. For example, the second packet can include at least a part of a first first-level ADU. For example, the second packet can include at least a part of a second second-level ADU. For example, the third packet can include at least a part of a second first-level ADU. For example, the third packet can include at least a part of a third second-level ADU. For example, the fourth packet can include at least a part of a second first-level ADU. For example, the fourth packet can include at least a part of a fourth second-level ADU.

[0444] In an example, a field associated with one or more ADUs can be one of the fields of the second-type ADUs of one or more packets. For example, for one or more packets, the timestamp field of an RTP packet can be one of the fields associated with the identification of one or more ADUs.

[0445] In an example, based on that this packet includes a part of a first ADU, a field associated with one or more ADUs (e.g., the timestamp field) can be set to 1, and the one or more ADUs are associated with the first packet. For example, based on that this packet includes a part of a first ADU, a field associated with one or more ADUs (e.g., the timestamp field) can be set to 1, and the one or more ADUs are associated with the second packet. For example, based on that this packet includes a part of a second ADU, a field associated with one or more ADUs (e.g., the timestamp field) can be set to 2, and the one or more ADUs are associated with the third packet. For example, based on that this packet includes a part of a second ADU, a field associated with one or more ADUs (e.g., the timestamp field) can be set to 2, and the one or more ADUs are associated with the fourth packet.

[0446] In an example, a recipient of a packet can use fields associated with one or more ADUs to determine ADU-related information for one or more packets, where the one or more ADUs are associated with the one or more packets. For example, based on a field of a first packet (e.g., a timestamp field) being set to 1 and a field of a second packet being set to 1, the recipient can determine that the first packet and the second packet are associated with the same ADU. For example, based on a field of the first packet being set to 1 and a field of a third packet being set to 2, the recipient can determine that the first packet and the third packet are associated with the same ADU. For example, based on a field of the first packet being set to 1, the recipient can determine that the identity of the ADU associated with the first packet is 1. The recipient can use the determined information and can include the determined information in the ADU identification information and / or the ADU-related information.

[0447] Figure 33 Example embodiments of the present disclosure may be depicted.

[0448] In an example, the upper layer of a sender (e.g., a UE, an AF), such as above the 3GPP NAS layer, may be composed of one or more layers (e.g., protocol entities). For example, one or more layers may include a first-level layer and / or a second-level layer. The first-level layer may generate one or more first-level ADUs. The one or more first-level ADUs may include a first first-level ADU and / or a second first-level ADU. The first-level layer may deliver the one or more first-level ADUs to the second-level layer. The second-level layer may process the one or more first-level ADUs and may generate one or more second-level ADUs. For example, based on the first first-level ADU, the second-level layer may generate a first second-level ADU and / or a second second-level ADU. For example, based on the second first-level ADU, the second-level layer may generate a third second-level ADU. Based on the one or more second-level ADUs, the sender may generate one or more packets. For example, the first packet may include the first second-level ADU. For example, the second packet may include the second second-level ADU. For example, the third packet may include the third second-level ADU. The one or more second-level ADUs may include one or more fields associated with one or more ADU identifiers. In an example, to identify the ADU associated with a packet, the AF and the network may negotiate one or more fields of the ADU. Based on the one or more fields, the sender (e.g., the AF, an application) may use the one or more fields to indicate to the receiver information about the ADU associated with the packet. Based on the one or more fields, the receiver (e.g., the UPF, the UE, the NG-RAN) may use the one or more fields to identify the ADU associated with the received packet. In an example, to identify the ADU associated with a packet, the AF may indicate one or more fields of the ADU to the network. For example, the one or more fields may include the timestamp field of the RTP header. For example, the timestamp field of the first second-level ADU may be set to t = 1. For example, the timestamp field of the second second-level ADU may be set to t = 1. For example, the timestamp field of the third second-level ADU may be set to t = 2. The receiver may receive one or more packets including the one or more second-level ADUs. The receiver may identify the one or more ADUs associated with the packets. For example, the receiver may use the fields negotiated with the AF and / or indicated by the AF. For example, based on the field (e.g., the timestamp field) of the first packet being set to t = 1 and the field of the second packet being set to t = 1, the receiver may determine that the first packet and the second packet may be associated with the same ADU. For example, based on the field of the first packet being set to t = 1 and the field of the third packet being set to t = 2, the receiver may determine that the first packet and the second packet may be associated with different ADUs. The determined information may be used as ADU-related information and / or ADU identification information.

[0449] In an example, a first network node (e.g., UPF, NG-RAN, UE) may receive data unit processing configuration information (e.g., associated configuration parameters for ADU-aware delivery) from a second network node (e.g., SMF). The first network node may receive one or more first type packets (e.g., IP packets) from an application and / or AF. The one or more first type packets may include one or more packet payloads and / or one or more packet headers (e.g., IP headers). The one or more packet payloads may include one or more data units (e.g., ADUs). For example, the one or more data units may include data of an application and / or data of AF and / or one or more RTP frames and / or one or more video data frames and / or one or more files and / or one or more NAL frames and / or UDP datagrams and / or TCP frames, etc. Based on the data unit processing configuration information, for the one or more first type packets, the first network node may determine one or more data unit identification information associated with the one or more first type packets. For example, the one or more data unit identification information may include information indicating one or more identities of the one or more data units. For example, the one or more data unit identification information may include information indicating which or which first type packets are associated with the data unit. For example, the one or more data unit identification information may include information indicating whether the one or more first type packets are associated with different data units. For the one or more first type packets, the first network node may send one or more second type packets. The one or more second type packets may include the one or more first type packets and / or one or more data unit identification information associated with the one or more first type packets.

[0450] In an example, a first network node (e.g., UPF, NG-RAN, UE) may receive data unit processing configuration information (e.g., associated configuration parameters for ADU-aware delivery) from a third network node (e.g., SMF). The third network node may build the data unit processing configuration information based on information delivered from a fourth network node (e.g., PCF, UDM, NEF, AF). The data unit processing configuration information may include information associated with identifying one or more data units associated with one or more first type packets.

[0451] In an example, a first network node may receive one or more first type packets (e.g., IP packets) from an application and / or an AF. The one or more first type packets may be for the same application and / or service data stream. The one or more first type packets may include one or more packet payloads and / or one or more packet headers (e.g., IP headers). The one or more packet payloads may include one or more data units (e.g., ADUs). For example, the one or more data units may include application data and / or AF data and / or one or more RTP frames and / or one or more video data frames and / or one or more files and / or one or more NAL frames and / or UDP datagrams and / or TCP frames, etc.

[0452] In an example, the one or more first type packets may include a first first type packet and a second first type packet.

[0453] In an example, based on data unit processing configuration information, for the one or more first type packets, the first network node may determine one or more data unit identification information associated with the one or more first type packets. For example, the one or more data unit identification information may include information indicating one or more identities of the one or more data units associated with the one or more first type packets. For example, the one or more data unit identification information may include information indicating which or which first type packets are associated with the data unit. For example, the one or more data unit identification information may include information indicating whether the one or more first type packets are associated with different data units. For example, the one or more data unit identification information may include information indicating the identification of the data unit associated with the first type packet.

[0454] For example, based on data unit processing configuration information, a first network node may determine whether a first packet of a first type is associated with a second packet of the first type. For example, if the data units associated with the first packet of the first type are the same as the data units associated with the second packet of the first type, the first network may determine that the first packet of the first type is associated with the second packet of the first type. For example, if the processing of the data unit associated with the first packet of the first type depends on the availability of the data unit associated with the second packet of the first type, the first packet of the first type and the second packet of the first type may be associated. For example, if the processing of the data unit associated with the first packet of the first type depends on the availability of the data unit associated with the second packet of the first type, the first packet of the first type and the second packet of the first type may be associated. For example, if a specific field of the first packet of the first type is the same as a specific field of the second packet of the first type, the first packet of the first type and the second packet of the first type may be associated. The specific field of the first type of packet may be located in the first type of packet header and / or within the first type of packet payload. For example, the specific field may be the DSCP field of the IP header and / or the option field of the IP header and / or the timestamp field of the RTP header and / or a field of the TCP header and / or a field of the UCP header, etc. Information about the specific field may be determined by the network and / or by the AF.

[0455] In an example, the data unit processing configuration information may include information about the processing of one or more received packets of the first type. For example, based on the identified one or more data unit identification information associated with one or more packets of the first type, the information about the processing of one or more received packets of the first type may include the information executed by the first network node for one or more received packets of the first type. For example, the information about the processing of one or more received packets of the first type may indicate that the first network node includes the identified one or more data unit identification information associated with one or more packets of the first type into one or more packets of the second type.

[0456] In an example, a second network node (e.g., NG-RAN) may receive data unit processing configuration information (e.g., associated configuration parameters for ADU-aware delivery) from a third network node (e.g., SMF). The second network node may process one or more received packets of the second type based on the received data unit processing configuration information. For the received data unit processing configuration information, the second network node may send an acknowledgement of the received data unit processing configuration information to the third network node.

[0457] In an example, a first network device (e.g., UPF, NG-RAN, UE) may receive, from a second network node (e.g., SMF), a message (e.g., N4 session message, N2 SM container, PDU session establishment message) including data unit configuration information (e.g., associated configuration parameters for ADU-aware delivery). The data unit configuration information may include information indicating how to determine a data unit (DU) associated with a received packet based on the content of the received packet. For example, the first network node may receive one or more packets. The one or more packets may include one or more data units. The one or more data units may be generated by one or more first entities. The one or more data units may be generated by one or more second entities. The one or more contents of the one or more packets may include one or more data units and / or one or more parts of the one or more data units.

[0458] In an example, the first network node may receive one or more first packets (e.g., IP packets) from an application server (e.g., AF). The one or more first packets may include one or more packet payloads and / or one or more packet headers (e.g., IP header). The one or more packet payloads may include one or more data units (e.g., DU) and / or one or more parts of the one or more data units. For example, the one or more data units may include application data and / or AF data and / or one or more RTP frames and / or one or more video data frames and / or one or more files and / or one or more NAL frames and / or UDP datagrams and / or TCP frames, etc. Based on the data unit configuration information, for the one or more first packets, the first network node may determine one or more data unit indication information associated with the one or more first type packets. For example, the one or more data unit indication information may include information indicating one or more identities of the one or more data units. For example, the one or more data unit indication information may include information indicating which of the one or more first packets is / are associated with the data unit. For example, the one or more data unit indication information may include information indicating whether the one or more first packets are associated with different data units. For example, the one or more data unit indication information may include information indicating which of the one or more first packets is / are associated with the data unit.

[0459] In an example, for the one or more first packets, the first network node may send one or more second packets (e.g., GTP-U containers) to an access node (e.g., NG-RAN, gNB). The one or more second packets may include the one or more first packets and / or one or more data unit indication information associated with the one or more first packets.

[0460] In an example, a first network node (e.g., UPF, NG-RAN, UE) may receive data unit configuration information (e.g., associated configuration parameters for ADU-aware delivery) from a second network node (e.g., SMF). The second network node may construct the data unit configuration information based on information delivered from a fourth network node (e.g., PCF, UDM, NEF, AF). The first network node may send a message acknowledging the data unit configuration information. The data unit configuration information may include information associated with identifying one or more data units, where the one or more data units are associated with one or more first packets. The data unit configuration information may include information on how to determine the data units associated with one or more first packets.

[0461] In an example, a first network node may receive one or more third packets. The one or more third packets may include one or more packet payloads and / or one or more packet headers. The one or more packet payloads may include at least a portion of at least one second DU. The first network node may send one or more fourth packets to an access node. The one or more fourth packets may include one or more third packets and / or one or more indications of at least one second DU.

[0462] In an example, the data unit configuration information may include information indicating whether the UPF determines an indication of at least one first DU based on the content of a first packet. For example, if the data unit configuration information indicates that the UPF determines an indication of at least one first DU, the UPF may determine the indication of at least one first DU. For example, if the data unit configuration information indicates that the UPF determines an indication of at least one first DU, the UPF may send one or more second packets including the indication of at least one first DU to an access node. For example, if the data unit configuration information does not indicate that the UPF determines an indication of at least one first DU, the UPF may not determine the indication of at least one first DU. For example, if the data unit configuration information does not indicate that the UPF determines an indication of at least one first DU, the UPF may send one or more second packets that do not include the indication of at least one first DU to an access node.

[0463] In an example, the data unit configuration information may include information indicating how to determine at least one first DU of a first packet. For example, the data unit configuration information may include information on at least one or more fields of the DU or the packet, and the one or more fields are used to determine the indication of at least one first DU of the first packet. For example, the one or more fields may include a DSCP field, a timestamp field, etc. In an example, based on the data unit configuration information, the first network node may determine the indication of the DU. For example, the indication of the DU may be a unique identifier associated with the DU. For example, the indication of the DU may be identity information associated with the DU. For example, the indication of the DU may be identity information that allows the DU to be distinguished from other DUs. For example, the indication of the DU may be information that the first packet and the third packet may belong to one DU. For example, the indication of the DU may be information that the first packet and the third packet may belong to different DUs. For example, the indication of the DU may be information that the first packet and the third packet may include a part of the data of the DU. For example, the indication of the DU may be information that the first packet and the third packet may include parts of the data of different DUs. For example, the indication of the DU may be information that the first packet and the third packet may be associated. For example, if the first packet and the third packet include at least a part of the DU, the first packet and the third packet may be associated. For example, if one or more fields of the first packet and / or the first DU have the same values as one or more fields of the third packet and / or the second DU, the first packet and the third packet may be associated. In an example, the first packet and the third packet may be received from an application function. In an example, the first packet and the third packet may belong to one service data flow. For example, if the first DU is different from the second DU, the indication of at least one second DU of the third packet may be different from the indication of at least one first DU of the first packet. For example, if the first DU is the same as the first DU, the indication of at least one second DU of the third packet may be the same as the indication of at least one first DU of the first packet.

[0464] In an example, the data unit configuration information may include information on a service data flow. The service data flow may include one or more first packets and / or one or more second packets. The information on the service data flow may include a source IP address, a destination IP address, a source port, a destination port, a source MAC address, a destination MAC address, etc. The information on the service data flow may indicate whether one or more packets belong to the same data flow.

[0465] In an example, the UPF may receive, from the SMF, a message including data unit (DU) identification configuration information, which indicates how to determine, based on the content of a received packet, identification information associated with the DU of the received packet. The UPF may receive one or more packets from the application function. The one or more packets may include a first packet. The first packet may include a portion of at least one first DU. Based on the data unit identification configuration information, the UPF may determine the identification information associated with the at least one first DU. Based on the determined identification information, the UPF may send a second packet to the access node. The second packet (e.g., GTP-U container) may include the first packet and / or the determined identification information associated with the first packet and / or the at least one first DU.

[0466] In an example, the access node (e.g., NG-RAN) may receive, from a second network node (e.g., SMF), a message (e.g., N2 message), which includes an indication that the second packet (e.g., GTP-U container) includes identification information associated with the received packet. The access node may receive the second packet from a first network node (e.g., UPF). The second packet may include the first packet and / or the identification information associated with the first packet. Based on the second packet and / or the identification information, the access node may send a third packet to the wireless device. The third packet may include the first packet.

[0467] In an example, a fourth network node (e.g., NEF) may receive, from the AF, a request message including data unit identification assistance information. The data unit identification assistance information may include information on how to identify the data unit associated with the received packet based on the content of the received packet. Based on the data unit identification assistance information, the fourth network node may determine a second network node (e.g., SMF) associated with the AF. The fourth network node may send the data unit identification assistance information to the second network node. The fourth network node may send a response message to the AF for the request message.

[0468] In an example, a first entity (e.g., PDCP entity, SDAP entity) may receive, from a second entity (e.g., application, protocol entity, SDAP entity), a first packet (e.g., SDAP PDU, IP packet, protocol data unit, application data). The first packet may include at least a portion of the data unit. The first entity may determine the data unit identification information associated with the first packet. The data unit identification information may indicate the information associated with identifying the data unit. The first entity may form one or more second packets including the first packet. The one or more second packets may further include the determined data unit identification information. The first entity may deliver the one or more second packets to a third entity (e.g., RLC entity, PDCP entity).

Claims

1. A method, which includes: receiving, by a User Plane Function (UPF) from a Session Management Function (SMF), configuration information of one or more packets associated with one or more Data Units (DUs) of a data flow; receiving, by the UPF, a first packet from an Application Function (AF); determining, by the UPF and based on the configuration information, that the first packet is one of the one or more packets associated with the first data unit; sending, by the UPF, a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) container to an access node, the GTP container including: the first packet; and a GTP header including a field indicating that the first packet is one of the one or more packets associated with the first data unit.

2. A method, which includes: sending, by the User Plane Function (UPF), a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) container to an access node, the GTP container including: a first packet; and a GTP header including a field indicating that the first packet is one of the one or more packets associated with a first data unit of a data flow.

3. The method according to claim 2, further comprising receiving, by the UPF, from the Session Management Function (SMF), configuration information of the one or more packets associated with the one or more data units of the data flow.

4. The method according to claim 3, further comprising determining, by the UPF and based on the configuration information, that the first packet is one of the one or more packets associated with the first data unit.

5. The method according to any one of claims 3 to 4, wherein the configuration information indicates one or more fields of the one or more packets.

6. The method according to claim 5, further comprising determining, by the UPF and based on the one or more fields, that the first packet is one of the one or more packets associated with the first data unit.

7. The method according to any one of claims 3 to 6, wherein the configuration information includes information of the data flow associated with the one or more packets.

8. The method according to claim 7, wherein the information of the data flow includes at least one of the following: source IP address; destination IP address; source port; destination port; source MAC address; or destination MAC address.

9. The method according to any one of claims 3 to 8, wherein the configuration information is delivered to the UPF by at least one of the following: N4 session message; N4 session establishment request; Packet Forwarding Control Protocol (PFCP) message; N2 session management (SM) container message; or SM PDU session message.

10. The method according to any one of claims 2 to 9, further comprising receiving, by the User Plane Function (UPF), from the Session Management Function (SMF), a message requesting the UPF to identify whether the received packet is one of the one or more packets associated with the first data unit of the data flow.

11. The method according to claim 10, further comprising determining, by the UPF and based on the message, that the first packet is one of the one or more packets associated with the first data unit.

12. The method according to any one of claims 2 to 11, wherein the first data stream is associated with a wireless device.

13. The method according to any one of claims 2 to 12, further comprising receiving, by the UPF, the first packet from an application function AF.

14. The method according to any one of claims 2 to 13, wherein the data unit is generated by an application layer.

15. A user plane function UPF, comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the UPF to perform the method according to any one of claims 1 to 14.

16. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 14.

17. A method, which comprises: receiving, by an access node, a General Packet Radio Service Tunneling Protocol GTP container from a user plane function UPF, the GTP container comprising: a first packet; and a GTP header comprising a field indicating that the first packet is one of the one or more packets associated with a first data unit of a data stream.

18. The method according to claim 17, wherein the access node comprises at least one of the following: gNB; eNB; N3IWF; or NG-RAN.

19. The method according to any one of claims 17 to 18, wherein the first data stream is associated with a wireless device.

20. The method according to any one of claims 17 to 19, further comprising receiving, by the UPF, the first packet from an application function AF.

21. The method according to any one of claims 17 to 20, wherein the data unit is generated by an application layer.

22. An access node, comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the access node to perform the method according to any one of claims 17 to 21.

23. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 17 to 21.

24. A system, which comprises: a user plane function UPF, comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the UPF to perform operations comprising: sending, to an access node, a General Packet Radio Service Tunneling Protocol GTP container, the GTP container comprising: a first packet; and a GTP header comprising a field indicating that the first packet is one of the one or more packets associated with a first data unit of a data stream; and The access node, where the access node includes: one or more processors; and a memory that stores instructions that, when executed by the one or more processors, cause the access node to perform operations including the following: Receive the GTP container from the UPF.

25. A method, which includes: Receiving, by a Network Exposure Function (NEF) from an Application Function (AF), assistance information for determining whether a packet is one of one or more packets associated with a data unit of a data stream; Sending, by the NEF, the assistance information to a Session Management Function (SMF); and Sending, by the NEF, an acknowledgement of the assistance information to the AF.

26. A method, which includes: Receiving, by a first network node, assistance information for determining whether a packet is one of one or more packets associated with a data unit of a data stream; and Sending, by the first network node, the assistance information to a second network node.

27. The method according to claim 26, wherein the first network node includes a Network Exposure Function (NEF).

28. The method according to any one of claims 26 to 27, wherein the second network node includes a Session Management Function (SMF).

29. The method according to any one of claims 26 to 28, wherein the first network node receives the assistance information from an Application Function (AF).

30. The method according to any one of claims 26 to 29, further comprising sending, by the first network node, an acknowledgement of the assistance information.

31. The method according to any one of claims 26 to 30, wherein the assistance information indicates one or more fields of one or more packets.

32. The method according to any one of claims 26 to 31, wherein the assistance information includes information on how to determine whether the packet is associated with the data unit.

33. The method according to any one of claims 26 to 32, wherein a first data stream is associated with a wireless device.

34. The method according to any one of claims 26 to 33, wherein the data unit is generated by an application layer.

35. The method according to any one of claims 26 to 34, further comprising receiving, by the first network node, a message requesting a data communication service, wherein the data communication service is based on determining whether the packet is one of the one or more packets associated with the data unit of the data stream.

36. The method according to claim 35, further comprising sending, by the first network node, a request for packet processing based on the determination to the second network node.

37. A first network node, comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the first network node to perform the method according to any one of claims 26 to 36.

38. A non-transitory computer-readable medium including instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 26 to 36.

39. A method, which includes: The session management function SMF receives auxiliary information from the network exposure function NEF for determining whether a packet is one of one or more packets associated with a data unit of a data stream.

40. A session management function SMF, comprising one or more processors and a memory storing instructions, which when executed by the one or more processors cause the SMF to perform the method according to claim 39.

41. A non-transitory computer-readable medium comprising instructions, which when executed by one or more processors cause the one or more processors to perform the method according to claim 39.

42. A method, which comprises: receiving, by a network exposure function NEF, a message requesting a data communication service from an application function AF, wherein the data communication service is based on determining whether the packet is one of one or more packets associated with a data unit of a data stream; sending, by the NEF, a request for packet processing based on the determination to a session management function SMF; and sending, by the NEF, an acknowledgement of the request to the AF.

43. A method, which comprises: receiving, by a first network node, a message requesting a data communication service, wherein the data communication service is based on determining whether the packet is one of one or more packets associated with a data unit of a data stream; and sending, by the first network node, a request for packet processing based on the determination to a second network node.

44. The method according to claim 43, wherein the first network node comprises a network exposure function NEF.

45. The method according to any one of claims 43 to 44, wherein the second network node comprises a session management function SMF.

46. The method according to any one of claims 43 to 45, wherein the first network node receives the message requesting the data communication service from an application function AF.

47. The method according to any one of claims 43 to 46, further comprising sending, by the first network node, an acknowledgement of the auxiliary information.

48. The method according to any one of claims 43 to 47, further comprises: receiving, by the first network node, auxiliary information for determining whether the packet is one of the one or more packets associated with the data unit of the data stream; and sending, by the first network node, the auxiliary information to the second network node.

49. A first network node, comprising one or more processors and a memory storing instructions, which when executed by the one or more processors cause the first network node to perform the method according to any one of claims 43 to 48.

50. A non-transitory computer-readable medium comprising instructions, which when executed by one or more processors cause the one or more processors to perform the method according to any one of claims 43 to 48.

51. A method, which comprises: A request message for establishing a protocol data unit (PDU) session is sent by a wireless device, where the request message includes an indication of the ability of the wireless device to support data communication based on whether a packet is one of one or more packets associated with a data unit of a data stream; and A response message indicating the establishment of the PDU session is received by the wireless device.

52. The method according to claim 51, wherein the wireless device sends the request message to a session management function (SMF).

53. The method according to any one of claims 51 to 52, further comprising: The wireless device determines that a first packet is one of the one or more packets associated with the data unit for the first packet; and The wireless device sends a first message, the first message including: The first packet; and Information that the first packet is one of the one or more packets associated with the data unit.

54. A method, which comprises: The wireless device determines that a first packet is one of the one or more packets associated with a first data unit of a data stream for the first packet; and The wireless device sends a first message, the first message including: The first packet; and Information that the first packet is one of the one or more packets associated with the data unit.

55. The method according to claim 54, further comprising: The wireless device sends a request message for establishing a protocol data unit (PDU) session, where the request message includes an indication of the ability of the wireless device to support data communication based on whether the packet is one of the one or more packets associated with the data unit of the data stream; and The wireless device receives a response message indicating the establishment of the PDU session.

56. A wireless device, comprising one or more processors and a memory storing instructions, the instructions when executed by the one or more processors cause the wireless device to perform the method according to any one of claims 51 to 55.

57. A non-transitory computer-readable medium including instructions, the instructions when executed by one or more processors cause the one or more processors to perform the method according to one of claims 51 to 55.

Images