Methods, architectures, apparatuses and systems for secure communication of packet data unit set information

Abstract

Procedures, methods, architectures, apparatuses, systems, devices, and computer program products for securely communicating packet data unit (PDU) set information are described. An application server (AS) may send secure PDU set metadata, encrypted and integrity protected, within an application PDU, where the metadata portion of the PDU is encrypted independently from the application portion of the PDU. This enables secure metadata to be sent together with any application protocol, including end-to-end encrypted protocols. The user plane function (UPF) UPF detects, decrypts and uses the secure metadata. To enable this, a secure context is established between the UPF and AS. Different methods are described, including sending control messages piggybacking the application flow, or enhancing existing mechanisms for shared keys distribution. The proposed solutions can also be used for other types of metadata, and between different nodes, e.g., from UPF to a wireless transmit-receive unit (WTRU).

Description

METHODS, ARCHITECTURES, APPARATUSES AND SYSTEMS FOR SECURE COMMUNICATION OF PACKET DATA UNIT SET INFORMATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 553,734 filed 15 -February-2024 which is incorporated herein by reference.BACKGROUND

[0002] The present disclosure is generally directed to the fields of communications, software and encoding, including, for example, to methods, architectures, apparatuses, systems related to communication of packet data unit set information.SUMMARY

[0003] There are disclosed embodiments of methods, as described in the following and as claimed in the appended claims.

[0004] There are disclosed embodiments of a device, as described in the following and as claimed in the appended claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures (FIGs.) and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("ref.") in the FIGs. indicate like elements, and wherein:

[0006] FIG. 1 A is a system diagram illustrating an example communications system;

[0007] FIG. IB is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A;

[0008] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A;

[0009] FIG. ID is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A;

[0010] FIG. 2 depicts embodiments for PS identification of downlink encrypted traffic;

[0011] FIG. 3 depicts major phases and IES for deploying and using Secure Metadata;

[0012] FIG. 4 depicts PDC Operation on the Data Plane;

[0013] FIG. 5 is a sequence chart of SMD Context Establishment and Operation according to an embodiment (AS to UPF metadata, with WTRU-relayed SMD context establishment);

[0014] FIG. 6 is a sequence chart of SMD Context Establishment and Operation according to an embodiment (metadata from AS to UPF, with direct UPF-AS SMD context establishment);

[0015] FIG. 7 is a sequence chart of SMD Context Establishment and Operation according to an embodiment (metadata from AS to UPF, with shared key based SMD Context);

[0016] FIG. 8 is a sequence chart of SMD Context Establishment and Operation according to an embodiment (UPF to WTRU metadata);

[0017] FIG. 9 is a flow chart of an exemplary embodiment of an embodiment of a method implemented by an UPF;

[0018] FIG. 10 is a flow chart of an exemplary embodiment of a method implemented by a WTRU; and

[0019] FIG. 11 is a flow chart of an exemplary embodiment of a method implemented by an UPF in a core network.DETAILED DESCRIPTION

[0020] Abbreviations and Acronyms5GS 5G System AF Application Function AKMA Authentication and Key Management for Application A-KID AKMA Key Identifier API Application Programing Interface AS Application Server CA Certificate Authority CPU Central Processing Unit DASH Dynamic Adaptive Streaming over HTTP DASH-LL DASH Low Latency DN Data Network DNN Data Network Name FQDN Fully Qualified Domain Name GTP-U Generic Tunneling Protocol User Plane HTTP Hypertext Transfer Protocol ID Identifier IE Information ElementIP Internet Protocol (IPv4: IP version 4, IPv6: IP version 6)MASQUE Multiplexed Application Substrate over QUIC Encryption MEC Mobile Edge ComputingMOQ Media over QUICMTU Maximum Transmission UnitN4 Interface defined by 3 GPP between SMF and UPFNACK Negative AcknowledgementNAS Non-Access StratumPDU Protocol Data UnitPS PDU SetPSK Pre- Shared KeyPSA UPF PDU Session Anchor UPFPSDB PDU Set Delay BudgetPSER PDU Set Error RatePSII PDU Set Integrated IndicationQoE Quality of ExperienceQoS Quality of ServiceQUIC The QUIC protocol (not an acronym)RAN Radio Access NetworkROQ RTP over QUICRTP Real-Time ProtocolSDF Service Data FlowSEAL Service Enabler Architecture LayerSMD Secure Metadata (defined herein)SMF Session Management FunctionS-NSSAI Single Network Slice Selection Assistance InformationSRTP Secure RTPUDP User Datagram ProtocolUE User EquipmentUPF User Pl ane Functi onURSP UE Route Selection PolicyXR Extended Reality

[0021] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed or otherwise provided explicitly, implicitly and / or inherently (collectively "provided") herein. Although various embodiments are described and / or claimed herein in which an apparatus, system, device, etc. and / or any element thereof carries out an operation, process, algorithm, function, etc. and / or any portion thereof, it is to be understood that any embodiments described and / or claimed hereinassume that any apparatus, system, device, etc. and / or any element thereof is configured to carry out any operation, process, algorithm, function, etc. and / or any portion thereof.

[0022] In embodiments described herein, ‘a’ and ‘an’ and similar phrases are to be interpreted as ‘one or more’ and ‘at least one’. Similarly, any term which ends with the suffix ‘(s)’ is to be interpreted as ‘one or more’ and ‘at least one’. The term ‘may’ is to be interpreted as ‘may, for example’.

[0023] A symbol 7’ (e.g., forward slash) may be used herein to represent ‘and / or’, where for example, ‘A / B’ may imply ‘A and / or B’.

[0024] Example Communications System

[0025] The methods, apparatuses and systems provided herein are well-suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to FIGs. 1A-1D, where various elements of the network may utilize, perform, be arranged in accordance with and / or be adapted and / or configured for the methods, apparatuses and systems provided herein.

[0026] FIG. 1A is a system diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discreet Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block- filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0027] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or a "STA", may be configured to transmit and / or receive wirelesssignals and may include (or be) a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi- Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0028] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d, e.g., to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the networks 112. By way of example, the base stations 114a, 114b may be any of a base transceiver station (BTS), a Node-B (NB), an eNode-B (eNB), a Home Node-B (HNB), a Home eNode-B (HeNB), a gNode-B (gNB), a NR Node-B (NR NB), a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0029] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0030] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0031] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0032] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE- Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access, which may establish the air interface 116 using New Radio (NR).

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0035] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0036] The base station 114b in FIG. 1 A may be a wireless router, Home Node-B, Home eNode- B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of a small cell, picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0037] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing any of a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0038] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / oroperated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 114 or a different RAT.

[0039] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0040] FIG. IB is a system diagram illustrating an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other elements / peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together, e.g., in an electronic package or chip.

[0042] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In an embodiment, the transmit / receive element 122 may be configured to transmit and / or receive bothRF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0043] Although the transmit / receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0044] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0045] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), readonly memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0046] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0047] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., basestations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0048] The processor 118 may further be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality and / or wired or wireless connectivity. For example, the elements / peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (e.g., for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The elements / peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0049] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the uplink (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the uplink (e.g., for transmission) or the downlink (e.g., for reception)).

[0050] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0051] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers forcommunicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0052] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and / or downlink (DL), and the like. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0053] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0055] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode-B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0056] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0057] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interfacebetween the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0058] Although the WTRU is described in FIGs. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0059] In representative embodiments, the other network 112 may be a WLAN.

[0060] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802. l ie DLS or an 802.1 Iz tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad-hoc" mode of communication.

[0061] When using the 802.1 lac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier sense multiple access with collision avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0062] High throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadj acent 20 MHz channel to form a 40 MHz wide channel.

[0063] Very high throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse fast fourier transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operation for the 80+80 configuration may be reversed, and the combined data may be sent to a medium access control (MAC) layer, entity, etc.

[0064] Sub 1 GHz modes of operation are supported by 802.1 laf and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.1 laf and 802.1 lah relative to those used in802.1 In, and 802.1 lac. 802.1 laf supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.1 lah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment,802.1 lah may support meter type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems, which may support multiple channels, and channel bandwidths, such as802.1 In, 802.1 lac, 802.1 laf, and 802.1 lah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.1 lah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV)settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0066] In the United States, the available frequency bands, which may be used by 802.1 lah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 lah is 6 MHz to 26 MHz depending on the country code.

[0067] FIG. ID is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0068] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the WTRUs 102a, 102b, 102c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0069] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., including a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0070] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non- standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non- standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0071] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and the like. As shown in FIG. ID, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0072] The CN 115 shown in FIG. ID may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0073] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b, e.g., to customize CN support for WTRUs 102a, 102b, 102c based on thetypes of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0074] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP -based, non-IP based, Ethernet-based, and the like.

[0075] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, e.g., to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0076] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0077] In view of FIGs. 1 A-1D, and the corresponding description of FIGs. 1 A-1D, one or more, or all, of the functions described herein with regard to any of: WTRUs 102a-d, base stations 114a- b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a- b, SMFs 183a-b, DNs 185a-b, and / or any other element(s) / device(s) described herein, may beperformed by one or more emulation elements / devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0078] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

[0079] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0080] Introduction

[0081] The terms Application Server (AS) and Application Function (AF) may be used interchangeably herein. An AS may in some cases be an Edge Application Server.

[0082] The term Information Element (IE) is used herein to represent one or more parameters. An IE may be made up of one or more other IES.

[0083] Public key certificates (e.g., X.509 certificates) may be referred to as “certificates” herein.

[0084] The terms “PDU set IEs”, “PDU set metadata” and “metadata” are used interchangeably herein. “PDU Set IEs” are defined in section “XR Traffic Handling by Wireless Networks and PDU Sets” in this document.

[0085] The terms “packet” and “IP packet” may be used interchangeably herein. They may designate a PDU for a protocol such as an Internet layer protocol such as IPv4 or IPv6, a transportprotocol such as UDP, a layer-2 protocol such as Ethernet or 802.11, or an information centric networking protocol such as the Named Data Networking protocol.

[0086] The term “UPF” used herein generally designates a PSA UPF, unless specified otherwise.

[0087] The terms “encryption / encrypt / encrypted” used herein designates more generally a transmission that provides confidentiality, integrity protection, and / or authentication.UPF and AS establish a security context with each other and UPF uses the security context to identify encrypted PDU set information sent by the AS (UPF, WTRU, SMF)Details of embodiment can be found in sections based on procedures and based on detailed descriptions. Regarding the procedures, certificate-based embodiments (see “Case 1” below) are described in sections “WTRU-Relayed Method”, “Piggyback Method”, “Point-to-point Connection Method”, while shared key-based embodiment (see “Case 2” below) is described in section “Shared Key -based Method”;Regarding the detailed descriptions, these can be found in sections “Phase 2: Initiation of Secure Metadata Usage”, “Phase 3: Secure Metadata Context Establishment” and “Phase 4: Secure Metadata Transmission and Usage”.

[0088] Steps on the UPF1. The UPF receives, from the SMF, an indication to use encrypted metadata between AS and UPF.

[0089] Case 1 (certificate-based embodiments)NOTE: in some embodiments the indication from 1 may include a shared key that can be used for the handshake (2a-2e)2a. The UPF generates an encrypted metadata handshake request message (e.g., including a DTLS client hello) and sends the message (e.g., to WTRU, AS, or SMF);2b. The UPF receives an encrypted metadata handshake response message (e.g., including a DTLS server hello);2c. The UPF stores an SMD context including a session key generated using the metadata handshake response message.NOTE: additional steps may be included, such as:2d. The UPF sends an encrypted metadata handshake finished message (e.g., including a DTLS finished message encrypted with the session key);2e. The UPF may receive an additional message (e.g., including a server certificate) and may use it to authenticate the AS using the provisioned certificates.

[0090] Case 2 (shared key-based embodiment)2. The UPF receives a message containing an encrypted metadata session key and stores an SMD context including the session key.

[0091] In all cases (1 or 2), the procedure continues:3. The UPF obtains mapping information that is associated with the SMD context (e.g., a traffic filter and / or an SMD context ID). For example, the UPF maintains a mapping table associating an application flow between an AS and the WTRU (e.g., using traffic filters, and / or through a mapping with a QoS flow IDs and / or PDU session ID), with an SMD context.4. The UPF receives a PDU from the AS;5. The UPF detects the presence of encrypted metadata in the PDU (e.g., through parsing of a UDP option header);6. The UPF identifies the SMD context associated with the encrypted metadata (e.g., based on the mapping information and / or based on the source / destination IP address and port of the PDU and / or based on SMD context ID in the PDU);7. The UPF decrypts the encrypted metadata using the session key associated / included with the SMD context;8. The UPF obtains the PDU set information from the decrypted metadata and forwards to the RAN, the PDU and PDU set information (e.g., in the header of the GTP packet holding the PDU).

[0092] Steps on the SMF (shared key -based embodiment section “Shared Key -based Method”)1. The SMF receives a message (e.g., from PCF) including SMD request IES;2. The SMF requests a shared key from a network function, e.g., AAnF. The SMF receives the shared key in a response message;3. The SMF sends, to the UPF, an N4 session request including SMD request IE including the shared key;4. The SMF receives an N4 session response;5. The SMF sends a notification including an SMD configuration complete indication, and an SMD context ID (e g., an A-KID);

[0093] Steps on the WTRU (WTRU-relayed embodiment section “WTRU-Relayed Method”)1. The WTRU sends a PDU session establishment or update request message, indicating a capability to relay SMD control messages;2. The WTRU receives an SMD control messages (e.g., from SMF over control plane or from UPF over user plane);3. The WTRU inserts the SMD control message in a user plane PDU (e.g., in a UDP option);4. The WTRU receives application PDUs over the PDU session, with SMD service applied by the network (e.g., with PDU set differentiated QoS service applied by the network, enabling higher QoE for XR applications);UPF and WTRU establish a security context with each other, and WTRU uses the security context to decrypt metadata sent by the UPF (UPF, WTRU, SMF)

[0094] Details of embodiments can be found in sections in this document:Based on procedures: certificate-based embodiments in “SMD for Encrypted Traffic between WTRU and UPF”.Based on detailed descriptions: sections “Phase 2: Initiation of Secure Metadata Usage”, “Phase 3: Secure Metadata Context Establishment” and “Phase 4: Secure Metadata Transmission and Usage”.

[0095] Steps on the WTRU1. the WTRU sends a PDU session establishment or update request message, which may include an SMD capability (e.g., a capability to receive and use SMD);2. the WTRU receives a PDU session establishment or update response message, which includes an indication to use the SMD service, and may include the IP address and port of an SMD endpoint on the UPF;3. the WTRU may establish an SMD control connection on the user plane;4. the WTRU initiates the creation of an SMD context (e.g., derives a shared key Ksmd) and sends an SMD control message (on the user plane established in step 3, or on the control plane, e.g., NAS);5. the WTRU receives an SMD control message from UPF. The WTRU completes the creation of the SMD context (e.g., including a DTLS security context based on the SMD control messages);6. the WTRU receives an application flow PDU on the PDU session, detects the presence of an SMD, decrypts the SMD and provides the decrypted metadata to the WTRU application.

[0096] Steps on the SMF1. the SMF receives a PDU session establishment / update message, which may include an SMD capability;2. the SMF retrieves a subscription policy and determines to use the SMD service;3. the SMF retrieves a shared key Ksmd from an NF (e.g., AUSF / AAnF);4. the SMF provides the shared key Ksmd to the UPF, e.g., in an N4 session update message;5. the SMF receives a response from UPF, including an IP address and port of the SMD endpoint;6. the SMF sends to the UE, a PDU session establishment / update response, including an IP address and port of the SMD endpoint;

[0097] Steps on the UPF1. the UPF receive an N4 session message including SMD service IES, e.g., including a shared key Ksmd;2. the UPF configure an SMD endpoint on the UPF;3. the UPF sends a response that may include the SMD endpoint IP address and port (if SMD control is over user plane);4. the UPF receives an SMD control message (e.g., initial SMD control message from WTRU, over control or data plane);5. the UPF creates an SMD context and sends an SMD control message (e.g., to WTRU);6. the UPF receives a metadata IE (e.g., from SMF or from a software component on the UPF) and uses the SMD context to encrypt the metadata IE;7. the UPF inserts the encrypted metadata IE in a DL PDU it forwards to the WTRU.XR Traffic Handling by Wireless Networks and PDU Sets

[0098] It is challenging for wireless networks to carry media flows, especially for applications with high-throughput and low latency requirements, such as video conferencing and Extended Reality (XR). Wireless networks can implement techniques to improve network capacity and energy efficiency, as well as reduce the impact of packet losses on user experience. For example, wireless networks such as 5G can handle groups of packets based on how critical they are to the user experience. Some groups of data packets hold application data units that are handled together (e.g., decoded) by the application, and that are referred to as "PDU set" . A PDU set can for example correspond to the PDUs carrying a single complete Network Application Layer (NAL) unit.

[0099] To support high-throughput low-latency media flows, the network (e.g., RAN) can perform differentiated / integrated QoS handling of XR traffic. This can include prioritizing PDU sets over others in case of congestion. The network can use the fact that application data units can depend on other application data units to be handled or decoded by the application (e.g., P-frames depend on I-frames, and enhancement layers depend on base layers). The network can also selectively drop data packets that depend on an already lost application data unit. The network can limit wake-up time (of radios) to transmit and receive data. For example, the packet scheduler (e.g., in RAN nodes) and / or WTRUs can synchronize their transmission and listening times usinginformation on the size and periodicity of traffic, as well as delay budget and expected jitter specific to the application.

[0100] The RAN can perform differentiated / integrated QoS handling of XR traffic based on differentiated / integrated handling IES associated with a flow and / or PDU sets inside this flow. Differentiated / integrated Handling IEs include PDU Set QoS Parameters that are received via the control plane and PDU Set Information that was received via user plane. For downlink traffic, PDU set information can be sent by the UPF to the RAN node via a GTP-U header of a user plane packet. For uplink traffic, PDU set information can be provided by a WTRU application through the SDAP interface.

[0101] The term PDU set IE can be used to represent IEs described herein as PDU set information and PDU set QoS parameters.

[0102] PDU set information may include some of the following:

[0103] PDU Set ID. This IE is an identifier of a PDU set, which uniquely identifies the PDU set within the flow, at least for duration corresponding to the transmission time of PDUs between sender and receiver. This IE may be, e.g., a numerical ID, a timestamp, etc.

[0104] Start / End of a PDU Set indication. These IEs identifies the first / last PDU(s) of a PDU set.

[0105] PDU Sequence Number within a PDU Set. This IE identifies a PDU within a PDU set, e.g., a numerical ID starting at 0 for the first PDU and incremented by 1 for each PDU in the set.

[0106] PDU Set size. This IE may hold the total number of PDUs, or the cumulative length of all the PDUs in the set, or the cumulative length of all PDU payload (e.g., transport payload) in the PDU set.

[0107] PDU Set Importance. This IE may be a numerical value indicative of the importance level of a PDU set within a service flow (e.g., from highest priority value 0 to lowest priority value 255). RAN may use it for PDU Set level packet discarding in presence of congestion.

[0108] End-of-burst indication. This IE may indicate that a PDU or a PDU set is the last PDU or PDU set of a burst. This IE may also include IEs indicating the amount of time before the next burst.

[0109] PDU set information may additionally include some of the following.

[0110] XR application session ID, which identifies the session, e.g., to provide a scope for prioritizing, scheduling, and synchronizing flows, packets and PDU sets.[OHl] XR application session priority, which provides a priority for inter-session prioritization, e.g., to prioritize between flows belonging to different application sessions, which have a same flow priority.

[0112] XR flow ID, which identifies the flow, e.g., for applying XR service on the flow. This ID may be provided by the mobile network, e.g., it may be a PDU Session ID.

[0113] XR flow priority, which provide a priority for inter-flow prioritization.

[0114] Data type, e.g., audio, video, haptic, data. This may be used for inter-flow synchronization, e.g., to determine the acceptable synchronization delay between flows.

[0115] XR synchronization group ID, which indicates which flows of the application session should be synchronized with each other.

[0116] List of applicable network services, which indicates which network services, e.g., including PDU QoS Set Handling, but may also include additional services, such as increased reliability (e.g., using multipath connectivity such as provided by ATSSS), low-latency delivery, etc. This can be used by the 5G network to determine which level of service should be provided to a given PDU set.

[0117] PDU set type, which enable associating a domain-specific meaning with a PDU set, e.g., I-frame, P-frame, B-frame. PDU set type may be useful to provide XR services where specialized processing is required for selected types of PDU sets.

[0118] PDU FEC parameters, including FEC algorithm and its parameters. They can be used, e.g., by WTRU / UPF / AS to recover lost packets in a PDU set protected by FEC.

[0119] PDU parent set ID, which identifies a parent PDU set that is required to be received by the application, for the (child) PDU set to be usable by the application.

[0120] Timing IES such as media unit timestamp, presentation timestamp, sending time timestamp, accumulated transmission delay, PDU synchronization ID. PDU synchronization ID may identify a group of inter-related PDUs that must be presented to the user at a similar time, within the same flow (e.g., a set of frames that must be presented to the user at the same time in a multi-screen setup), or between different flows (e.g., a video PDU that must be presented to the user together with haptic PDU).

[0121] PDU set QoS parameters is a set of parameters to configure the QoS handling of a flow. PDU set QoS parameters include:

[0122] PDU Set Error Rate. This IE value corresponds to error rates applicable to PDU sets (e.g., where a PDU set loss corresponds to an event where at least a PDU of the set could not be transmitted successfully). This IE can be used to configure the acceptable error rate for PDU sets of a service flow or QoS flow in the RAN.

[0123] PDU Set Delay Budget. This IE value corresponds to the acceptable delay for transmitting a full PDU set (e.g., from the reception of the first PDU of the set, to the transmission of the lastPDU of the set). This IE can be used to configure the delay budget for a service flow or QoS flow in the RAN.

[0124] PDU Set Integrated Indication (PSII). This IE indicates whether all PDUs of the set are needed by the application.

[0125] Burst periodicity. This IE value designates the period of a data burst for this flow (e.g., transmission period for consecutive independent frames in a video stream. E.g., transmission period for a group of pictures).

[0126] Common related definitions include:

[0127] PDU set Identification is the determination of which PDU Set a PDU belongs to, along with the identification of PS IES that are associated with this PDU set. For non-encrypted media flows (e.g., using the RTP protocol), this operation is typically performed by the UPF for downlink flows. For encrypted media flows, this operation can be performed both by the media sender (e.g., origin media server or a proxy with access to transport metadata), and by the UPF (e.g., based on metadata placed in the PDU by the media sender, which is visible by the UPF).

[0128] PDU set QoS Handling designates the operation (in RAN and possibly in UPF) that consists in providing differentiated handling depending on PS IEs. E.g., dropping PDUs of lower PS importance in case of congestion.Encrypted Media Transport

[0129] Encrypted media protocols transport can prevent certain intermediaries (e.g., intermediaries not explicitly trusted by an endpoint and inserted in the connection) to perform PDU set identification. Encrypted media protocols include HTTP -based stream protocols (e.g., when using TLS fortransport), SRTP when used with encrypted RTP extensions (e.g., such as described in RFC9335), media over QUIC protocols (MOQ) and RTP over QUIC (ROQ).DTLS

[0130] The Datagram Transport Layer Security (DTLS) protocol version 1.3 enables a client and a server application to communicate securely, e.g., preventing eavesdropping, tampering with messages, or forging messages. While it is based on the Transport Layer Security (TLS) protocol and provides similar security guarantees, DTLS can be transported over unreliable datagrams. For this reason, DTLS provides additional security guarantees, for order protection and nonreplayability.

[0131] DTLS may be transported over a range of transport protocols. Some example of transport protocols envisioned for DTLS are unreliable transport protocols such as UDP and DCCP, as well as reliable transport protocols such as TCP and SCTP.AKMA

[0132] The Authentication and Key Management for Applications (AKMA) security feature provides mechanisms to support authentication and key management aspects for applications based on subscription credential(s) in a 5G system (AKMA).

[0133] An AKMA key (KAKMA) is derived by the network (AUSF) and the WTRU from an access key (KAUSF) following a primary authentication procedure. An AF key (KAF) is derived from KAKMA by the WTRU and the network (AKMA Anchor Function (AAnF)) and provided by the network to the AF, to be used for secure application layer communication between the WTRU and the AF. A single KAKMA is established per WTRU and a single KAF is established per Application, per WTRU.

[0134] PDU set (PS) identification cannot be performed by the UPF on downlink media traffic such as MOQ or ROQ traffic, where media headers are encrypted end-to-end between the media receiver and a media source. For the sake of simplicity, we will use herein the use case where a WTRU is the media receiver, and where the media source is an AS such as an origin server, a CDN media proxy or media middlebox. However, the media source may also be another WTRU.

[0135] At least two embodiments may be recognized. These embodiments may be used alone or in combination to perform PS identification of downlink encrypted traffic, see FIG. 2 that depicts embodiments for PS identification of downlink encrypted traffic:According to a first embodiment, the PSA UPF acts as a proxy (e.g., a MOQ relay) for the encrypted application connection. The proxy can be used to have access to transport signaling, which can be used to perform PDU set identification; andAccording to a second embodiment, the AS performs PDU set identification, and transmits PDU set information to the PSA UPF along with encrypted PDUs, using header fields accessible by the UPF, e.g., either without encryption (i.e., in cleartext), or with encryption that is decryptable by the UPF.

[0136] The first embodiment may not always be suitable, because it requires the 5G network (UPF) to be a media intermediary node trusted by the application client and server, while, in the second embodiment, the trust relationship can be restricted to the exposure of only specificmetadata between the AS and the UPF. This disclosure describes, amongst others, solutions according to the second embodiment. This can include multiple use cases such as: the case where the AS is an edge CDN node (e.g., MOQ relay operated by Akamai in the 5G operator’s edge network); the case where the AS is a media server at the edge; and the case where the AS is a media server or CDN node in the distant cloud.

[0137] A solution for the second embodiment may enable PDU set information to be provided by the AS to the network (e.g., UPF), along with a media flow transported over any type of (encrypted or non-encrypted) media protocols such as MOQ, ROQ, SRTP, RTP, DASH, DASH- LL, etc., while addressing requirements, as for example: a) preserve the privacy of users. Exposing PDU set information in cleartext to the network enables an attacker with access to the link on the data path to identify characteristics of the media flow. A well-known embodiment consists in establishing an encrypted tunnel between the UPF and AS, over which PDUs including media data and PDU set information are sent from AS to UPF; b) make an efficient use of network resources. For example, using an encrypted tunnel between AS and UPF can be wasteful of UPF CPU resources. Because the whole PDU is encrypted, including media data and PDU set information, such a tunnel requires a non-negligible processing overhead at the AS and UPF, to encrypt / decrypt media data, which is typically already encrypted end-to-end.A new mechanism is desired, to enable metadata such as PDU set information to be transmitted securely and efficiently using limited network resources.

[0138] Efficient Secure Metadata Exchange - Overview

[0139] Secure Metadata (SMD) designates metadata associated with one or more PDUs, which is transmitted in the same (e.g., IP) packet as one or more of the associated PDUs, and encrypted using a security context established between a sender node, which encrypts the secure metadata, and a network node, which decrypts and uses the secure metadata. Typically, SMD is encrypted / decrypted independently from the rest of the PDU. PDU Set IES are an example of SMD that may be transmitted using the methods and procedures described herein. PDU Set IEs are useful to enable enhanced support for XR traffic in mobile networks. However, other types of metadata may be transmitted using these methods and procedures. For example, the network (UPF) may use methods and procedures described herein to transmit recommended maximum bandwidth usage to WTRUs, to help guide ABR algorithms on the WTRU and limit the need for bandwidth throttlingby the network. More generally, the methods and procedures described herein may be used to transmit metadata that may apply to one specific PDU or group of PDUs, when this metadata needs to be accessed by a network function that is on the path of the PDUs.

[0140] Methods and procedures for efficient SMD exchange are described herein. A UPF establishes a security context with an application sender (e.g., a media sender, AS or WTRU). In an illustrative example of security context establishment, the UPF and AS exchange information to create a secure session key. Once a security context is established, the AS generates metadata (e.g., PDU set information), encrypts it using the security context, and transmits the encrypted metadata in the same IP packet as an application PDU. In an illustrative example, the encrypted metadata is placed in a header or trailer portion of the IP packet, such as an IP option or UDP option, respectively. When it receives the IP packet including the application PDU and encrypted metadata, the UPF, using the security context, decrypts the metadata portion of the IP packet and uses it to provide a network service. In an illustrative example of metadata usage, the UPF may transmit the decrypted PDU set information to the RAN, where the RAN uses it to provide differentiated QoS service.

[0141] The major phases of this process, as well as new IES defined herein, are as illustrated in FIG. 3 and detailed below.

[0142] In the service provisioning phase of FIG. 3, (section “Phase 1 : Provisioning of Information Related to Secure Metadata” in this document) the network operator and / or application provider provisions Secure Metadata provisioning IEs, e.g., in the SMF, PCF and / or NEF, to enable secure operation (e.g., enable authorizing WTRU subscribers and authentifying application domains).

[0143] In the initiation phase of FIG. 3, (section “Phase 2: Initiation of Secure Metadata Usage” in this document) the WTRU requests network service for a media session and may include in the request an SMD indication to use secure metadata, e.g., to enable XR support for encrypted media flows. Even in cases where the WTRU does not explicitly add an SMD indication, the network (e.g., SMF based on PCC rules from PCF) determines that SMD service is required for a service data flow.

[0144] In the SMD context establishment phase of FIG. 3, (section “Phase 3: Secure Metadata Context Establishment” in this document) a core network function (e.g., UPF / SMF / NEF / PCF) establishes a security context with the AS to process SMD. This security context may include a session key (e.g., a DTLS session key or symmetric encryption key), and other information such as an identifier for the security context, application session and / or session key. In some systems,this security context may be reused, e.g., for a different application session where the AS and UPF are the same as for the first application session. The security context establishment requires messages to be sent between the core network function and AS, which may be (a) transmitted through the WTRU as an intermediary, or which may be (b) piggy-backed on WTRU-AS application messages, or which may be (c) exchanged over a control plane connection, or which may be (d) exchanged via a network function such as AAnF. For certificate-based embodiments (a-b-c), the context is established using an underlying protocol (e.g., DTLS), which is secure even when transmitted over an unsecure medium. For the shared key-based embodiment (d), the shared key is transmitted over secure connections such as HTTP / 2 over TLS or HTTP / 3.

[0145] In the SMD transmission and processing phase of FIG. 3, (section “ Phase 4: Secure Metadata Transmission and Usage” in the present document) the AS transmits, along with the PDUs, the secure metadata IES (e.g., PDU set IES) encrypted / integrity protected using the security context shared with the core network in phase 3. The UPF decrypts the secure metadata and uses it, e.g., to identify PDU set IEs and transmit them to the RAN in the header of the GTP-U packet that encapsulates the PDU.

[0146] In the maintenance phase of FIG. 3, (section “Phase 5: Secure Metadata Context Maintenance” in this document) the UPF / SMF and AS may exchange messages to maintain (e.g., re-generate news session keys) or re-establish the security context, in a manner similar to phase 3.

[0147] In the end / revocation phase of FIG. 3, (section “Phase 6: Closing a Connection with Secure Metadata” in this document) the SMD context can be terminated / deleted following events such as the end of the application session, or when the authorization for using an SMD service is revoked (e.g., by operator or AS).

[0148] The types of IEs defined herein are:SMD provisioning IEs, defined in section “Phase 1 : Provisioning of Information Related to Secure Metadata” in this document;SMD request IEs, defined in section “Phase 2: Initiation of Secure Metadata Usage” in this document;SMD context IEs, defined in section “Phase 3: Secure Metadata Context Establishment” in this document; andSMD, or SMD data message, defined further on in this document

[0149] FIG. 4 illustrates the desired operational state of an application session with SMD support. In this example, a security context is established between UPF and AS in step A, corresponding to phase 3 hereinabove. Steps B-E correspond to phase 4 herein above. In step B, acomponent of the AS packetizes a media data unit; identifies corresponding metadata (PDU set IES); encrypts / integrity protect the PDU set IES; and sends, towards the WTRU through the UPF, a PDU including the media data unit and the encrypted PDU set IEs, e.g., in a UDP option (step C). The UPF receives the PDU; detects the presence of encrypted metadata (e.g., based on the detection of a UDP option header with a specific UDP option kind / type); decrypts the PDU set IEs; and forwards them towards the RAN over the PDU session GTP tunnel (step D). The RAN uses the PDU set IEs to apply PDU set QoS handling and forwards the PDUs towards the WTRU (step E).

[0150] An underlying SMD protocol enables setting up the security context and encrypting / decrypting secure metadata. For certificate based SMD context establishment, DTLS will be used as a primary example of underlying SMD protocol herein. However, other alternative protocols, offering some security guarantees similar to what DTLS is offering, may be used instead. QUIC, or a protocol based on QUIC, may be such an alternative protocol. For shared key based SMD context establishment, an underlying protocol such as HTTP / 2 over TLS or HTTP / 3 can be used to transport the shared key securely.

[0151] An SMD context is a shared security context (e.g., including a shared key, a DTLS, QUIC, or other underlying SMD protocol security context) that is established between a sender node and a network node for the purpose of securely transmitting SMD.

[0152] An SMD service designates the network service described herein, where an SMD context is established between a sender node and a network node; where the sender node securely transmits SMD to a network node on the application traffic path; and where the SMD is encrypted / decrypted independently from the rest of the PDU.

[0153] SMD data messages designate the messages including secure metadata (e.g., encrypted PDU set information). SMD data messages are carried in an application PDU, e.g., in a trailer or header of the packet carrying an application payload. An SMD data message may for example include a UDP option type “SMD data”, a UDP option length, an SMD context ID, and the encrypted metadata. The SMD data message, or the encrypted metadata portion of the SMD data message may be herein referred to as secure metadata, or SMD (e.g., SMD used as a noun).Phase 1: Provisioning of Information Related to Secure Metadata

[0154] In a first phase, information related to the SMD service is provisioned in the mobile network.

[0155] SMD service provisioning IES are provided to the mobile network in a provisioning phase. SMD provisioning IEs include some of the following IEs (e.g., a-b): a) SMD security material, and b) an SMD service indication.

[0156] a) The SMD security material may include a CA certificate and / or a shared key, wherein the CA certificate corresponds to the CA that is used to generate the AS certificates. This CA can be used as a trusted root authority to authenticate the AS certificates that are provided by the AS during the SMD context establishment phase. The shared key, is e.g., derived from a key provisioned in the AAnF to enable AKMA based procedures.

[0157] b) an SMD service indication may include the following IEs (e.g., bl-b7):

[0158] b 1) an indication that SMD service is allowed / authorized (e.g., for a WTRU subscription);

[0159] b2) a list of application domains and / or other application attributes that are allowed and / or disallowed for use with the SMD service. The application domains and / or attributes may correspond to IEs present in AS server certificates, and the core network (e.g., UPF, SMF) can verify that these domains / attributes match, prior to authorizing the SMD context establishment to proceed. Examples of application attributes include a service name or a service type or an application group ID;

[0160] b3) SMD service types indicate methods and protocols for SMD context establishment and for SMD transmission. When used within a SMD service indication, this IE can indicate service types that are allowed and / or disallowed. Examples of values for SMD context establishment include certificate-based, certificate-based with WTRU relayed SMD context establishment, certificate-based with piggybacked SMD context establishment, certificate-based with direct SMD context establishment, shared-key based. Example of values for SMD transmission include using a UDP option, using an IP option, using a GTP header;

[0161] b4) a list of DNNs and / or slices (e.g., S-NSSAIs) that are allowed and / or disallowed for use with the SMD service;

[0162] b5) an SMD underlying protocol type (e.g., DTLS or QUIC), which indicates which underlying protocol types are supported and / or preferred for a given application or group of application;

[0163] b6) a SMD context scope configuration, which include default or maximum values for the SMD context scope IEs defined hereinafter. E.g., this may include a maximum number ofapplication sessions (e.g., a value 1 would indicate that a separate SMD context will be required for each new application session);

[0164] b7) a user consent indication for SMD, which indicates user consent for using the SMD service (in general or for specific applications). User consent may be requested at any time from the user (e.g., entered in settings) and stored in the network (e.g., in UDM, in the subscription profile). The SMF may check for user consent indication for SMD, in phase 2 when SMD is initiated.

[0165] SMD provisioning may be performed by the mobile network operator, based on business agreements with an application provider and / or with a WTRU subscriber. The mobile network operator may store an SMD service indication in the CN, e.g., in the UDM, e.g., in a WTRU subscription and / or in a service subscription. The mobile network operator may configure SMD security material in SMF, UPF, UDM, AAnF, or other CN functions. The mobile network may offer an interface (e.g., through PCF and / or NEF) enabling AF to configure a certificate into the mobile network. Through such an NEF / PCF interface, the AF may upload a certificate (e.g., a CA certificate that it uses to sign AS server certificates) and associate the certificate with an application ID, or a group of applications. In some systems, the certificates may be stored in the WTRU subscription, while in other systems, the certificates may be stored in SMF or UDM, and the WTRU subscription may include an ID reference to certificates domains or groups of domains. A role of the CA certificates is to enable the core network (e.g., SMF / UPF / NEF) to authenticate the AS when establishing the SMD context.

[0166] Alternatively, to enable certificate-based security the AS, 5GC and WTRU may use a (pre-)shared key / symmetric based security for the protection of secure metadata. The SMD service indication above may include the type of security supported (e.g., certificate-based, shared keybased). The shared key between the AF and operator for the metadata security may be established using AKMA based procedures. For a WTRU supporting AKMA, a KAKMA is derived for the WTRU in the 5GC (e.g., in AAnF, automatically) following a successful primary authentication. The AF supporting AKMA that wishes to use SMD, requests a KAF key for the purpose of protecting the metadata transmitted to the 5GC. A NF (e.g., SMF, NEF) that wishes to use SMD, requests a KAF key (e.g., from an AAnF) used for protecting the metadata transmitted to the 5GC.Phase 2: Initiation of Secure Metadata Usage

[0167] In a second phase, usage of SMD is initiated for an application session.

[0168] SMD request IES include some of the following IES (e.g., a-g):a) An SMD request indication to use the SMD service; b) SMD service type(s), which indicates requested / desired methods and protocols for SMD context establishment and for SMD transmission. Examples of values are given hereinbefore; c) An SMD capability, e.g., indicating that the WTRU supports relaying SMD control messages, and / or e.g., indicating that nodes such as WTRU, SMF, UPF, support the SMD service; d) An application ID (e.g., application domain) or application group ID, which can enable identifying an AS; e) One or more CA certificates (or IDs / references to such certificates) that may be used to authenticate the application sender, as part of the secure metadata context setup phase; f) An SMD context ID, to indicate a pre-existing SMD context ID that should be reused if possible. In some systems, e.g., when using a shared key, the SMD context ID may include an AKMA Key Identifier (A-KID); and g) AS endpoint IES, including information enabling connecting to an AS, e.g., including an IP address, transport protocol type (e.g. UDP), transport protocol port, FQDN.

[0169] The WTRU, AF or SMF initiates the SMD service (see e.g., a-e below). The WTRU may initiate the SMD service by sending a PDU session establishment or update message to the network. An AF may initiate the SMD service by requesting (e.g., through NEF and / or PCF) an AF session with required QoS (e.g., using the Nnef AFsessionWithQoS Create API). The SMF may initiate the SMD service based on a PCC rule. a) The AF may explicitly request using the SMD service, by transmitting an SMD request indication in an AF session with required QoS request, e.g., sent by AF to NEF or PCF. Upon reception of the request, the NEF / PCF may trigger the creation or modification of a PCC rule including the requested QoS and including an SMD request indication, and the PCF may send a notification to the SMF, including the PCC rule. The SMF may determine to use the secure metadata service based on the presence of secure metadata request indication in the rule. b) In systems using shared-key -based SMD service, the AF may provide an indication to the NEF requesting usage of SMD service using pre-shared key -based security for a particular session. c) The WTRU may explicitly request using the SMD service, by transmitting an SMD indication in the PDU session establishment or update message. The SMD request indication may for example be an extended protocol configuration option in the PDU session establishment / update message. d) The SMD service may alternatively be triggered by the SMF upon receiving a, e.g., PCC, rule, e.g., following the reception of a PDU session establishment / update message from the WTRU.The network operator may configure SMD request IES in the network, e.g., in a PCC rule in the PCF, based on a business agreement with an application provider and / or based on a request by an AF. In an example, the SMD service may be used in conjunction with other features such as a PDU set feature. In this case, if the AF includes an indication to enable PDU set feature on a flow, the 5GS may use that indication to determine that the SMD service needs to be started. e) In all cases, a message including SMD request IEs reaches the SMF (e.g., from PCF in an Npcf_SMPolicyControl_UpdateNotify message including SMD request IEs. E.g., from WTRU in PDU session establishment including SMD request IEs).

[0170] The SMF may use the following logic for SMD service determination for an application session, upon receiving a message including SMD request IEs (e.g., a-b):

[0171] a) The SMF collects the SMD request IEs in a PCC rule selected for the PDU session, the SMD request IEs in the PDU session establishment / update request if any, and the SMD service provisioning IEs, e.g., from the WTRU subscription profile and / or from a service subscription (for simplicity we will use WTRU subscription profile herein, however the SMD service provisioning IEs may be stored in and obtained from other types of subscriptions such as service subscription).

[0172] b) The SMF determines if an SMD service should be applied. For this, it compares the SMD IEs from the different sources. If the message (e.g., PCC rule) includes an SMD request indication, then the SMF should proceed with the SMD service determination. During SMD service determination, the SMF compares the SMD request IEs and SMD service provisioning IEs with each other, and the SMF may determine that an SMD service should be used if the SMD request IEs are allowed by the SMD service provisioning IEs for this user and / or service. The SMFmay also consider the capabilities of the network (e.g., UPF and RAN capabilities). See e.g. bl- b7 below. bl) E.g., is the SMD service allowed for this WTRU subscription? The SMD service may be allowed based on a service subscription by the user (e.g., it may be part of an XR support service). b2) E.g., are the PDU session DNN and / or slice (S-NSSAI) allowed for SMD service? b3) E.g., is the requested SMD service type allowed or disallowed in the WTRU subscription profile? Are the SMD services allowed in the WTRU subscription compatible with the SMD services requested by an AF? b4) E.g., is the SMD capability of the WTRU compatible with the requested SMD service type? In this case, if WTRU-relay is requested but not supported by the WTRU, the SMD service request should not be accepted. b5) E.g., is the requested application ID / domain / group present in the SMD request IES allowed or disallowed in the WTRU subscription profile? b6) If the RAN does not support PDU set QoS handling, the SMF may reject the SMD service request, since the PDU set IEs would be useless in this instance. If the RAN supports PDU set QoS handling, the SMF may proceed with the SMD service determination. b 7) If the UPF does not support the SMD service (in general) or if it does not support the requested SMD service type(s), the SMF may reject the SMD service request. Otherwise, the SMF may proceed with the SMD service determination.

[0173] Furthermore, the SMF may also determine if an SMD context should be reused for the session or if a new SMD context should be used. For example, the SMF may receive an SMD context ID from the AF (e.g., through NEF and / or PCF), which indicates that the AF already has one or more candidate SMD contexts that it wishes to reuse if possible. The SMF may retrieve the candidate SMD contexts using their IDs and evaluate their SMD context scope IEs to determine if an SMD context ID can be reused.

[0174] If the SMF determines to use the SMD service, it configures the UPF as described hereinafter. If the SMF determines to reuse an SMD context, the SMF provides the SMD context (e.g., ID) to the UPF in phase 3. If the SMD determines not to use the SMD service, it may proceed with the PDU session establishment / update procedure as usual, without requesting SMD service from the UPF.Phase 3: Secure Metadata Context Establishment

[0175] In a third phase, an SMD context is established between the SMD endpoints.

[0176] SMD endpoints are producers (SMD sender) and consumers (SMD receiver) of SMD data and control messages. For this purpose, SMD endpoints establish an SMD context between themselves. SMD endpoints are on one side, the application sender (e.g., an AS or WTRU), and on the other side, a mobile network node (e.g., a UPF, SMF or NEF). The UPF is typically the SMD receiver for SMD data messages. Other network nodes (SMF, NEF) may, in some systems, be involved in the SMD context establishment, and provide to the UPF the key material needed to decrypt SMD data messages. In other some systems, the UPF is an SMD endpoint for control and data messages.

[0177] SMD control messages are exchanged between secure metadata endpoints. The control messages are used to establish an SMD context between secure metadata endpoints. Secure metadata control message carries secure metadata context IES. To be later retrieved, an SMD context can be associated with identifying information such as an SMD context, a traffic filter, QoS flow, PDU session and / or N4 session. For example, the SMD receiver (e.g., UPF or WTRU) may maintain a mapping table which associates identifying information with the SMD context. Later, in phase 3, the SMD receiver will be able to retrieve the SMD context using this table and information from a PDU.

[0178] SMD context IEs may include some of the following IEs (e.g., a-e below): a) An SMD context session state, which is maintained on both the sender and receiver sides of the secure metadata transmission, e.g., UPF (and / or SMF) on one side, and AS on the other side. The secure metadata context session state is established and maintained using an underlying secure metadata protocol, e.g., DTLS or QUIC or HTTP. The secure metadata context session state is protocol-dependent (i.e., dependent on the underlying secure metadata protocol). For example, if DTLS is used as underlying secure metadata protocol, the SMD context session state may include a DTLS session key and other DTLS session-related information. For example, in a shared key based SMD service, the SMD context session state may include a shared key and key lifetime; b) An SMD context ID, which may be used to retrieve the SMD context when needed during SMD context establishment or to encrypt / decrypt an SMD data message. The SMD context ID may include, e.g., a combination of one or more of AS-ID, UPF -ID, SMF -ID, an ID for the SMD context that is unique for a given AS-ID, UPF-ID or SMF-ID; c) An SMD service type, which identifies the SMD service type (already defined hereinbefore) corresponding to this SMD context; d) SMD context scope IEs, which describe conditions of use and potential reuse of the SMD context across application sessions. When the network (e.g., SMF) determines that an SMDcontext is needed, it may first try to reuse an existing SMD context, if the SMD context scope IES allow for it. Otherwise, a new SMD context may be established. They may include (see e.g., dl- d7 below): dl) An AS ID, which identifies the AS that this SMD context is shared with. Typically, an SMD context may only be shared with one AS. The AS ID may be an FQDN, and / or IP address and port and protocol, and / or other types of ID; d2) A timestamp indicating a validity period, until which the same SMD context can be used for any application session between this AS and (potentially any) WTRUs; d3) A network slice (N-SSAI), service area or RAN node ID, indicating that the SMD context can be reused within this slice, service area or when this RAN node is used for the PDU session; d4) A trigger for ending the SMD context lifetime, e.g., “at the end of the last media session making use of this SMD context”; d5) One or more WTRU identities (e.g., SUPI, GPSI) that identify WTRUs whose application sessions can receive SMD service using this SMD context; d6) The number of concurrent media sessions that can use this SMD context; d7) The total number of past and current media sessions that used or are using this SMD context; e) Secure metadata control messages, which may include (see for example el-e5 below): el) An underlying secure metadata protocol message, e.g., DTLS messages. These messages can be carried over the user plane and / or control plane. e2) An SMD underlying protocol type, which identifies the underlying protocol used, e.g., DTLS or QUIC. e3) An SMD context ID, which identifies an SMD context session. Such an ID enables reusing an SMD context between network and AS, for multiple application sessions between one or more WTRUs and the AS. Such an ID may also enable multiplexing multiple metadata context over one application connection. e4) An SMD control message type, which identifies the content of the message. Example of message types include MSG, ERROR, STATUS, PING, etc. See for e.g., e4a-e4b below. e4a) An SMD control message of type MSG may include a message type (MSG), context ID and an underlying protocol message. The initial MSG messages sent between SMD endpoints may also include other IEs, e.g.: a protocol type, to enable secure message endpoints to negotiate the use of a specific underlying protocol; a SMD context lifetime value, to enable secure message endpoints to negotiate how long an SMD context may be maintained for use with multiple application sessions.e4b) An SMD control message of type ERROR or STATUS may include, besides the type, a context ID and an error or status code, e.g., to report an error or to report a status upon request. An SMD control message of type PING may include type, context ID and be used to request a STATUS response from the remote SMD endpoint. For example, when SMD context establishment fails due to non-support of PDU Set feature (e.g., by RAN), then a UPF may send an error message, with cause "PDU Set feature not supported" value.

[0179] In some systems, the SMD context establishment consists in exchanging underlying SMD protocol messages between the SMD endpoints, to enable the underlying SMD protocol stack (e.g., DTLS stack) on each SMD endpoint to establish a security context. If DTLS is the underlying SMD protocol and a UPF and AS are SMD endpoints, SMD context establishment may be composed of the following steps (a simplified summary of the well-known DTLS session establishment): the UPF generates a private / public keypair for key exchange and sends a DTLS client hello message to AS; upon reception, the AS generates its own private / public keypair and sends a DTLS server hello message to UPF; the AS also generates session keys using IES from the client hello and its own keypair; upon receiving the server hello, the UPF generates session keys using IEs from the server hello and its own keypair; from this point on the UPF-AS DTLS messages are all encrypted using the session keys; UPF and AS further exchange DTLS messages to authenticate the AS and complete the handshake (e.g., the AS sends a server certificate to the UPF).

[0180] SMD endpoints need to associate a received SMD control or data message with an SMD context, to be able to decrypt the received message. In some systems, the SMD endpoint may associate a SMD context with an application flow. For example, an AS can associate an SMD context with the application flow (e.g., with the destination and source IP address and port on AS and WTRU). For example, a UPF can associate an SMD context with the PDU session for which the SMD service was requested. In some cases, where, e.g., multiple SMD contexts may be used for a given single application flow, or for a given single PDU session, it may be useful to have an SMD context ID in SMD control and / or data messages. For example, an SMD context ID may be composed of a UPF ID (e.g., a subdomain name, a string allocated by the network operator), and a numerical ID allocated by the UPF, and unique for a given UPF, over a certain time period.

[0181] The SMD context establishment relies on exchanges of SMD control messages between SMD endpoints, e.g., AS and UPF, or AS and NEF, or AS and SMF. Ultimately, the session keys (used to encrypt / decrypt SMD data messages) need to be present on the metadata sender (e.g., AS) and metadata receiver (e.g., UPF). If the NEF or SMF are SMD endpoints, they maintain the SMDcontext, but they provide the session keys to the UPF. Several methods for SMD context establishment are described hereinafter.Establishing an SMD Context through the WTRU

[0182] In a first method (“WTRU-relayed method”), the WTRU is used as a relay for SMD control messages in one direction (e.g., UPF to AS SMD control messages are relayed by the WTRU). In this first method, for UL SMD messages (e.g., UPF to AS), the UPF transmits the SMD control message to the WTRU, which forwards the SMD control message to the AS. For DL SMD messages (e.g., AS to UPF), the AS transmits the SMD control message towards the WTRU. Since the UPF is on the application flow path, the UPF can access the DL SMD message directly, without a need for relaying it through the WTRU.

[0183] An application endpoint (e.g., AS) transmits DL SMD control messages in an end-to-end PDU (e.g., between WTRU and AS). The PDU may include an application unit (e.g., a media data unit), and / or a transport-layer acknowledgement. The AS inserts an SMD control message in the packet, e.g., in a UDP option (including a UDP option type, also referred to as UDP option kind, “SMD control”, a UDP option length, an SMD context ID, and the SMD control message), IP option (including an IP option type “SMD control”, an IP option length, an SMD context ID, and the SMD control message), or other type of header (e.g., a GTP header) or trailer. The SMD and any UDP / IP option header (e.g., option type and length) are not encrypted end-to-end. The UPF can read and use the SMD control message. Since the WTRU has no use for the SMD control message, the UPF may further truncate the whole UDP option or IP option from the DL packet and then forward the truncated DL packet (e.g., to the WTRU). For example, if the SMD was transmitted in a UDP option, the UPF can update the IP header of the packet to truncate the UDP option. Truncating an SMD control or data message from a DL packet improves efficiency, since it reduces the size of the PDU to transmit over the air to the WTRU. The transmission of a DL SMD control message is therefore enabled directly from the application endpoint (e.g., AS) to the UPF. In an alternative system, both DL and UL SMD control messages are transmitted through the WTRU (as described hereinafter for UL SMD control messages), which may be less efficient but enables transmitting SMD control messages over a symmetric path. UL and / or DL SMD control messages may in some systems be transmitted inside the encrypted application transport session between WTRU and AS (e.g., in a dedicated QUIC stream if the application is transported over QUIC).

[0184] The UPF can transmit UL SMD control messages (e.g., to the AS) through the WTRU using the mobile network control plane or user plane. In a control plane example, the UPF transmits the UL SMD control message to the SMF in a new “N4 SMD control” message. Upon reception the SMF forwards the UL SMD control message to the WTRU in a NAS message. In a user plane example, the UPF transmits the UL SMD control message to the WTRU in an, e.g., UDP or MASQUE, message, over the PDU session (e.g., over a WTRU-UPF connection which may be a dedicated connection, or tunnel such as a MASQUE connection). For this purpose, when establishing the PDU session with SMD service, the UPF can create a service endpoint for SMD control messages and send the corresponding IP address, port and possibly protocol to the SMF which sends this information to the WTRU (e.g., in PDU session accept message). Then the WTRU establishes a connection with the service endpoint on the UPF.

[0185] Upon receiving an UL SMD control message, the WTRU forwards the UL SMD control message to the remote application endpoint (e.g., AS) in a UDP option, IP option, or other type of header or trailer in a manner similar to DL SMD control messages described hereinbefore. In an alternative system, since the UL SMD control message is intended for the remote application endpoint and not for an on-path SMD endpoint, the WTRU could transmit the UL SMD inside the encrypted application transport session. In another alternative system, the UL / DL SMD may be transmitted over another user plane connection between enabler components on the WTRU (e.g., edge enabler client or SEAL client) and AS (e.g., edge enabler server or SEAL server).

[0186] The WTRU-relayed method enables leveraging the trust relationship, between the WTRU application user and the AS, to authorize the SMD service. For this purpose, the WTRU application may transmit to the AS a request to use the SMD service, e.g., in an application message. In some cases, the WTRU application may further transmit to the AS, in an application message, a signature (e.g., a hash value) of an SMD control protocol message transported in a UDP / IP option. The request and / or signature can prevent cases where an attacker on the path of the application flow adds a UDP / IP option to trigger the SMD service. This enables the AS to authorize the WTRU application user to use the SMD service. The AS can then enable the SMD service to proceed with establishing the SMD context with the UPF.

[0187] The WTRU-relayed method has multiple advantages over some other methods (see for example a-d below): a) [Al] Since there is no direct connection between SMD endpoints (e.g., UPF-AS), there is no need for one of them to discover the IP address and port of the other, therefore simplifying signaling.b) [A2] The UPF does not need to be trusted or authorized by the AS. The AS authorizes the WTRU to use the SMD service, e.g., based on a business agreement between the application provider and the WTRU application user. Similarly, the network authorizes the WTRU subscriber to the SMD service, e.g., based on a service subscription. This enable scaling up since it requires less complex business arrangements. c) [A3] SMD control messages can be transmitted using the same method as SMD data messages (e.g., both using a UDP option, both using an IP option, etc.). This can reduce the number of error modes where SMD control messages are well transmitted and received, but SMD data messages are not, e.g., in cases where UDP options are not well supported in the network. d) [A4] The UPF does not need to insert headers or trailers in forwarded packets, which helps keeping network resource usage low.Establishing an SMD Context using Message Insertion by UPF

[0188] In a second method (“piggyback method”), the UPF inserts and consumes SMD control messages into / from application flow PDUs. For DL SMD control messages, the AS transmits the DL SMD control message in a UDP option / IP option / header / trailer of an application flow packet, and the UPF accesses and uses the DL SMD control message. For UL SMD control messages, the UPF waits for a suitable UL application flow packet from WTRU to AS to be available to forward; then the UPF inserts the UL SMD control message in a UDP option / IP option / header / trailer; then the UPF forwards the packet including the inserted UL SMD control message to the AS. The AS detects the presence of the SMD control message (e.g., using the UDP option header), decrypts the SMD and uses it as described hereinbefore to establish the SMD context.

[0189] When using the piggyback method, the WTRU may transmit to the AS a request IE to use the SMD service, which enables the AS to authorize the WTRU application user to use the SMD service. The AS may configure itself to send / receive SMD control and data messages based on this authorization.

[0190] The piggyback method has some advantages over some other methods, e.g. [Al] [A2] and [A3] as described hereinabove.Establishing an SMD Context using a Dedicated Control Connection

[0191] In a third method (“point-to-point connection method”), one SMD endpoint establishes a point-to-point connection with the other SMD endpoint, e.g., UPF or AS initiates an UPF-AS SMD control connection. The point-to-point connection may use the underlying SMD protocol (e.g.,DTLS over UDP) or it may transport the underlying SMD protocol over any application-layer, transport or tunneling protocol (e.g., QUIC, MASQUE, GTP, etc.). In an example, the UPF establishes a DTLS connection with the AS. Once the DTLS connection is established, both AS and UPF can create an SMD context, that includes the DTLS session state including the session keys.

[0192] A discovery method is needed to enable the point-to-point connection method. One of the SMD endpoints (e.g., UPF or AS) needs to be provided with (e.g., to discover) the remote SMD endpoint (e.g., IP address and port for a point-to-point DTLS connection). This discovery may be performed using any well-known discovery methods. In a first example, the AS / AF provides an SMD service IP address and port to the UPF through a NEF or PCF Web Service API, and NEF / PCF transmit the IP address and port to the SMF, which provides them to the UPF. In a second example, the AS / AF sends a request to a NEF or PCF Web Service API and the NEF / PCF provides in a response the SMD service IP address and port on the UPF (which it may obtain from the SMF).

[0193] The point-to-point connection method has some advantages over other methods: it does not send SMD control messages over the WTRU air interface and does not require the UPF to insert UDP / IP options in application PDUs.Establishing an SMD Context using a NEF / AAnF API

[0194] In a fourth method (“shared key-based method”), the AF triggers the establishment of an SMD security context between the UPF and AS. The AF provides an indication to the NEF requesting usage of SMD using pre-shared key-based security for a particular session (e.g., using the Nnef AFsessionWithQoS Create API). The AF may include an AKMA key identifier (A- KID) to identify the KAKMA key from which to derive a pre-shared key. The NEF requests a preshared key (KAFSMD) from AAnF. The AAnF may derive the pre-shared key from KAKMA directly or from KAF. The NEF provides the SMF serving the session (e.g., directly or through the PCF) and the AF with the KAFSMD key. The UPF is configured by SMF with the pre-shared key KAFSMD key and A-KID. The AS is configured by AF with the pre-shared key KAFSMD key and A-KID. From this point on, the SMD context can be established in several ways, for example a-c below: a) In some systems, the UPF and AF perform a key agreement protocol (e.g., using DTLS-PSK) for the SMD session key wherein A-KID is transmitted to identify the pre-shared key KAFSMD.The key agreement protocol may be performed using any of the methods described herein (e.g., WTRU-relayed method, piggyback methods, or point-to-point connection method). b) In some systems, the pre-shared key KAFSMD (or a key derived from KAFSMD) may be used to directly encrypt / decrypt the SMD data messages. c) In some systems, the NEF may send the AF a shared key KAFSMD and a corresponding key identifier KAFSMD ID upon AF request (e.g., using Nnef AFsessionWithQoS Create request / response messages). Such method may be used for example for the scenario where AF (or WTRU) do not have support for AKMA. The NEF may generate the KAFSMD and identifier locally or communicate with another NF (e.g., the AUSF serving the WTRU) that may derive KAFSMD, and identifier based on an established access key (e.g., KAUSF). From this point on, the SMD context establishment can be complete as per a) or b).

[0195] The shared key -based method has some advantages over other methods: it leverages an existing framework for application-network interoperation and WTRU 3GPP access credentials (e.g., based on USIM), therefore limiting the number of changes to the system, to support SMD.Deployment Considerations

[0196] The WTRU application and AS may use a software library to implement mechanisms and procedures described herein.

[0197] The WTRU application can communicate with the AS through a WTRU software component that can modify (e.g., add a UDP option) to application flow packets sent to the AS. If using the user plane, the software component establishes a connection to the UPF based on an IP address and port received during the PDU session establishment. If using the control plane, the software component receives NAS messages from the SMF. The WTRU software component listens to SMD control messages, and relay these messages to the AS, e.g., by adding UDP or IP options on application PDUs.

[0198] The AS can connect to the WTRU application through an AS software component. The AS software component receives media data and PDU set information from the AS application and transmits the media data in an application PDU and adds SMD (e.g., PDU set information) as a UDP option. The AS software component also establishes and manages the SMD context, for example by sending and receiving SMD control protocol messages, or alternative by receiving a shared key from the AF.MTU Considerations

[0199] Path MTU should be controlled to enable methods described herein. Since SMD control and data messages can be sent in a header / trailer portion of a user plane packet, it is preferrable, to avoid packet loss or fragmentation, that the combined size of the initial packet and the SMD control / data message do not exceed the path MTU. Typically, SMD data messages should have a stable and relatively small size, since per-PDU or per-PDU set metadata tends to be limited in size by design, for efficiency. On the other side, SMD control messages may be larger but relatively few, since they are used to setup and maintain the SMD context. Based on these observations, several strategies may be used, possibly in combination, to enable transmitting SMD control / data messages while not exceeding the path MTU.

[0200] Firstly, the SMD control / data message size may be kept small. For example, the underlying SMD protocol stacks (e.g., DTLS on AS and UPF) may be configured with a small MTU. For example, a standard DTLS stack should be able to operate at the IPv4 minimum MTU of 576 bytes. An underlying SMD protocol may be further specialized for SMD and be designed to operate at a lower MTU than 576.

[0201] Secondly, the path MTU for the WTRU-AS application traffic may be set to a lower value in order to leave room for SMD messages. This may particularly be useful for SMD data messages, which may be carried in downlink packets including large application PDUs. In an example where SMD data messages are designed to be smaller than 50 bytes (including the PDU set IES and underlying SMD protocol overhead), then the path MTU on the SMD data message sender (e.g., AS) should be set to the detected or configured path MTU, minus 50.

[0202] Thirdly, an SMD control message sender / forwarder (e.g., AS / WTRU / UPF) may determine to add, or not, a SMD control message in a packet, based on whether the packet is sufficiently smaller than the path MTU. The sender may for example wait for a small packet (e.g., a transport acknowledgement) to be available for sending / forwarding, and insert a pending SMD control message to this packet. If no small packets become available in a timely manner, a sender may determine to trigger the sending of a transport message (e.g., a QUIC ping message) to get the opportunity to send the SMD control message.SMD Context between WTRU and UPF

[0203] An SMD context may be established between UPF and WTRU, in some systems, to enable metadata exchange between UPF and WTRU. For this purpose, the UPF and WTRU may exchange SMD control messages, as described herein. For example, a user plane or control plane connection between WTRU and UPF may be used. E.g., WTRU may connect to an IP address andport provided by the UPF to WTRU through SMF during the PDU session establishment, and the WTRU and UPF may exchange SMD control message over this connection. In an alternative system, the WTRU and UPF may exchange SMD control messages over the control plane, through SMF, over N4 (UPF-SMF) and a NAS message between SMF and WTRU.Reusing an SMD Context

[0204] A same SMD context may be used for applying an SMD service to multiple application sessions, e.g., between a WTRU and an AS, or between multiple WTRUs and an AS. SMD context reuse can limit the amount of processing on SMD endpoints (e.g., UPF and AS). An SMD context lifetime may be negotiated during SMD context establishment, and / or it may be configured on the SMD endpoints, e.g., through the NEF by an application provider, or in the network by the network operator. When establishing a PDU session with SMD service, the SMF or UPF may determine that an SMD context already exists or has been used recently, with the same AS. In an example where an SMD context is currently actively used for another connection, the UPF sends an initial SMD control message including the active SMD context ID. Upon reception, the AS may identify the currently active session and reply with a SMD control message accepting the active SMD context ID. In an example where an SMD context was recently used, the UPF uses a previously obtained resumption ticket (e.g., a DTLS NewSessionTicket received from AS during the recent SMD context lifetime) to generate the initial SMD control message to AS (e.g., to generate a DTLS client hello message using the resumption key from the ticket). The AS may locate the resumption key in a recent SMD context (e.g., using the usual DTLS resumption method), and may accept to use the recent SMD context.Phase 4: Secure Metadata Transmission and Usage Primary Use Case (SMD Transmitted from AS to UPF)

[0205] In a fourth phase, secure metadata is transmitted between the SMD endpoints. The SMD service can be used to transmit various types of metadata, in different systems and use cases.

[0206] In a first use case, an application endpoint (e.g., AS) transmits SMD data messages to provide PDU set IES metadata to a UPF. The SMD data messages are transmitted in an end-to-end PDU (e.g., between WTRU and AS). The PDU may include an application unit (e.g., a media data unit), and / or a transport-layer acknowledgement. The AS inserts an SMD data message in the packet, e.g., in a UDP option (including a UDP option type “SMD data”, a UDP option length, an SMD context ID, and the encrypted SMD), IP option (including an IP option type “SMD data”, anIP option length, an SMD context ID, and the encrypted SMD), or other type of header (e.g., a GTP header) or trailer. The SMD and any UDP / IP option header (e.g., option type and length) are not encrypted end-to-end. The SMD is encrypted using the SMD context. Upon receiving the PDU, the UPF uses information from the PDU (e.g., source / destination IP address and port, IP protocol, SMD context ID) and mapping information created in phase 3, to retrieve the SMD context suitable for decrypting the SMD. The UPF decrypts and uses the SMD. The UPF may further truncate the whole UDP option or IP option from the packet and then forward the truncated packet (e.g., to the WTRU). For example, if the SMD was transmitted in a UDP option, the UPF can update the IP header of the packet to truncate the UDP option.Secondary Use Case (SMD Transmitted from UPF to WTRU)

[0207] In a second use case, a UPF transmits SMD data messages to provide bandwidth hints metadata to a WTRU during an ABR media session (e.g., “target 1Mbps for this video session”). To enable this scenario, an SMD context is established between UPF and WTRU (e.g., using a shared key-based method). Following SMD context establishment between UPF and WTRU, the UPF adds metadata (e.g., a UDP or IP option holding metadata encrypted using the SMD context) to an application PDU forwarded downlink from AS to WTRU. Upon reception of the packet holding application PDU and metadata, the WTRU identifies the SMD context associated with the PDU, and decrypts and uses the metadata (e.g., as input to the ABR rate control algorithm on the WTRU) and uses the application PDU as usual, e.g., it transmits media data from the PDU to the media player.Phase 5: Secure Metadata Context Maintenance

[0208] In a fifth phase, the SMD context is maintained over time, between the SMD endpoints.

[0209] Additional SMD control messages may be needed, beyond the initial SMD context setup, between the SMD endpoints to maintain the SMD context over time. For example, secure protocols such as DTLS can update session keys to maintain the security properties of a connection. To enable SMD context maintenance, SMD endpoints (e.g., UPF and AS) may exchange SMD control messages as described herein for phase 3, e.g., through WTRU or directly between UPF and AS. When using shared key based SMD service, the AF may request a new shared key to the NEF prior to the shared key expiration.Phase 6: Closing a Connection with Secure Metadata

[0210] In a fifth phase, the application session with SMD service is closed.

[0211] When an application session with SMD service is closed, the UPF and AS may determine to close the SMD context, or they may determine, e.g., based on configuration of an SMD context lifetime (e.g., using the SMD context scope IES defined herein) by the operator and / or application provider, to keep the SMD context available for future application sessions (with the same WTRU or different WTRUs). When the authorization for using an SMD service is revoked, the PCF may notify the SMF, which can configure the UPF to stop using the SMD context for decrypting SMD for an SDF.Procedures

[0212] Efficient SMD transmission for encrypted traffic may be accomplished using a combination of embodiments described herein in FIGs. 4 to 7.WTRU-Relayed Method

[0213] FIG. 5 describes an exemplary procedure for the provisioning, establishment, and operation of an SMD context between the network and an AS. In this exemplary procedure, the SMD context establishment uses the WTRU as a relay between the UPF and the AS.

[0214] The section "A" of the figure represents the provisioning of the SMD service, the initiation of the SMD service and the establishment of an SMD context.

[0215] In A.0, the SMD service is provisioned as described in section 5.2.

[0216] In A.l, the WTRU application triggers the establishment of an, e.g., XR, application session. For example, the WTRU opens a socket to communicate with an AS.

[0217] The SMD service may be initiated in multiple manners.

[0218] In one example, the AF requests to influence an existing PDU session, to add SMD service for flow(s) on this PDU session. In A.2, the AF sends an "AF session with required QoS" request to PCF through NEF or directly, if AS is trusted.

[0219] In another example, in A.3a and A.3b, the WTRU sends a PDU session establishment or modification request message, which may include an SMD request indication. Upon reception, the SMF sends a message to the PCF to request policy rules update, e.g., a Npcf_SMPolicyControl_Update request.

[0220] In both cases (A.2 or A.3), in A.4 the PCF sends policy rule(s) including SMD request IEs, to the SMF, for example in a Npcf_SMPolicyControl_UpdateNotify message (if AF initiated the request), or Npcf SMPolicyControl Update response message (if WTRU initiated the request).

[0221] In A.5, upon receiving the policy rules including SMD request IES, the SMF determines to use the SMD service (as described in section 5.3)

[0222] In A.6, the SMF sends an N4 session establishment or modification request to UPF, including SMD request IEs. The UPF uses the SMD request IEs to configure an SMD endpoint. The UPF generates SMD session state and an initial underlying protocol message (e.g., DTLS client hello), in A.7. the UPF sends an N4 session establishment / modification response to SMF, including an indication to use SMD, the initial SMD control message, and in some systems, a UPF endpoint IP address and port. In A.9, the SMF forwards these IEs to the WTRU, in a PDU session establishment or update accept message.

[0223] NOTE: in alternate systems, the UPF may send the initial SMD control message to WTRU over the user plane, similar to the B.1. message.

[0224] In A.10, in some systems, the WTRU establishes a user plane connection to the UPF, using the UPF endpoint IP address and port received in step A.9. This enables SMD control messages to be received from the UPF over the user plane. In an alternative system, step A.10 is not needed and the SMD control messages are received from the UPF in a NAS message, through the SMF.

[0225] In A.11, the WTRU application sends an application message to the AS. The application message may include an indication to use the SMD service (e.g., at the application layer). The WTRU determines that there is enough room (i.e., before reaching the path MTU) in the IP packet to add the initial SMD control message (e.g., in a UDP or IP option). If there is not enough room, the WTRU may wait for a small application PDU or transport acknowledgement, or the WTRU may trigger sending a new transport message to AS (e.g., PING message), to add the initial SMD control message.

[0226] In A.12, upon receiving the application message including an indication to use the SMD service, the AS authorizes the application user to use the SMD service. The AS processes the initial SMD control message, initiates an SMD session state (e.g., including a DTLS session), and generates an SMD control response message (e.g., including a DTLS server hello).

[0227] In A.13, the application sends an application PDU including an indication to use the SMD service, and an SMD control response message, e.g., in a UDP or IP option.

[0228] In A.14, the UPF receives the application message, detects the presence of the SMD control message (e.g., based on a UDP or IP option header), and processes the SMD control message through the SMD context on the UPF (e.g., forwards it to the local DTLS session on the UPF). The SMD context may generate another SMD control message.

[0229] In A.15, the UPF forwards the application message to the WTRU. The UPF may truncate the SMD control response message from the application message (e.g., truncating the UDP or IP option from the PDU), since the WTRU does not need this part of the message.

[0230] The section "B" of the figure represents the transmission of an UL SMD control message (i.e., from UPF to AS), and a DL SMD control message (i.e., from AS to UPF). UPF and AS may exchange multiple SMD control messages to establish the SMD context (e.g., similarly to a DTLS session establishment).

[0231] In B.l, the UPF sends a UL SMD control message to the WTRU, over a user plane message (e.g., UDP or MASQUE between UPF and WTRU) or over a control plane message (e.g., an N4 notification message from UPF to SMF, and a NAS message from SMF to WTRU). In B.2, the WTRU inserts the UL SMD control message in an application flow message from WTRU to AS (e.g., in a UDP or IP option). In B.3, the AS detects the presence of an SMD control message (e.g., based on IP or UDP header) and processes it.

[0232] In B.4 the AS inserts a DL SMD control message in an application flow message from AS to WTRU. In B.5, the UPF detects and processes the SMD control message. The UPF may truncate the SMD control message from the application flow message, prior to forwarding the application flow message to the WTRU (B.6).

[0233] The section "C" of the figure represents the operation of the SMD service, in an example usage where the SMD is composed of PDU set IES.

[0234] In C.1, the AS performs PDU set identification (e.g., based on PDU set information from the application, or from the media headers, prior to encryption of the media headers). In C.2, the AS encrypts the PDU set IEs using the SMD context, which results in a secure metadata IE (SMD) and inserts the SMD in an application flow message (e.g., a DL media data flow PDU). The AS may also include an SMD context ID, to facilitate the identification of the SMD context to use by the UPF.

[0235] In C.3, the UPF receives the DL media flow PDU, detects the presence of SMD, identifies the relevant SMD context (e.g., using SMD context ID and / or PDU session traffic filters), and decrypts the SMD using the SMD context. The UPF reads the PDU set IEs and set them in the GTP header of the GTP packet including the PDU, prior to sending the GTP packet to the RAN (C.4). Prior to forwarding the PDU, the UPF may truncate the SMD from the PDU.

[0236] From this point on, the RAN provides QoS handling using PDU set IEs (C.5) and transmits the PDU towards the WTRU (C.6), where the WTRU application can play / render media data from the PDU.Piggyback Method

[0237] In some systems, instead of using the WTRU to relay (e.g., UL) SMD control messages, the UPF inserts SMD control messages in end-to-end application packets. The procedure is based on FIG. 5 with the following changes (a-c): a) Step A.10 is not needed; b) The initial SMD control message is not sent to the WTRU over the control plane (A.8 / A.9). The initial SMD control message is not forwarded by the WTRU in step Al l. Instead, the UPF inserts the initial SMD control message into the packet of step Al l, when the UPF receives and forwards the packet to AS; and c) Step Bl is not needed. The SMD control message is not forwarded by the WTRU in step B2. Instead, the UPF inserts the SMD control message into the packet of step B2, when the UPF receives and forwards the packet to AS.Point-to-point Connection Method

[0238] FIG. 6 describes an exemplary procedure for the provisioning, establishment, and operation of an SMD context between the network and an AS. In this exemplary procedure, the SMD context establishment is performed directly between the UPF and the AS. For example, UPF can establish an “SMD control connection” with the AS, using the underlying SMD protocol (e.g., DTLS). Once the SMD control connection is established, SMD data can be encrypted using the SMD context (e.g., SMD data can be encrypted as a DTLS record using the DTLS / SMD control connection). The SMD data is then sent, by the AS, in a header / trailer (e.g., UDP option) in an application PDU of the WTRU-AS end-to-end application connection.

[0239] The section "A" of the figure represents the provisioning of the SMD service, the initiation of the SMD service and the establishment of an SMD context.

[0240] A.O and A.1 are similar to FIG. 5.

[0241] In A.2, the WTRU triggers the establishment of a PDU session.

[0242] In A.3, the WTRU sends an application flow message, including an indication to use the SMD service.

[0243] Upon receiving the message, the AS / AF authorizes the application user to benefit from the SMD service. The AS / AF sends an "AS Session with required QoS" request, including SMD requests IES, to the NEF / PCF (A.4). The SMD request IES can include the IP address or FQDN, and port of the AS. The PCF update policies on the SMF, with the SMD request IEs (A.5). The SMF sends an N4 session modification request to the UPF, including the SMD request IEs (A.6).

[0244] The UPF configures an SMD endpoint for the PDU session and / or SDF. The UPF generates an SMD context and an initial underlying protocol message (A.7), then sends an initial SMD control request message including the underlying protocol message to the AS (A.8). The initial SMD control request may include an SMD context ID, which can be used in SMD service operation, to help the UPF identify the SMD context to use to decrypt the SMD. The SMD context ID, if it was provided by AS / AF in step A.4, can also be used by the AS to link the UPF message A.8 with the original request in A.4.

[0245] In A.9, the AS authorizes the UPF to use the SMD service, e.g., based on matching the SMD context ID with the request in step A.4. The AS generates and SMD context and an underlying protocol response. The AS links the SMD context to the application session, (e.g., using the SMD context ID), to enable retrieving the appropriate SMD context to encrypt metadata associated with the application session. In A.10 and A.11, the AS replies to the UPF and then completes the establishment of the SMD context (e.g., it completes the DTLS session establishment). In A.12, the UPF link the SMD context to the PDU session and SDF, to enable retrieving the appropriate SMD context when receiving encrypted metadata.

[0246] In B, UPF and AS may further exchange messages to maintain the SMD context (e.g., additional DTLS messages may be exchanged to update the session keys during the lifetime of the session).

[0247] In C, the SMD service operation is similar to the section "C" in FIG. 5.

[0248] Notel : in another system, in the procedure in FIG. 6 the network provides UPF endpoint IP address, protocol and port to AS in reply to NEF request, and then AS initiates direct connection to UPF.

[0249] Note2: in yet another system, in the procedure in FIG. 6, the AS (e.g., through NEF) and UPF (e.g., through SMF) obtain a shared key, e.g., from AAnF. The AS and UPF use the shared key (or a key derived from the shared key) to establish the SMD control session (e.g., using the PSK method of the DTLS protocol).Shared Key-based Method

[0250] FIG. 7 describes an exemplary procedure for the provisioning, establishment, and operation of an SMD context between the network and an AS. In this exemplary procedure, the SMD context includes a shared key established between the 5GC and the AS, e.g., obtained from AAnF. An SMD session key may be derived from the shared key, or alternatively the shared key may be used directly as the SMD session key. From this point on, SMD data can be encrypted using the SMD session key of the SMD context (e.g., using symmetric encryption). The SMD datais then sent, by the AS, in a header / trailer (e.g., UDP option) in an application PDU of the WTRU- AS end-to-end application connection.

[0251] The section "A" of the figure represents the provisioning of the SMD service, the initiation of the SMD service and the establishment of an SMD context.

[0252] A.0, A.1, A.2, A.3 are similar to FIG. 6. Additionally, AKMA bootstrapping may be performed during the WTRU registration, in cases where the AKMA framework (e.g., including AAnF) is used to obtain the shared key in this procedure. The procedure described herein uses AKMA, however, more generally the 5GC can establish a SMD context based on a shared key, on demand with AS, with or without AKMA dependency. For example, the shared key may be derived at AUSF upon NEF request. In another example, the trusted AF itself may provide the shared key to the 5GC through NEF.

[0253] In A.3, the WTRU sends an application flow message, including an indication to use the SMD service and an identifier for the shared key (e.g., A-KID).

[0254] In A.4 / A.5, the AS / AF requests and obtains an application key (e.g., an AKMA application key) from a network function (e.g., AAnF). The AS / AF provide the key identifier (e.g., A-KID) and the AF identifier (AF-ID) in the request. The AAnF uses A-KID, AF-ID to derive a key (Kaf). The reply may include a key (Kaf) and associated parameters such as expiration time and user identity (e.g., SUPI, GPSI).

[0255] In A.6, the AF / AS configures an SMD endpoint using the Kaf.

[0256] In A.7a / A.7b, the AS / AF provides SMD request IES, key identification (e.g., A-KID) and AF identification to the network (e.g., “AF session with required QoS request” to NEF / PCF and / or Npcf PolicyAuthorization Update from NEF to PCF). The PCF notifies the SMF with the modified policy rule including SMD request IEs and A-KID (A.8), e.g., in a Npcf_SMPolicyControl_UpdateNotify message.

[0257] In A.9 / A.10 the SMF requests and obtains an application key (e.g., an AKMA application key) from a network function (e.g., AAnF). The AS / AF provide the key identifier (e.g., A-KID) and the SMF or UPF identifier (SMF-ID or UPF-ID) in the request. The reply may include a key (Kaf) and associated parameters such as expiration time and user identity (e.g., SUPI, GPSI).

[0258] In A.11, A.12 and A.13, the SMF modifies the N4 session with UPF and provides the SMD requests IEs, A-KID, the session key (Kaf) and associated parameters (e.g., expiration time). The UPF configures an SMD endpoint using the Kaf. The UPF link the SMD context with the PDU session and SDF. Then the UPF sends the replies to the SMF, indicating success for the operation.

[0259] In A.14 / A.15 / A.16, the SMF sends a message (e.g., notification) to the PCF, indicating that the SMD configuration is complete, and including the SMD context ID and A-KID. A-KID may be used as SMD context ID in some systems. The PCF sends an "AF session with required QoS" response or notification message to the AS (directly or through the NEF), indicating that the SMD configuration is complete, and including the SMD context ID and A-KID. Upon reception, the AF / AS updates its SMD endpoint to indicate it can be used to encrypt metadata. If SMD context ID is different from A-KID, the SMD context ID is configured in the SMD context.

[0260] The AF and SMF may later retrieve new Kaf from the AAnF (for AF, possibly through the NEF), prior to the expiration time of the previous Kaf. The SMF then configures the new Kaf into the UPF, as described herein.

[0261] Notel : if the AF is trusted by the network operator, the AF may directly communicate with PCF and AAnF, instead of passing through the NEF as described in FIG. 7.

[0262] Note2: in FIG. 7, in some systems, the SMD context ID value may be omitted, and A- KID may be used as SMD context ID, to reduce the number of IDs.

[0263] Alternatively, to the above A.4 and A.5 the AF may establish an SMD shared key with 5GC assistance via NEF using messages A.7, A.15 (e.g., receive a new key and identifier in A.15). In that case, the AF may configure the SMF endpoint using the SMD shared key at A.16.

[0264] The AF may subsequently obtain a fresh SMD key (e.g., upon expiry) from NEF for that session using a Nnef AFsessionWithQoS Update request / response exchange. In that scenario, the PCF / SMF / UPF are updated with the new SMD key. AF may continue to protect SMD traffic using the old key until reception of the new key / acknowledgment of its configuration in the 5GC (UPF).

[0265] In some systems, the SMD context establishment may combine steps from FIG. 5 and FIG. 7. E.g., a shared key may be used to initiate (using DTLS-PSK) a WTRU-relayed or piggybacked DTLS connection between UPF and AS, and the DTLS session key may be used to encrypt SMD (as the AS) and decrypt SMD (at the UPF).

[0266] In some systems, the SMD context establishment may combine steps from FIG. 6 and FIG. 7. E.g., a shared key may be used to initiate a point-to-point DTLS connection between UPF and AS, and the DTLS session key may be used to encrypt SMD (as the AS) and decrypt SMD (at the UPF).SMD for Encrypted Traffic between WTRU and UPF

[0267] FIG. 8 describes an exemplary procedure for the provisioning, establishment, and operation of an SMD context between the UPF and a WTRU. In this exemplary procedure, the SMD context establishment is initiated through the control plane and completed over the user planebetween WTRU and UPF. As for the other cases described herein, SMD is inserted as a trailer or header of IP packets carrying an end-to-end encrypted application PDU.

[0268] A WTRU triggers the establishment of an application session in A.1. In A.3a to A.9, the WTRU triggers the establishment or update of a PDU session, similarly to the steps described in steps A.3a to A.9 in FIG. 5, with the following differences (e.g. a-d below): a) (1) the PDU session establishment / update message may include a WTRU capability to support the SMD service as a receiver of SMD; b) (2) the policy rule in A.4 indicates an SMD service from UPF to WTRU; c) (3) in A.5 the SMF obtains a Ksmd key (e.g., from AUSF or AAnF) and provides it to the UPF in A.6. In A.11, the WTRU derives the Ksmd key locally on the WTRU (e.g., from a Kausf or Kakma). Ksmd is derived by the WTRU and network from the same root key, provisioned in the WTRU and in the network, and using the same derivation function and derivation parameters (following existing practices related to AUSF and / or AAnF). At this point, the UPF and WTRU have a shared key Ksmd, which they can use to establish an SMD context in the following steps; d) (4) the A.9 response does not typically include an initial SMD control message (e.g., instead, if the WTRU acts as DTLS client, the WTRU will send an initial SMD control message in A.12). The A.9 response may include the IP address and port of the UPF SMD endpoint, if using the user plane for SMD control.

[0269] In A.10, the WTRU establishes a user plane connection for UPF-WTRU SMD messages. Alternatively, in some systems the UPF-WTRU SMD messages are sent on the control plane (e.g., using NAS and N4 messages as described hereinbefore) and A.10 is not needed. In this alternative, the WTRU does not receive an IP address and port of UPF SMD endpoint in step A.9.

[0270] If the WTRU acts as underlying SMD protocol (e.g., DTLS) client, the WTRU sends an initial SMD control message in A.12. Alternatively, in some systems the UPF may be a client and send the initial SMD control message.

[0271] WTRU and UPF establish an SMD context using SMD control messages over the control or user plane as shown in B.1 and B.2. In an example, WTRU and UPF establish a DTLS session and use the DTLS session key to encrypt / decrypt the SMD in the following steps.

[0272] The AS sends an application DL PDU to the WTRU (C.l, C.2). The UPF generates, or receives from the SMF, a bandwidth capacity hint for the application flow. For example, the SMF / UPF, based on the current cell capacity and the number of concurrent application sessions with similar QoS, may load balance the available capacity between the session. The PDU encrypts the bandwidth capacity hint metadata inside an SMD data message (C.3) and inserts the SMD datamessage in the application DL PDU and forwards the DL PDU to the WTRU (C.4). The WTRU detects the presence of SMD in the DL PDU, e.g., based on UDP / IP option type / kind, decrypts the SMD, and provides the bandwidth capacity hint to the WTRU application. The WTRU application (e.g., an ABR media streaming application) may use the bandwidth capacity hint to determine the media representation it requests from the server.

[0273] FIG. 9 is a flow chart of an exemplary embodiment of an embodiment of a method implemented by a core network element (e.g., a user plane function) in a core network of a wireless network. The method may comprise: a) In 901, receiving an indication to use encrypted metadata between an application server and the network element (e.g., the user plane function); b) In 902, obtaining a secure metadata (SMD) context associated with the encrypted metadata, the SMD context comprising a session key; c) In 903, obtaining mapping information associating the SMD context with an application flow between a wireless transmit-receive unit (WTRU) and the application server; d) In 904, receiving a packet data unit (PDU) from the application server; e) In 905, determining presence of encrypted metadata in the received PDU; f) In 906, based on the mapping information associating the SMD context with an application flow between the WTRU and the application server and based on information comprised in the received PDU, identifying the obtained SMD context associated with the encrypted metadata in the PDU; g) In 907, decrypting the encrypted metadata in the PDU, using the session key comprised in the obtained SMD context, and obtaining decrypted metadata; h) In 908, obtaining PDU set information from the decrypted metadata; and i) In 909, forwarding, to a radio access network, the received PDU and the PDU set information obtained.The SMD context is a security context, and may be a secure metadata context that includes the session key but also other IES (SMD context IES) such as an ID, a service type describing the protocols used, information about the scope of the SMD context.

[0274] According to an embodiment, the mapping information is one of: a traffic filter; and an SMD context identifier.

[0275] According to an embodiment, the obtaining the SMD context may comprise: creating an encrypted metadata handshake request message, and transmitting the encrypted metadata handshake request message; receiving an encrypted metadata handshake response message;creating the SMD context and creating the session key using the encrypted metadata handshake response message.

[0276] According to an embodiment, the encrypted metadata handshake request message is a datagram transport layer security (DTLS) client hello message, and the encrypted metadata handshake response message is a DTLS server hello message.

[0277] According to an embodiment, the obtaining an SMD context comprises receiving a message comprising the session key.

[0278] According to an embodiment, the obtaining the SMD context further comprises, after receiving the message comprising the session key, sending an encrypted metadata handshake finished message.

[0279] According to an embodiment, the obtaining an SMD context further comprises, after receiving the message comprising the session key, receiving a message comprising a server certificate and using the server certificate to authenticate the application server.

[0280] According to an embodiment, the encrypted metadata handshake finished message is a datagram transport layer security (DTLS) finished message, encrypted with the session key.

[0281] There is also disclosed a network element (e.g., an UPF), comprising at least one processor that may be configured to: a) receive an indication to use encrypted metadata between an application server and the network element; b) obtain a secure metadata (SMD) context associated with the encrypted metadata, the SMD context comprising a session key; c) obtain mapping information associating the SMD context with an application flow between a wireless transmit-receive unit (WTRU) and the application server; d) receive a packet data unit (PDU) from the application server; e) determine presence of encrypted metadata in the received PDU; f) based on the mapping information associating the SMD context with an application flow between the WTRU and the application server and based on information comprised in the received PDU, identify the obtained SMD context associated with the encrypted metadata in the PDU; g) decrypt the encrypted metadata in the PDU, using the session key comprised in the obtained SMD context, and obtaining decrypted metadata; h) obtain PDU set information from the decrypted metadata; and i) forward, to a radio access network, the received PDU and the PDU set information obtained.

[0282] According to an embodiment, the mapping information is one of: a traffic filter; and an SMD context identifier.

[0283] According to an embodiment, to obtain the SMD context, the at least one processor is configured to: create an encrypted metadata handshake request message, and transmitting the encrypted metadata handshake request message; receive an encrypted metadata handshake response message; and create the SMD context and creating the session key using the encrypted metadata handshake response message.

[0284] According to an embodiment, the encrypted metadata handshake request message is a datagram transport layer security (DTLS) client hello message, and the encrypted metadata handshake response message is a DTLS server hello message.

[0285] According to an embodiment, the obtaining an SMD context further comprises, after receiving a message comprising the session key, receiving a message comprising a server certificate and using the server certificate to authenticate the application server.

[0286] FIG. 10 is a flow chart of an exemplary embodiment of a method implemented by a WTRU in a network. The method may comprise:In 1001, transmitting a packet data unit (PDU) session establishment or PDU session update request message to the network, indicating a capability of the WTRU to relay secure metadata (SMD) control messages for the establishment of an SMD context;In 1002, receiving from the network, in response to the PDU session establishment or session update request message, one or more SMD control messages;In 1003, inserting the one or more SMD control messages in one or more user plane PDUs; and In 1004, receiving application PDUs over the PDU session, with an SMD service applied by the network.

[0287] According to an embodiment, the SMD service applied by the network is a PDU set differentiated quality of service (QoS) service applied by the network.

[0288] According to an embodiment, the one or more SMD control messages are inserted into a user datagram protocol (UDP) option of the one or more user plane PDUs.

[0289] According to an embodiment, the one or more SMD control messages are received from one of: a session management function over a control plane; a user plane function over a user plane.

[0290] There is also discloses a wireless transmit-receive unit (WTRU) in a network. The WTRU comprises at least one processor configured to: transmit a packet data unit (PDU) session establishment or PDU session update request message to the network, indicating a capability of the WTRU to relay secure metadata (SMD) control messages for the establishment of an SMD context; receive from the network, in response to the PDU session establishment or session update request message, one or more SMD control messages; insert the one or more SMD control messages in one or more user plane PDUs; and receive application PDUs over the PDU session, with an SMD service applied by the network.

[0291] According to an embodiment, the SMD service applied by the network is a PDU set differentiated quality of service (QoS) service applied by the network.

[0292] According to an embodiment, the at least one processor is configured to insert the one or more SMD control messages into a user datagram protocol (UDP) option of the one or more user plane PDUs.

[0293] According to an embodiment, the at least one processor is configured to receive the one or more SMD control messages from one of a session management function over a control plane; a user plane function over a user plane.

[0294] FIG. 11 is a flow chart of an exemplary embodiment of a method 1100 implemented by an UPF in a core network. The method comprises:

[0295] In 1101, receiving an indication to use encrypted metadata between an application server (AS) and the UPF, wherein the indication is associated with an application flow between a wireless transmit-receive unit (WTRU) and the AS;

[0296] In 1102, obtaining a secure metadata (SMD) context associated with the application flow, the SMD context comprising a session key;

[0297] In 1103, receiving a packet data unit (PDU) associated with the application flow, from the AS;

[0298] In 1104, determining presence of encrypted metadata in the PDU;

[0299] In 1105, decrypting the encrypted metadata in the PDU, using the session key comprised in the obtained SMD context, and obtaining decrypted metadata;

[0300] In 1106, obtaining PDU set information from the decrypted metadata; and

[0301] In 1107, forwarding, to the WTRU through a radio access network, the PDU and the PDU set information.

[0302] According to an embodiment, the SMD context used to decrypt the encrypted metadata in the PDU is identified based on information comprised in the PDU.

[0303] According to an embodiment, the association between the SMD context and the application flow between the WTRU and the AS comprises at least one of a traffic filter; and an SMD context identifier.

[0304] According to an embodiment, obtaining the SMD context comprises: transmitting an encrypted metadata handshake request message; receiving an encrypted metadata handshake response message; determining the SMD context and the session key using the encrypted metadata handshake response message.

[0305] According to an embodiment, the encrypted metadata handshake request message is a datagram transport layer security (DTLS) client message, and the encrypted metadata handshake response message is a DTLS server message.

[0306] According to an embodiment, obtaining the SMD context comprises receiving a message comprising the session key.

[0307] According to an embodiment, obtaining the SMD context further comprises, after receiving the message comprising the session key, sending an encrypted metadata handshake finished message.

[0308] According to an embodiment, the encrypted metadata handshake finished message is a datagram transport layer security (DTLS) finished message, encrypted with the session key.

[0309] According to an embodiment, obtaining the SMD context comprises, after receiving the message comprising the session key, receiving a message comprising a server certificate and using the server certificate to authenticate the AS.

[0310] There is also disclosed and described a network element, comprising at least one processor configured to:

[0311] receive an indication to use encrypted metadata between an application server (AS) and the network element, wherein the indication is associated with an application flow between a wireless transmit-receive unit (WTRU) and the AS;

[0312] obtain a secure metadata (SMD) context associated with the application flow, the SMD context comprising a session key;

[0313] receive a packet data unit (PDU) associated with the application flow, from the AS;

[0314] determine presence of encrypted metadata in the PDU;

[0315] decrypt the encrypted metadata in the PDU, using the session key comprised in the obtained SMD context, and obtaining decrypted metadata;

[0316] obtain PDU set information from the decrypted metadata; and

[0317] forward, to the WTRU through a radio access network, the PDU and the PDU set information.

[0318] According to an embodiment of the network element, the SMD context used to decrypt the encrypted metadata in the PDU is identified based on information comprised in the PDU.

[0319] According to an embodiment of the network element, the association between the SMD context and the application flow between the WTRU and the AS comprises at least one of: a traffic filter; and an SMD context identifier.

[0320] According to an embodiment of the network element, to obtain the SMD context, the at least one processor is configured to:

[0321] transmit an encrypted metadata handshake request message;

[0322] receive an encrypted metadata handshake response message;

[0323] create the SMD context and creating the session key using the encrypted metadata handshake response message.

[0324] According to an embodiment of the network element, the encrypted metadata handshake request message is a datagram transport layer security (DTLS) client message, and the encrypted metadata handshake response message is a DTLS server message.

[0325] According to an embodiment of the network element, obtain the SMD context further comprises, after receiving a message comprising the session key, receiving a message comprising a server certificate and using the server certificate to authenticate the AS.

[0326] There is also disclosed and described a method implemented by a wireless transmitreceive unit (WTRU) in a network, comprising:

[0327] transmitting a packet data unit (PDU) session establishment or PDU session update request message to the network, indicating a capability of the WTRU to relay secure metadata (SMD) control messages for establishment of an SMD context;

[0328] receiving from the network, in response to the PDU session establishment or session update request message, one or more SMD control messages;

[0329] inserting the one or more SMD control messages in one or more user plane PDUs; and

[0330] receiving application PDUs over the PDU session, with an SMD service applied by the network.

[0331] According to an embodiment of the method implemented by a WTRU in a network, the SMD service applied by the network is a PDU set differentiated quality of service (QoS) service applied by the network.

[0332] According to an embodiment of the method implemented by a WTRU in a network, the one or more SMD control messages are inserted into a user datagram protocol (UDP) option of the one or more user plane PDUs.

[0333] According to an embodiment of the method implemented by a WTRU in a network, the one or more SMD control messages are received from one of:

[0334] a session management function over a control plane;

[0335] a user plane function over a user plane.

[0336] There is also disclosed and described a wireless transmit-receive unit (WTRU) in a network, comprising at least one processor configured to:

[0337] transmit a packet data unit (PDU) session establishment or PDU session update request message to the network, indicating a capability of the WTRU to relay secure metadata (SMD) control messages for the establishment of an SMD context;

[0338] receive from the network, in response to the PDU session establishment or session update request message, one or more SMD control messages;

[0339] insert the one or more SMD control messages in one or more user plane PDUs;

[0340] receive application PDUs over the PDU session, with an SMD service applied by the network.

[0341] According to an embodiment of the WRTU in a network, the SMD service applied by the network is a PDU set differentiated quality of service (QoS) service applied by the network.

[0342] According to an embodiment of the WRTU in a network, the at least one processor is configured to insert the one or more SMD control messages into a user datagram protocol (UDP) option of the one or more user plane PDUs.

[0343] According to an embodiment of the WRTU in a network, the at least one processor is configured to receive the one or more SMD control messages from one of: a session management function over a control plane; a user plane function over a user plane.

[0344] Conclusion

[0345] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, orinstruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0346] The foregoing embodiments are discussed, for simplicity, with regard to the terminology and structure of wireless communication capable devices, (e.g., radio wave emitters and receivers). However, the embodiments discussed are not limited to these systems but may be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0347] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term "video" or the term "imagery" may mean any of a snapshot, single image and / or multiple images displayed over a time basis. As another example, when referred to herein, the terms "user equipment" and its abbreviation "WTRU", the term "remote" and / or the terms "head mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a number of embodiments of a WTRU; (iii) a wireless-capable and / or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU; (iii) a wireless-capable and / or wired-capable device configured with less than all structures and functionality of a WTRU; or (iv) the like. Details of an example WTRU, which may be representative of any WTRU recited herein, are provided herein with respect to FIGs. 1 A-1D. As another example, various disclosed embodiments herein supra and infra are described as utilizing a head mounted display. Those skilled in the art will recognize that a device other than the head mounted display may be utilized and some or all of the disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other device may include a drone or other device configured to stream information for providing the adapted reality experience.

[0348] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted overwired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, WTRU, terminal, base station, RNC, or any host computer.

[0349] Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

[0350] Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices that include processors are noted. These devices may include at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[0351] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0352] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, whichexist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

[0353] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0354] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost versus efficiency tradeoffs. There may be various vehicles by which processes and / or systems and / or other technologies described herein may be effected (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary with the context in which the processes and / or systems and / or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and / or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and / or firmware.

[0355] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams, flowcharts, and / or examples. Insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those within the art that each function and / or operation within such block diagrams, flowcharts, or examples may be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing thecircuitry and / or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and / or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[0356] Those skilled in the art will recognize that it is common within the art to describe devices and / or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and / or control systems including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0357] The herein described subject matter sometimes illustrates different components included within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being "operably connected", or "operably coupled", to each otherto achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0358] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0359] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and / or the descriptions herein may include usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim including such introduced claim recitation to embodiments including only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those instanceswhere a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of' followed by a listing of a plurality of items and / or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of the items and / or the categories of items, individually or in conjunction with other items and / or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. And the term "multiple", as used herein, is intended to be synonymous with "a plurality".

[0360] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0361] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

[0362] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended toinvoke 35 U.S.C. §112, U 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

Claims

CLAIMSWhat is claimed is:

1. A method, implemented by a user plane function (UPF) in a core network, the method comprising: receiving an indication to use encrypted metadata between an application server (AS) and the UPF, wherein the indication is associated with an application flow between a wireless transmitreceive unit (WTRU) and the AS; obtaining a secure metadata (SMD) context associated with the application flow, the SMD context comprising a session key; receiving a packet data unit (PDU) associated with the application flow, from the AS; determining presence of encrypted metadata in the PDU; decrypting the encrypted metadata in the PDU, using the session key comprised in the obtained SMD context, and obtaining decrypted metadata; obtaining PDU set information from the decrypted metadata; and forwarding, to the WTRU through a radio access network, the PDU and the PDU set information.

2. The method of claim 1, wherein the SMD context used to decrypt the encrypted metadata in the PDU is identified based on information comprised in the PDU.

3. The method according to claim 1, wherein the association between the SMD context and the application flow between the WTRU and the AS comprises at least one of: a traffic filter; and an SMD context identifier.

4. The method according to any of claims 1 to 3, wherein obtaining the SMD context comprises: transmitting an encrypted metadata handshake request message; receiving an encrypted metadata handshake response message; anddetermining the SMD context and the session key using the encrypted metadata handshake response message.

5. The method according to claim 4, wherein the encrypted metadata handshake request message is a datagram transport layer security (DTLS) client message, and the encrypted metadata handshake response message is a DTLS server message.

6. The method according to any of claims 1 to 3, wherein obtaining the SMD context comprises receiving a message comprising the session key.

7. The method according to claim 6, wherein obtaining the SMD context further comprises, after receiving the message comprising the session key, sending an encrypted metadata handshake finished message.

8. The method according to claim 7, wherein the encrypted metadata handshake finished message is a datagram transport layer security (DTLS) finished message, encrypted with the session key.

9. The method according to any of claims 6 to 8, wherein obtaining the SMD context comprises, after receiving the message comprising the session key, receiving a message comprising a server certificate and using the server certificate to authenticate the AS.

10. A network element, comprising at least one processor configured to: receive an indication to use encrypted metadata between an application server (AS) and the network element, wherein the indication is associated with an application flow between a wireless transmit-receive unit (WTRU) and the AS; obtain a secure metadata (SMD) context associated with the application flow, the SMD context comprising a session key; receive a packet data unit (PDU) associated with the application flow, from the AS; determine presence of encrypted metadata in the PDU;decrypt the encrypted metadata in the PDU, using the session key comprised in the obtained SMD context, and obtaining decrypted metadata; obtain PDU set information from the decrypted metadata; and forward, to the WTRU through a radio access network, the PDU and the PDU set information.

11. The network element of claim 10, wherein the SMD context used to decrypt the encrypted metadata in the PDU is identified based on information comprised in the PDU.

12. The network element according to claim 10, wherein the association between the SMD context and the application flow between the WTRU and the AS comprises at least one of: a traffic filter; and an SMD context identifier.

13. The network element according to any of claims 10 to 13, wherein to obtain the SMD context, the at least one processor is configured to: transmit an encrypted metadata handshake request message; receive an encrypted metadata handshake response message; and create the SMD context and creating the session key using the encrypted metadata handshake response message.

14. The network element according to claim 13, wherein the encrypted metadata handshake request message is a datagram transport layer security (DTLS) client message, and the encrypted metadata handshake response message is a DTLS server message.

15. The network element according to any of claims 10 to 13, wherein obtain the SMD context further comprises, after receiving a message comprising the session key, receiving a message comprising a server certificate and using the server certificate to authenticate the AS.

16. A method implemented by a wireless transmit-receive unit (WTRU) in a network, the method comprising: transmitting a packet data unit (PDU) session establishment or PDU session update request message to the network, indicating a capability of the WTRU to relay secure metadata (SMD) control messages for establishment of an SMD context; receiving from the network, in response to the PDU session establishment or session update request message, one or more SMD control messages; inserting the one or more SMD control messages in one or more user plane PDUs; and receiving application PDUs over the PDU session, with an SMD service applied by the network.

17. The method according to claim 16, wherein the SMD service applied by the network is a PDU set differentiated quality of service (QoS) service applied by the network.

18. The method according to claim 16 or 17, wherein the one or more SMD control messages are inserted into a user datagram protocol (UDP) option of the one or more user plane PDUs.

19. The method according to any of claims 16 to 18, wherein the one or more SMD control messages are received from one of: a session management function over a control plane; a user plane function over a user plane.

20. A wireless transmit-receive unit (WTRU) in a network, comprising at least one processor configured to: transmit a packet data unit (PDU) session establishment or PDU session update request message to the network, indicating a capability of the WTRU to relay secure metadata (SMD) control messages for the establishment of an SMD context;receive from the network, in response to the PDU session establishment or session update request message, one or more SMD control messages; insert the one or more SMD control messages in one or more user plane PDUs; and receive application PDUs over the PDU session, with an SMD service applied by the network.

21. The WTRU according to claim 20, wherein the SMD service applied by the network is a PDU set differentiated quality of service (QoS) service applied by the network.

22. The WTRU according to claim 20, wherein the at least one processor is configured to insert the one or more SMD control messages into a user datagram protocol (UDP) option of the one or more user plane PDUs.

23. The WTRU according to any of claims 20 to 22, wherein the at least one processor is configured to receive the one or more SMD control messages from one of: a session management function over a control plane; a user plane function over a user plane.

Images