Devices, methods, apparatuses, and media for negotiating payload information on a path

Abstract

Embodiments of this disclosure relate to apparatus, methods, devices, and media for negotiating information associated with payload information on a path using a capsule. In one aspect, a first device sends a first capsule to a second device, the first capsule including first information associated with payload information on a path, the first device being capable of receiving or sending the payload information on the path. The first device receives a second capsule from the second device, the second capsule including second information associated with the payload information on the path, the second device being to send or receive the payload information on the path, wherein the second information is determined based on the first information. By implementing embodiments of this disclosure, the first device and the second device can negotiate information associated with payload information on a path using a capsule, thus the first device and the second device will know the payload information on the path to be transmitted.

Description

Technical Field

[0001] Various example embodiments generally relate to the field of communications, and more specifically to devices, methods, apparatuses, and computer-readable storage media related to the negotiation of information relating to payload information along the path of using the capsule. Background Technology

[0002] A communication network can be viewed as a facility that enables communication between two or more communication devices, or provides communication devices with access to a data network. Mobile or wireless communication networks are an example of communication networks.

[0003] Such communication networks operate according to standards, such as those issued by 3GPP (3rd Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). Examples of such standards include the so-called 5G (fifth generation) standard or other standards issued by 3GPP. Summary of the Invention

[0004] Generally, exemplary embodiments of this disclosure provide devices, methods, apparatuses, and computer-readable storage media for communication, such as for negotiating information related to payload information along a path of using a capsule, and particularly for negotiating information related to media.

[0005] In a first aspect, a first device is provided. The first device may include at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first device to at least: send a first capsule to a second device, the first capsule including first information associated with payload information on a path, the first device supporting receiving or sending the payload information on the path; and receive a second capsule from the second device, the second capsule including second information associated with the payload information on the path, the second device to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0006] In some example embodiments of the first aspect, the payload information on the path includes: payload information received by the first device from or sent to the second device along with user plane traffic transmitted between the first device and the second device, and the payload information is used by the first device or the second device to support or influence the transmission of user plane traffic.

[0007] In some example embodiments of the first aspect, the first information includes at least one of the following: the first device supports receiving or sending one or more types of payload information on the path; the first device supports receiving or sending the content of the payload information on the path; or a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram, wherein the first device supports receiving or sending the HTTP datagram when receiving or sending the payload information on the path using a User Datagram Protocol (UDP) proxy.

[0008] In some example embodiments of the first aspect, the second information includes at least one of the following: one or more types of payload information on the path that the second device wants to send or receive; the content of the payload information on the path that the second device wants to send or receive; a context ID for an HTTP datagram that the second device wants to send or receive when sending or receiving the payload information on the path using a UDP proxy; or an indication that the first capsule is accepted, or that the second device will send or receive the payload information on the path based on the first information.

[0009] In some example embodiments of the first aspect, the first device is further configured to: determine first information associated with payload information on the path that the first device supports receiving or transmitting.

[0010] In some example embodiments of the first aspect, the first device is further configured to: be triggered to send path payload information to the second device or receive path payload information from the second device.

[0011] In some example embodiments of the first aspect, the first device is further configured to receive payload information on the path from the second device based on the second information.

[0012] In some example embodiments of the first aspect, the first device is further configured to: send path payload information to the second device based on the second information.

[0013] In some example embodiments of the first aspect, prior to sending the first capsule, the first device is further configured to: send a request message to a second device indicating support for the use of the capsule by the first device; and receive a response message from the second device indicating permission to use the capsule.

[0014] In some example embodiments of the first aspect, the request message is an HTTP connection request message, and the response message is an HTTP 200 OK response message.

[0015] In some example embodiments of the first aspect, the payload information on the path includes media-related information (MRI).

[0016] In some example embodiments of the first aspect, at least one of the following is true: one or more types of payload information on the path include at least one of the following: one or more formats of signaling on the path carrying the MRI; or one or more formats for encoding the MRI; the content of the payload information on the path includes one or more types of the MRI; and the context ID for the HTTP datagram includes a context ID value that will be used to send or receive the MRI.

[0017] In some example embodiments of the first aspect, one or more types of the MRI include at least one of the following: Protocol Data Unit (PDU) collection information; data burst end indication; expedited transmission indication; data burst size; or time to the next burst.

[0018] In some example embodiments of the first aspect, the first device is an HTTP client and the second device is a UDP proxy.

[0019] In some example embodiments of the first aspect, the HTTP client is a user plane function (UPF) and the UDP proxy is an application server (AS).

[0020] In some example embodiments of the first aspect, the payload information on the path is associated with end-to-end secure traffic between the AS and the terminal device.

[0021] In some example embodiments of the first aspect, the first device is further configured to send payload information on the path to a network device serving the terminal device.

[0022] In some example embodiments of the first aspect, the HTTP client is a terminal device, and the UDP proxy is a UPF.

[0023] In some example embodiments of the first aspect, the payload information on the path is associated with end-to-end secure traffic between the terminal device and the AS or another terminal device.

[0024] In a second aspect, a second device is provided. The second device may include: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second device to at least: receive a first capsule from a first device, the first capsule including first information associated with payload information on a path, the first device supporting receiving or transmitting the payload information on the path; and transmit a second capsule to the first device, the second capsule including second information associated with the payload information on the path, the second device intending to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0025] In some example embodiments of the second aspect, the payload information on the path includes: payload information received by the first device from or sent to the second device along with user plane traffic transmitted between the first device and the second device, and the payload information is used by the first device or the second device to support or influence the transmission of user plane traffic.

[0026] In some example embodiments of the second aspect, the first information includes at least one of the following: the first device supports receiving or sending one or more types of payload information on the path; the first device supports receiving or sending the content of the payload information on the path; or a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram, wherein the first device supports receiving or sending the HTTP datagram when receiving or sending the payload information on the path using a User Datagram Protocol (UDP) proxy.

[0027] In some example embodiments of the second aspect, the second information includes at least one of the following: one or more types of payload information on the path that the second device wants to send or receive; the content of the payload information on the path that the second device wants to send or receive; a context ID for an HTTP datagram that the second device wants to send or receive when sending or receiving the payload information on the path using a UDP proxy; or an indication that the first capsule is accepted, or that the second device will send or receive the payload information on the path based on the first information.

[0028] In some example embodiments of the second aspect, the second device is further configured to: determine, based on the first information, second information associated with the payload information on the path to be sent or received by the second device.

[0029] In some example embodiments of the second aspect, the second device is further configured to: send payload information on the path to the first device based on the second information.

[0030] In some example embodiments of the second aspect, the second device is further configured to receive payload information on the path from the first device based on the second information.

[0031] In some example embodiments of the second aspect, prior to receiving the first capsule, the first device is further configured to: receive a request message from the first device indicating support for the use of the capsule; and send a response message to the first device indicating permission to use the capsule.

[0032] In some example embodiments of the second aspect, the request message is an HTTP connection request message, and the response message is an HTTP 200 OK response message.

[0033] In some example embodiments of the second aspect, the payload information on this path includes media-related information (MRI).

[0034] In some example embodiments of the second aspect, at least one of the following: one or more types of payload information on the path include at least one of the following: one or more formats of signaling on the path carrying the MRI; or one or more formats for encoding the MRI; the content of the payload information on the path includes one or more types of the MRI; and the context ID for the HTTP datagram includes a context ID value that will be used to send or receive the MRI.

[0035] In some example embodiments of the second aspect, one or more types of the MRI include at least one of the following: Protocol Data Unit (PDU) collection information; data burst end indication; expedited transmission indication; data burst size; or time to the next burst.

[0036] In some example embodiments of the second aspect, the first device is an HTTP client and the second device is a UDP proxy.

[0037] In some example embodiments of the second aspect, the HTTP client is a user plane function (UPF), and the UDP proxy is an application server (AS).

[0038] In some example embodiments of the second aspect, the payload information on the path is associated with end-to-end secure traffic between the AS and the terminal device.

[0039] In some example embodiments of the second aspect, the HTTP client is a terminal device, and the UDP proxy is a UPF.

[0040] In some example embodiments of the second aspect, the payload information on the path is associated with the end-to-end secure traffic between the terminal device and the AS or another terminal device.

[0041] In some example embodiments of the second aspect, the second device is further configured to send payload information on the path to the network device serving the terminal device.

[0042] In a third aspect, a method is provided. The method may include: sending a first capsule to a second device, the first capsule including first information associated with path-based payload information, the first device supporting receiving or sending the path-based payload information; and receiving a second capsule from the second device, the second capsule including second information associated with the path-based payload information, the second device to send or receive the path-based payload information, wherein the second information is determined based on the first information.

[0043] In a fourth aspect, a method is provided. The method may include: receiving a first capsule from a first device, the first capsule including first information associated with payload information on a path, the first device supporting receiving or transmitting the payload information on the path; and transmitting a second capsule to the first device, the second capsule including second information associated with the payload information on the path, the second device being to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0044] In a fifth aspect, an apparatus is provided. The apparatus may include: components for transmitting a first capsule to a second device, the first capsule including first information associated with payload information on a path, the first device supporting receiving or transmitting the payload information on the path; and components for receiving a second capsule from the second device, the second capsule including second information associated with the payload information on a path, the second device to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0045] In a sixth aspect, an apparatus is provided. The apparatus may include: components for receiving a first capsule from a first device, the first capsule including first information associated with payload information on a path, the first device supporting the reception or transmission of the payload information on the path; and components for transmitting a second capsule to the first device, the second capsule including second information associated with the payload information on the path, the second device to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0046] In a seventh aspect, a non-transitory computer-readable medium is provided, including program instructions for causing the apparatus to perform at least the method according to a third or fourth aspect.

[0047] In an eighth aspect, a computer program is provided, including instructions that, when executed by a device, cause the device to at least: send a first capsule to a second device, the first capsule including first information associated with payload information on a path, the first device supporting receiving or sending the payload information on the path; and receive a second capsule from the second device, the second capsule including second information associated with the payload information on a path, the second device being to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0048] In a ninth aspect, a computer program is provided, including instructions that, when executed by a device, cause the device to at least: receive a first capsule from a first device, the first capsule including first information associated with payload information on a path, the first device supporting receiving or transmitting the payload information on the path; and send a second capsule to the first device, the second capsule including second information associated with the payload information on the path, the second device being to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0049] In a tenth aspect, a first device is provided. The first device may include: a transmitting circuit system configured to transmit a first capsule to a second device, the first capsule including first information associated with payload information on a path, the first device supporting receiving or transmitting the payload information on the path; and a receiving circuit system configured to receive a second capsule from the second device, the second capsule including second information associated with the payload information on a path, the second device to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0050] In an eleventh aspect, a second device is provided. The second device may include: a receiving circuitry configured to receive a first capsule from a first device, the first capsule including first information associated with payload information on a path, the first device supporting the reception or transmission of the payload information on the path; and a transmitting circuitry configured to transmit a second capsule to the first device, the second capsule including second information associated with the payload information on the path, the second device to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0051] It should be understood that the summary section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become apparent from the following description. Attached Figure Description

[0052] Some exemplary embodiments will now be described with reference to the accompanying drawings, in which:

[0053] Figure 1 Examples of application scenarios in which some exemplary embodiments of this disclosure can be implemented are shown;

[0054] Figure 2 Example signaling procedures for negotiating payload information on a path to be transmitted between a first device and a second device, according to some embodiments of this disclosure, are shown.

[0055] Figure 3Example signaling procedures are shown according to some embodiments of the present disclosure for negotiating payload information on the path to be sent from the application server (AS) to the user plane function (UPF);

[0056] Figure 4 Example signaling procedures for negotiating payload information on the path from a user equipment (UE) to a user plane function (UPF) are shown according to some embodiments of this disclosure;

[0057] Figure 5 Example signaling procedures are shown according to some embodiments of the present disclosure for negotiating the payload information that should be used for transmission of the capsule between the first device and the second device on the path;

[0058] Figure 6 Example signaling procedures are shown according to some embodiments of this disclosure for negotiating the payload information on the path that should be sent from the AS to the UPF using the capsule;

[0059] Figure 7 Example signaling procedures are shown according to some embodiments of this disclosure for negotiating the payload information on the path that should be sent from the UE to the UPF using the capsule;

[0060] Figure 8 A flowchart is shown illustrating an example method implemented at a first device according to some embodiments of the present disclosure;

[0061] Figure 9 A flowchart is shown illustrating an example method implemented at a second device according to some embodiments of the present disclosure;

[0062] Figure 10 A flowchart is shown illustrating an example method implemented at a first device according to some other embodiments of this disclosure;

[0063] Figure 11 A flowchart is shown illustrating an example method implemented at a second device according to some other embodiments of this disclosure;

[0064] Figure 12 Simplified example block diagrams of devices suitable for implementing embodiments of the present disclosure are shown; and

[0065] Figure 13 Example block diagrams of example computer-readable media according to some example embodiments of the present disclosure are shown.

[0066] In all the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0067] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only and to assist those skilled in the art in understanding and implementing this disclosure, and do not imply any limitation on the scope of this disclosure. The disclosure described herein can be implemented in various ways other than those described below.

[0068] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0069] In this disclosure, references to "an embodiment," "an embodiment," "an example embodiment," etc., indicate that the described embodiments may include specific features, structures, or characteristics, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, those skilled in the art will recognize that, whether explicitly described or not, incorporating other embodiments to affect such a feature, structure, or characteristic is within their knowledge.

[0070] It should be understood that although the terms “first,” “second,” “third,” etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0071] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising,” “including,” “having,” “having,” “including,” and / or “containing” are used herein, the presence of the stated features, elements, and / or components is specified, but the presence or addition of one or more other features, elements, components, and / or combinations thereof is not excluded. As used herein, “at least one of the following: ” and “at least one of ” and similar wording (where the list of two or more elements is connected by “and” or “or”) means at least any one of these elements, or at least any two or more of these elements, or at least all of these elements.

[0072] As used in this application, the term "circuit system" may refer to one or more or all of the following: (a) Hardware circuit implementation only (such as implementation only in analog and / or digital circuit systems); and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits having software / firmware, and (ii) Any part of a hardware processor(s) having software (including (multiple) digital signal processors, software, and (multiple) memories, which work together to enable a device (such as a mobile phone or server) to perform various functions); and (c) (multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may be absent when operation is not required.

[0073] This definition of circuit system applies to all uses of the term in this application (including in any claim). As another example, as used in this application, the term circuit system also covers only hardware circuitry or a processor (or multiple processors) or portions of hardware circuitry or a processor and its accompanying software and / or firmware implementation. For example, and if applicable to a particular claim element, the term circuit system also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices or other computing or network devices.

[0074] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in the communication network can be performed according to any suitable intergenerational communication protocol, including but not limited to third-generation (3G), fourth-generation (4G), 4.5G, fifth-generation (5G), sixth-generation (6G), and / or higher. Embodiments of this disclosure can be applied to various communication systems. Due to the rapid development of communication, there will naturally be future types of communication technologies and systems that can be utilized to implement this disclosure. The scope of this disclosure should not be considered limited to the systems described above.

[0075] As used herein, the term "network device" refers to a node in a communications network through which terminal devices access the network and receive services. Depending on the terminology and technology applied, a network device can refer to a base station (BS) or access point (AP), such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR NB (also known as a gNB), a Transmitter Receiver Point (TRP), a Remote Radio Unit (RRU), a Radio Header (RH), a Remote Radio Header End (RRH), a relay, a low-power node (such as a femtosecond or picosecond), an Integrated Access and Backhaul (IAB) node, a Non-Terrestrial Network (NTN) or Non-Terrestrial Network Equipment (such as satellite network equipment, Low Earth Orbit (LEO) satellites, and Geosynchronous Orbit (GEO) satellites), airborne network equipment, and so on. In some example embodiments, the Radio Access Network (RAN) separation architecture includes a centralized unit (CU) and a distributed unit (DU) at the IAB donor node. The IAB node consists of the mobile termination (IAB-MT) portion (which behaves similarly to a UE moving toward a parent node) and the DU portion of the IAB node (which behaves similarly to a base station moving toward a next-hop IAB node).

[0076] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not a limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Terminal devices may include, but are not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop devices (LMEs), USB dongles, smart devices, wireless customer premises equipment (CPEs), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronic devices, commercially operating devices, relays, integrated access and backhaul (IAB) nodes, and / or industrial wireless networks, etc. In the following description, the terms "terminal device," "communication device," "terminal," "user equipment," and "UE" are used interchangeably.

[0077] As used herein, “resource,” “transmission resource,” “resource block,” “physical resource block” (PRB), “uplink (UL) resource,” or “downlink (DL) resource” can refer to any resource used to perform communication, such as communication between a terminal device and a network device, including time-domain resources, frequency-domain resources, spatial-domain resources, code-domain resources, combined resources of more than one domain, or any other resource that enables communication. In the following, time-domain resources (such as subframes) will be used as examples of transmission resources used to describe some exemplary embodiments of this disclosure. Note that the exemplary embodiments of this disclosure are equally applicable to other resources in other domains.

[0078] In communications technology, to support Extended Reality (XR) services, the 3rd Generation Partnership Project (3GPP) requires Application Servers (AS) to provide path payload information (e.g., Media Related Information (MRI)) to User Plane Functions (UPF). The UPF can then provide this path payload information to the Next Generation Radio Access Network (NG-RAN), enabling the NG-RAN to support XR services with optimal / efficient resource utilization and scheduling. Agreement is reached to support XR services for end-to-end (e2e) secure traffic, and when using e2e secure traffic, path payload information is transmitted from the AS to the UPF / UE, from the UE to the AS / UPF, from the UE to the UPF, or from the UE to another UE. Therefore, how the devices used to transmit path payload information negotiate the information associated with the path payload information to be transmitted (e.g., for the type, content, or context identifier (ID) of the datagram) needs to be discussed.

[0079] In this disclosure, certain example embodiments provide methods and / or apparatus for negotiating payload information on a path transmitted between a first device and a second device. Based on these embodiments, a first device (e.g., a UE or UPF) sends a request message to a second device (e.g., a UPF or AS) including first information associated with the payload information on the path, the first device supporting the reception or transmission of the payload information on the path. The first device receives a response message from the second device, the response message including second information associated with the payload information on the path, the second device then sending or receiving the payload information on the path. The second information is determined based on the first information.

[0080] It should be understood that the above process steps can work together, or partially together or independently of each other, in accordance with the following operational flow. By implementing these embodiments of the present disclosure, the first device (e.g., UE or UPF) and the second device (e.g., UPF or AS) can negotiate information associated with the payload information on the path, so that both the first device and the second device will know the payload information on the path to be transmitted.

[0081] Furthermore, some other example embodiments of this disclosure provide methods and / or apparatus for negotiating payload information on a path transmitted between a first device and a second device using capsules. According to these embodiments of this disclosure, a first device (e.g., a UE or UPF) sends a first capsule to a second device (e.g., a UPF or AS), the first capsule including first information associated with payload information on the path, the first device supporting the reception or transmission of the payload information on the path. The first device receives a second capsule from the second device, the second capsule including second information associated with the payload information on the path, the second device transmitting or receiving the payload information on the path. The second information is determined based on the first information.

[0082] It should be understood that the above process steps can work together, or partially together or independently of each other, in accordance with the following operational flow. By implementing these embodiments of the present disclosure, a first device (e.g., UE or UPF) and a second device (e.g., UPF or AS) can use capsule negotiation to associate information with payload information on the path, so that both the first device and the second device will know the payload information on the path to be transmitted.

[0083] For ease of explanation, the principles and exemplary embodiments of this disclosure regarding the negotiation of information associated with payload information on the path will be described in the following references. Figures 1 to 13 The embodiments described herein are intended to enable those skilled in the art to understand the inventive concept of this disclosure and to implement the solutions presented herein, and are not intended to limit the scope of this application in any way.

[0084] Figure 1 Examples of application scenarios 100 in which some exemplary embodiments of this disclosure may be implemented are shown. Communication system 100 may be part of a communication network, including terminal device 102-1, User Plane Function (UPF) 104, Application Server (AS) 106, and / or terminal device 102-2. For example... Figure 1As shown, terminal devices 102-1 / 102-2 can also be referred to as user equipment 102-1 / 102-2 or UE 102-1 / 102-2. UPF 104 can be referred to as network device 104. AS 106 can also be referred to as network device 106. Path-related payload information (e.g., media-related information) can be transmitted between terminal devices 102-1 and UPF 104, between UPF 104 and AS 106, or between terminal devices 102-1 and terminal devices 102-2. Path-related payload information can refer to payload information transmitted along the path between these devices. Alternatively or additionally, path-related payload information may include non-media-related information, such as information for Quality of Service (QoS) processing; therefore, information targeting more than payload information (user plane traffic, e.g., e2e secure traffic) can be transmitted together. User plane traffic (e.g., e2e secure traffic) can also be transmitted between terminal device 102-1 and UPF 104, between UPF 104 and AS 106, or between terminal device 102-1 and terminal device 102-2. Path payload information and user plane traffic can be transmitted together, for example, within a Hypertext Transfer Protocol (HTTP) datagram or a Fast User Datagram Protocol (UDP) Internet Connection (QUIC) datagram, and the path payload information can be used to support or influence the transmission of user plane traffic. For example, UPF 104 can establish an HTTP connection to AS 106, and AS 106 can send downlink (DL) traffic to UPF 104 in an HTTP datagram, which includes e2e protected traffic and path payload information for use by UPF 104. In another example, UPF 104 can establish an HTTP connection to AS 106, and AS106 can send downlink (DL) traffic to UPF 104 in a QUIC datagram, which includes e2e protected traffic and payload information on the path used by UPF 104.

[0085] In communication system 100, the link from AS 106 or UPF 104 to terminal device 102-1 is called the downlink (DL), while the link from terminal device 102-1 to AS 106 or UPF 104 is called the uplink (UL). In the downlink, AS 106 or UPF 104 is a transmitting (TX) device (or transmitter), and terminal device 102-1 is a receiving (RX) device (or receiver). In the uplink, terminal device 102-1 is a transmitting (TX) device (or transmitter), and AS 106 or UPF 104 is a receiving (RX) device (or receiver).

[0086] The communication in communication system 100 can conform to any applicable standard, including but not limited to: Long Term Evolution (LTE), LTE-Evolution, LTE-A Advanced, Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), Wi-Fi, etc. Furthermore, communication can be performed according to any generation of communication protocol, whether currently known or to be developed in the future. Examples of communication protocols include, but are not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G), 5.5G, advanced 5G networks, sixth generation (6G), or the IEEE 802.11 communication protocol. The communication network can support non-3GPP access to the 3GPP core network, such as core networks provided by wired access, untrusted non-3GPP access networks, trusted non-3GPP access networks using radio access gateway functions (W-AGF), non-3GPP interoperability functions (N3IWF or evolved packet data gateway (ePDG)) or trusted non-3GPP gateway functions (TNGF) to connect to the core network of mobile or cellular networks (e.g., 5G core network (5GC) or 6G core network (6GC)).

[0087] It should be understood that Figure 1 The number of devices, their connections, and types shown are for illustrative purposes only and do not imply any limitation. Communication system 100 may include any number of devices suitable for implementing embodiments of this disclosure.

[0088] Figure 2 Example signaling procedures 200 according to some embodiments of the present disclosure for negotiating payload information on a path to be transmitted between a first device 202 and a second device 204 are illustrated. The first device 202 may refer to... Figure 1 The terminal device 102-1 or UPF 104, and the second device 204 may refer to Figure 1 The UPF is 104 or AS is 106.

[0089] At 210, the first device 202 can send a request message to the second device 204, the request message including first information associated with the payload information on the path, the first device 202 supporting receiving or sending the payload information on the path. Simultaneously, in the opposite direction, the second device 204 can receive a request message from the first device 202, the request message including the first information associated with the payload information on the path, the first device 202 supporting receiving or sending the payload information on the path. The word "support" can also be understood as "accept" or "willing" to receive or send. Alternatively or additionally, the word "support" can also be understood as "accept" or "willing" to receive or send via a UDP tunnel or HTTP connection established with the second entity. At 220, the first device 202 can receive a response message from the second device 204, the response message including second information associated with the payload information on the path, the second device 204 sending or receiving the payload information on the path. Simultaneously, in the opposite direction, the second device 204 can send a response message to the first device 202, which includes second information associated with path payload information, which the second device 204 will send or receive. The second information is determined based on the first information. The path payload information may include: path payload information received by the first device 202 from or sent to the second device 204 along with user plane traffic transmitted between the first device 202 and the second device 204, and the payload information is used by the first device 202 or the second device 204 to support or influence the transmission of user plane traffic. The path payload information may include media-related information (MRI). In this way, the first device 202 and the second device 204 can negotiate information associated with the path payload information (e.g., MRI), so that the first device 202 and the second device 204 will know the path payload information to be transmitted.

[0090] In some example embodiments, the first information may include one or more types of path-on payload information that the first device 202 supports receiving or transmitting. The one or more types of path-on payload information may include one or more formats / versions of path-on signaling carrying path-on payload information (e.g., MRI); and / or one or more formats / versions for encoding path-on payload information (e.g., MRI). Alternatively or additionally, the first information may include the content of path-on payload information that the first device 202 supports receiving or transmitting. The content of the path-on payload information includes one or more types of MRI. Alternatively or additionally, the first information may include a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram that the first device 202 receives or transmits when receiving or transmitting the path-on payload information using a User Datagram Protocol (UDP) proxy. The context ID provides an overview of the HTTP datagram payload. The context ID for the HTTP datagram may include a context ID value to be used for sending or receiving MRI. In this way, the second device 204 will know the type, content, and / or context ID of the payload information on the path that the first device 202 supports receiving or sending, so the second device 204 can determine the payload information on the path that the second device 204 will send to or receive from the first device 202.

[0091] In some example embodiments, the second information may include one or more types of on-path payload information that the second device 204 will receive or send. The one or more types of on-path payload information may include on-path signaling in one or more formats / versions carrying on-path payload information (e.g., MRI); and / or one or more formats / versions for encoding the on-path payload information (e.g., MRI). Alternatively or additionally, the second information may include the content of the on-path payload information that the second device 204 will send or receive. The content of the on-path payload information includes one or more types of MRI. Alternatively or additionally, the second information may include a context ID for an HTTP datagram used by the second device 204 when receiving or sending the on-path payload information using a UDP proxy that the second device will send or receive. The context ID for the HTTP datagram may include a context ID value to be used for sending or receiving MRI. Alternatively or additionally, the second information may include an indication that a request message was successful or that the second device 204 will send or receive on-path payload information based on the first information. For example, upon receiving an instruction, the first device 202 can know the path payload information that the second device 204 will send or receive, corresponding to the type, content, or context ID indicated in the first information. In this way, the first device 202 will know the type, content, and / or context ID of the path payload information that the second device 204 will send or receive, therefore the transmitter will not send path payload information that the receiver cannot understand, and the receiver will know which path payload information it will receive from the transmitter. Furthermore, if the response message contains an indication that the request message was successful, or that the second device 204 will send or receive path payload information based on the first information, the first device 202 will know the path payload information that the second device 204 will send or receive, even if the response message does not contain the type, content, or context ID.

[0092] In some example embodiments, the first and second information may be associated with an MRI signaled within a General Media-Related Information (GMRI) container. One or more formats of signaling along the path carrying the MRI, or one or more formats used to encode the MRI, may include one or more versions of the GMRI container. One or more types of the MRI include at least one of the following: Protocol Data Unit (PDU) set information; data burst end indication; expedited delivery indication; data burst size; or time to the next burst. Note that the types of MRI listed herein are for illustrative purposes only and are not intended to limit the scope of this application. The types of MRI may expand as the technology develops.

[0093] In some example embodiments, the first device 202 may determine first information associated with the first device 202 supporting the reception or transmission of payload information on the path. For example, the first device 202 may determine multiple types, multiple contents, and / or context IDs for the payload information on the path it supports receiving or transmitting.

[0094] In some example embodiments, the first device 202 may be triggered to send or receive path payload information to or from the second device 204. For example, after receiving a UL user plane packet or deciding to send a UL end-to-end encrypted packet, or by a Session Management Function (SMF) instruction, the first device 202 may be triggered to send or receive path payload information from the second device 204. For example, after receiving a DL user plane packet or deciding to send a UL end-to-end encrypted packet, or by a Session Management Function (SMF) instruction, the second device 204 may be triggered to send path payload information to the first device 202, thereby triggering the first device 202 to receive path payload information from the second device 204.

[0095] In some example embodiments, the second device 204 may determine second information associated with payload information on a path to be sent or received by the second device 204 based on the first information. For example, the second device 204 may determine the type, content, and / or context ID of the payload information on a path to be sent or received by the second device 204 based on the type, content, and / or context ID contained in the first information. Alternatively or additionally, the second device 204 may determine to send or receive payload information on a path corresponding to the type, content, or context ID indicated in the first information; in this case, the second device 204 may determine, based on the first information, that the first capsule has been accepted or that the second device 204 intends to send or receive payload information on a path as the second information.

[0096] In some example embodiments, the first device 202 may be an HTTP client, and the second device 204 may be a UDP proxy. For example, the HTTP client may be a User Plane Function (UPF), and the UDP proxy may be an Application Server (AS) or a proxy that allows access to an Application Server (AS). In this case, path-on payload information may be associated with end-to-end secure traffic between the AS and the end device. The first device 202 may send information derived from the path-on payload information to the network device (e.g., NG-RAN) serving the end device. In another example, the HTTP client may be the end device, and the UDP proxy may be a UPF. In this case, path-on payload information may be associated with end-to-end secure traffic between the end device and the AS or other end devices.

[0097] In some example embodiments, the request message may be an HTTP connection request message, and the response message may be an HTTP 200 OK response message. First information may be carried in a first HTTP header in the HTTP connection request, and second information may be carried in a second HTTP header in the HTTP 200 OK response message. The first HTTP header may list the content that the first device 202 supports sending to the second device 204 and / or the content that the first device 202 is willing to receive from the second device 204. The second HTTP header may list the content that the second device 204 determines to send to the first device 202 and / or the content that the second device 204 is willing to receive from the first device 202. The first and second information may be applicable to a Generic Media Related Information (GMRI) container carrying path payload information, and the types of supported path payload information that can be encoded within the GMRI container. For UDP proxy or UDP option mechanisms, the first HTTP header may be a new header in the HTTP connection request message, and the second HTTP header may be a new header in the HTTP 200 OK response message. For a Quick UDP Internet Connection (QUIC) aware proxy mechanism, the first HTTP header can be a "proxy-quic-forward" header or another new header in the HTTP connection request message, and the second HTTP header can be a "proxy-quic-forward" header or another new header in the HTTP 200 OK response message.

[0098] In some example embodiments, after the HTTP connection request message and the HTTP 200 OK response message, an HTTP connection can be established, and the first device 202 can send path payload information to the second device 204 based on the second information. Simultaneously, in the opposite direction, the second device 204 can receive path payload information from the first device 202 based on the second information. Alternatively or additionally, the second device 204 can send path payload information to the first device 202 based on the second information. Simultaneously, in the opposite direction, the first device 202 can receive path payload information from the second device 204 based on the second information.

[0099] Figure 3 Example signaling procedures 300 are shown according to some embodiments of the present disclosure for negotiating payload information on the path that should be sent from application server (AS) 306 to user plane function (UPF) 304. Figure 3 It may also include UE 302. UE 302 can refer to Figure 1 Terminal device 102-1, UPF 304 in the text can refer to Figure 1 UPF 104 or Figure 2 The first device 202, and AS 306 may refer to Figure 1 AS 106 or Figure 2 The second device 204. Figure 3 In this context, UPF 304 can indicate an HTTP client, and AS 306 can indicate a UDP proxy.

[0100] At 305, UE 302 sends a UL traffic plane packet to UPF 304. After receiving the UL traffic plane packet, and / or after the SMF with the AS agent address instructs to establish an HTTP connection to AS 306 (or the AS agent) using a UDP connection before or during the receipt of the first UL traffic plane packet from UE 302, UPF 304 will need to establish an HTTP connection to AS 606.

[0101] At 310, UPF 304 determines the MRI (and / or other path payload information) it supports receiving and / or transmitting in (multiple) formats / (multiple) versions and / or (multiple) contents. The MRI format / version may be a GMRI container format / version. The MRI content may include, for example, Protocol Data Unit (PDU) set information, burst end indication, expedited delivery indication, burst size, or time to the next burst. If a UDP proxy is used (including the alternative of using the UDP option to carry path payload information), UPF 304 can determine the context ID to be used to receive the path payload information. UPF 304 can determine that it needs to receive the path payload information from AS 306 carrying the MRI. The (multiple) formats / (multiple) versions need to be negotiated between UPF 304 and AS 306 because UPF 304 and AS 306 may support different versions, or AS 306 may not support all versions supported by UPF 304. For example, UPF 304 may only support version 1, while AS306 may support both version 1 and version 2.

[0102] At 320, UPF 304 sends an HTTP connection request to AS 306. This HTTP connection request includes headers indicating payload information on the paths it supports for receiving from and / or sending to AS 306. For example, the headers may indicate the GMRI container(s) format / (s) version and / or specific type of MRI it supports for receiving (e.g., PDU set information, burst end indication, expedited delivery indication, burst size, or time to next burst). As another example, the headers may indicate the GMRI container(s) format / (s) version and / or specific type of MRI it supports for sending (e.g., throughput recommendation). If a UDP proxy is used, the headers may indicate the context ID that will be used to transmit signaling information on the transmission path. As an example, the header could be: proxy-to-client-datagram-payloads = ?1; payloads = [3gpp-gmri-udp-v1: {pduset, ttnb, edt}, 3gpp-gmri-udp-v2, 3gpp-gmri-udp-v3]; context-id = 2. This means that UPF 304 supports receiving GMRI container versions including 3gpp-gmri-udp-v1, 3gpp-gmri-udp-v2, and 3gpp-gmri-udp-v3. Specific types of MRI that UPF 304 supports receiving include PDU set information, time to the next burst, and data burst end indication. Furthermore, if a UDP proxy is used, the context ID used for signaling information on the transmission path will be "2". 3gpp-gmri-udp-v1, 3gpp-gmri-udp-v2, and 3gpp-gmri-udp-v3 can be listed in preferred order. Alternatively, or otherwise, {pduset,ttnb,edt} can be replaced with their corresponding type values.

[0103] At 330, AS 306 determines, based on the received information, the path-on signaling it needs to send from AS 306 carrying the MRI, and determines the MRI (and / or other path-on payload information) it needs to send and / or expect to receive in (multiple) formats / (multiple) versions and / or (multiple) contents. If a UDP proxy is used and no context ID is received in the HTTP connection request, AS 306 can determine the context ID that will be used to send the path-on payload information.

[0104] At 340, AS 306 may send a 200 OK response to UPF 304. This 200 OK response includes a header indicating information about the payload information on the path that AS 306 will send to UPF 304 and / or expect to receive from UPF 304. For example, the header may indicate the format / version and / or specific type of the GMRI container(s) of the MRI that AS 306 will send (e.g., PDU set information, burst end indication, accelerated delivery indication, burst size, or time to the next burst). As another example, the header may indicate the format / version and / or specific type of the GMRI container(s) of the MRI that it expects to receive (e.g., throughput recommendation). If a UDP proxy is used, the header may indicate the context ID that will be used to transmit signaling information on the path. An HTTP connection may be established after the HTTP connection request and the 200 OK response. As an example, the header could be: proxy-to-client-datagram-payloads=?1;payloads=[3gpp-gmri-udp-v1:{pduset,ttnb}];context-id=2. This means that AS 306 will send a GMRI container version including 3gpp-gmri-udp-v1, and the specific type of MRI that AS 306 will send includes PDU set information and the time to the next burst. If a UDP proxy is used, the context ID used for signaling information on the transmission path will be "2". Alternatively or additionally, the 200 OK response may also include an indication that the HTTP connection request was successful, or that AS 306 will send the MRI based on the information in the HTTP connection request header.

[0105] At 350, AS 306 sends UDP datagrams to UPF 304. The UDP datagrams may include end-to-end (e2e) secure DL user plane packets. The UDP datagrams may also include an MRI based on the format(s), content(s), and / or context ID indicated in 340. Upon receiving the UDP datagrams, UPF 304 may send these UDP datagrams to UE 302 and use the MRI to control the Quality of Service (QoS) to be provided for delivering end-to-end (e2e) secure DL user plane packets to UE 302 via the access network serving UE 302 (e.g., RAN or non-3GPP access network). This may include using the received MRI to populate the tunneling protocol (such as GPRS Tunneling Protocol-User Plane (GTP-u)) used to deliver end-to-end (e2e) secure DL user plane packets to the access network.

[0106] For QUIC-aware proxy mechanisms, the headers in HTTP connection requests and 200 OK responses can be proxy-quic-forwarding headers. For example, the header in an HTTP connection request could be: Proxy-quic-forwarding=?1; accept-transforms=3gpp-gmri-udp-v1:{pduset,ttnb,edt}; support-transforms=3gpp-ue-info-1,3gpp-ue-info-2. The header in a 200 OK response could be: Proxy-quic-forwarding=?1; support-transforms=3gpp-gmri-udp-v1: {pduset,ttnb}; accept-transforms=3gpp-ue-info-2. The accept-transforms header parameter on each side indicates what they are willing to receive from the other side, while the support-transforms header parameter on each side indicates what they are willing to send.

[0107] By implementing reference Figure 3 In these embodiments, UPF 304 (i.e., the HTTP client) and AS 306 (i.e., the UDP proxy) can negotiate information associated with the payload information on the path, so that UPF 304 and AS 306 will know the payload information on the path to be transmitted and transmit the payload information on the path as negotiated.

[0108] Figure 4 Example signaling procedures 400 are shown according to some embodiments of the present disclosure for negotiating payload information on the path that should be sent from user equipment (UE) 402 to user plane function (UPF) 404. Figure 4 It may also include AS 406. UE402 may refer to Figure 1 Terminal device 102-1 or Figure 2 The first device 202, UPF 404 in the text can refer to Figure 1 UPF104 or Figure 2 The second device 204 in the context, and AS 406 may refer to Figure 1 AS 106 in. Figure 4 In this context, UE 402 can be an HTTP client, and UPF4 04 can be a UDP proxy.

[0109] UE 402 can generate path payload information (e.g., MRI) on the UL path pointing to UPF 404. This path payload information will be used by UPF 404 to support optimizations for the delivery of media traffic (XRM) when forwarded to another UE 402 (e.g., PDU set processing). The uplink MRI from UE 402 to UPF 404 can support downlink services for remote UEs. If UE 402 is located on a different UPF, the remote UE can benefit from receiving path payload information via an intermediate UPF 404 or an intermediate AS 406.

[0110] At 410, UE 402 may determine the MRI (and / or other path payload information) formats / versions and / or content that it supports for transmission and / or expects to receive. The MRI format / version may be a GMRI container format / version. The MRI content may include, for example, Protocol Data Unit (PDU) set information, data burst end indication, expedited delivery indication, data burst size, or time to the next burst. UE 402 expects to receive, for example, throughput recommendation information to inform the network how much throughput of the UL media stream that UE 402 wants to send to the network is acceptable. If a UDP proxy is used (including using the alternative of using the UDP option to carry path payload information), UE 402 may determine the context ID to be used to transmit the path payload information. UE 402 may determine that it needs to transmit the path payload information to UPF 404.

[0111] At 420, UE 402 sends an HTTP connection request to UPF 404. This HTTP connection request includes a header indicating information about payload information on the path it supports sending to and / or expects to support receiving from UPF 404. For example, the header may indicate the GMRI container(s) format / (s) version and / or specific type of MRI it supports sending (e.g., PDU set information, data burst end indication, expedited delivery indication, data burst size, or time to the next burst). As another example, the header may indicate the GMRI container(s) format / (s) version and / or specific type of MRI it expects to receive (e.g., throughput recommendation). If a UDP proxy is used, the header may indicate the context ID that will be used to transmit signaling information on the path. As an example, the header could be: `client-to-proxy-datagram-payloads=?1;payloads=[3gpp-gmri-udp-v1:{pduset,ttnb,edt},3gpp-gmri-udp-v2]`. This means that UE 402 supports transmitting GMRI container versions including 3gpp-gmri-udp-v1 and 3gpp-gmri-udp-v2. Specific types of MRI transmitted by UE 402 include PDU set information, time to the next burst, and data burst end indication. 3gpp-gmri-udp-v1 and 3gpp-gmri-udp-v2 can be listed in preferred order. Alternatively, or additionally, `{pduset,ttnb,edt}` can be replaced with its corresponding type value. Alternatively or otherwise, the header may include a context ID value (e.g., “context-id=1” or “gmri-context-id=1”) that indicates that if a UDP proxy is used, UE 402 may be used to send signaling information on that path.

[0112] At 430, UPF 404 determines, based on the received information, that it will receive path signaling from UE 402, and determines the MRI (and / or other path payload information) it expects to receive from UE 402 and / or the MRI (and / or other path payload information) in (multiple) formats / (multiple) versions and / or (multiple) contents it will send to UE 402. If a UDP proxy is used and no context ID is received in the HTTP connection request, AS 406 can determine the context ID that will be used by UE 402 to send path payload information.

[0113] At 440, UPF 404 may send a 200 OK response to UE 402. This 200 OK response includes a header indicating information about the payload information on the path that UPF 404 expects to receive from and / or send to UE 402. For example, the header may indicate the GMRI container(s) format / (s) version and / or specific type (e.g., PDU set information, data burst end indication, expedited delivery indication, data burst size, or time to the next burst) of the MRI that UPF 404 expects to receive from UE 402. As another example, the header may indicate the GMRI container(s) format / (s) version and / or specific type (e.g., throughput recommendation) of the MRI that it will send to UE 402. If a UDP proxy is used, the header may also indicate the context ID that will be used for signaling information on the path sent by UE 402. An HTTP connection may be established after the HTTP connection request and the 200 OK response. For example, the header information could be: client-to-proxy-datagram-payloads=?1;payloads=[3gpp-gmri-udp-v1:{pduset}];context-id=1. This means that UPF 404 expects the GMRI container version received from UE 402 to include 3gpp-gmri-udp-v1, the specific type of MRI that UPF 404 expects to receive from UE 402 to include PDU set information, and if a UDP proxy is used, the context ID used for signaling information on the path sent by UE 402 will be "1". Alternatively or additionally, a 200 OK response could include an indication that the HTTP connection request was successful, or that UPF 404 expects to receive the MRI based on the information in the HTTP connection request header.

[0114] At 450, UE 402 sends UDP datagrams to UPF 404. These UDP datagrams may include end-to-end (e2e) secure UL user plane packets. These UDP datagrams may also include MRI based on the format(s), content(s), and / or context ID indicated in 450. After receiving the UDP datagrams, UPF 404 may send these UDP datagrams to AS 406.

[0115] For QUIC-aware proxy mechanisms, the HTTP connection request and 200 OK response headers can include the `proxy-quic-forwarding` header. As an example, the HTTP connection request header could be: `Proxy-quic-forwarding=?1;accept-transforms=3gpp-gmri-udp-v1:{pduset,ttnb,edt};support-transforms=3gpp-ue-info-1,3gpp-ue-info-2`. The 200 OK response header could be: `Proxy-quic-forwarding=?1;support-transforms=3gpp-gmri-udp-v1: {pduset,ttnb};accept-transforms=3gpp-ue-info-2`. The `accept-transforms` header parameter on each side indicates what they are willing to receive from the other side, while the `supported-transforms` header parameter on each side indicates what they are willing to send.

[0116] By implementing reference Figure 4 In these embodiments, UE 402 (i.e., the HTTP client) and UPF 404 (i.e., the UDP proxy) can negotiate information associated with the payload information on the path, so UE 402 and UPF 404 will know the payload information on the path to be transmitted and transmit the payload information on the path as negotiated.

[0117] Figure 5 Example signaling procedure 500 according to some embodiments of this disclosure is illustrated for negotiating how payload information should be transmitted on a path using a capsule between a first device 502 and a second device 504. The first device 502 may refer to... Figure 1 The terminal device 102-1 or UPF 104, and the second device 504 may refer to Figure 1 The UPF is 104 or AS is 106.

[0118] At point 510, the first device 502 can send a first capsule to the second device 504, the first capsule including first information associated with payload information on the path, and the first device 502 supports receiving or sending the payload information on the path. Simultaneously, in the opposite direction, the second device 504 can receive a first capsule from the first device 502, the first capsule including first information associated with payload information on the path, and the first device 502 supports receiving or sending the payload information on the path. The word "support" can also be understood as "accept" or "willing" to receive or send. Alternatively or additionally, the word "support" can also be understood as "accept" or "willing" to receive or send via a UDP tunnel or HTTP connection established with the second entity. At point 520, the first device 502 can receive a second capsule from the second device 504, the second capsule including second information associated with payload information on the path, and the second device 504 will send or receive the payload information on the path. Simultaneously, in the opposite direction, the second device 504 can send a second capsule to the first device 502. This second capsule includes second information associated with path-on-payload information, which the second device 504 will send or receive. The second information is determined based on the first information. The path-on-payload information may include: path-on-payload information received by the first device 502 from or sent to the second device 504 along with user plane traffic transmitted between the first device 502 and the second device 504, and used by either the first or second device 502 to support or influence the transmission of said user plane traffic. The path-on-payload information may include media-related information (MRI). In this way, the first device 502 and the second device 504 can use the capsule to negotiate information associated with the path-on-payload information (e.g., MRI), thus knowing the path-on-payload information to be transmitted.

[0119] In some example embodiments, the first information includes one or more types of path-on payload information that the first device 502 supports receiving or transmitting. The one or more types of path-on payload information may include path-on signaling (e.g., MRI) carrying one or more formats / versions of path-on payload information; and / or one or more formats / versions for encoding the path-on payload information (e.g., MRI). Alternatively or additionally, the first information may include the content of path-on payload information that the first device 502 supports receiving or transmitting. The content of the path-on payload information includes one or more types of MRI. Alternatively or additionally, the first information may include a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram that the first device 502 receives or transmits when receiving or transmitting the path-on payload information using a User Datagram Protocol (UDP) proxy. The context ID provides an overview of the HTTP datagram payload. The context ID for the HTTP datagram may include a context ID value to be used for sending or receiving MRI. In this way, the second device 504 will know the type, content, and / or context ID of the payload information on the path that the first device 502 supports receiving or sending via the capsule, and thus the second device 504 can determine the payload information on the path that the second device 504 will send to or receive from the first device 502.

[0120] In some example embodiments, the second information may include one or more types of on-path payload information that the second device will receive or transmit. The one or more types of on-path payload information may include on-path signaling (e.g., MRI) carrying one or more formats / versions of on-path payload information; and / or one or more formats / versions for encoding the on-path payload information (e.g., MRI). Alternatively or additionally, the second information may include the content of the on-path payload information that the second device 504 will transmit or receive. The content of the on-path payload information includes one or more types of MRI. Alternatively or additionally, the second information may include a context ID for an HTTP datagram that the second device 504 will transmit or receive when receiving or transmitting the on-path payload information using a UDP proxy. The context ID for the HTTP datagram may include a context ID value to be used for transmitting or receiving MRI. Alternatively or additionally, the second information may include an indication that the first capsule has been accepted or that the second device 504 will transmit or receive on-path payload information based on the first information. For example, upon receiving an instruction, the first device 502 can know the path payload information that the second device 504 intends to send or receive, corresponding to the type, content, or context ID indicated in the first information. In this way, the first device 502 will know the type, content, and / or context ID of the path payload information that the second device 504 will send or receive, thus the transmitter will not send path payload information that the receiver cannot understand, and the receiver will know which path payload information it will receive from the transmitter. Furthermore, if there is an indication in the second capsule that the first capsule has been accepted, or that the second device 504 will send or receive path payload information based on the first information, the first device 502 will know the path payload information that the second device 504 will send or receive, even if the second capsule does not contain the type, content, or context ID.

[0121] In some example embodiments, the first and second information may be associated with an MRI, which is signaled within a General Media-Related Information (GMRI) container. One or more signaling formats along the path carrying the MRI, or one or more formats used to encode the MRI, may include one or more versions of the GMRI container. One or more types of the MRI include at least one of the following: Protocol Data Unit (PDU) set information; data burst end indication; expedited delivery indication; data burst size; or time to the next burst. Note that the types of MRI listed herein are for illustrative purposes only and are not intended to limit the scope of this application. The types of MRI may expand as technology develops.

[0122] In some example embodiments, the first capsule may be a REQUEST_MRI_ContextID_Version capsule, which may have the following format:

[0123] In some example embodiments, the second capsule may be a Response_MRIContextID_Version capsule, which may have the following format:

[0124] In some example embodiments, the first device 502 may determine first information associated with payload information on a path, the first device 502 supporting the reception or transmission of the payload information on that path. For example, the first device 502 may determine multiple types, multiple contents, and / or context IDs for the payload information on the path that it supports receiving or transmitting.

[0125] In some example embodiments, the first device 502 may be triggered to send or receive path payload information to or from the second device 504. For example, upon receiving a UL user plane packet or deciding to send a UL end-to-end encrypted packet, or by a Session Management Function (SMF) instruction, the first device 502 may be triggered to send or receive path payload information from the second device 504. For example, upon receiving a DL user plane packet or deciding to send a UL end-to-end encrypted packet, or by a Session Management Function (SMF) instruction, the second device 504 may be triggered to send path payload information to the first device 502, and thus the first device 502 may be triggered to receive path payload information from the second device 504.

[0126] In some example embodiments, the second device 504 may determine second information associated with the payload information on the path, which the second device 504 intends to send or receive, based on the first information. For example, the second device 504 may determine the type, content, and / or context ID of the payload information on the path that the second device 504 intends to send or receive based on the type, content, and / or context ID contained in the first information. Alternatively or additionally, the second device 504 may determine to send or receive payload information on the path corresponding to the type, content, or context ID indicated in the first information; in this case, the second device 504 may determine, based on the first information, an indication that the first capsule has been accepted or that the second device 504 intends to send or receive payload information on the path as the second information.

[0127] In some example embodiments, the first device 502 may be an HTTP client, and the second device 504 may be a UDP proxy. For example, the HTTP client may be a User Plane Function (UPF), and the UDP proxy may be an Application Server (AS) or a proxy that allows access to an Application Server (AS). In this case, the path payload information may be associated with end-to-end secure traffic between the AS and the end device. The first device 502 may send information derived from the path payload information to the network device serving the end device (e.g., NG-RAN). In another example, the HTTP client may be the end device, and the UDP proxy may be a UPF. In this case, the path payload information may be associated with end-to-end secure traffic between the end device and the AS or other end devices.

[0128] Still referencing Figure 5 Before step 510, the first device 502 can send a request message to the second device 504, indicating its support for using the capsule. Simultaneously, in the opposite direction, the second device 504 can receive a request message from the first device 502, also indicating its support for using the capsule. Then, the second device 504 can send a response message to the first device 502, indicating permission to use the capsule. Simultaneously, in the opposite direction, the first device 502 can receive a response message from the second device 504, indicating permission to use the capsule. In some example embodiments, the request message may be an HTTP connection request message, and the response message may be an HTTP 200 OK response message. In this way, the first device 502 and the second device 504 can negotiate support for using the HTTP capsule, and an HTTP connection can be established.

[0129] In some example embodiments, the first device 502 may send path payload information to the second device 504 based on the second information. Simultaneously, in the opposite direction, the second device 504 may receive path payload information from the first device 502 based on the second information. Alternatively or additionally, the second device 504 may send path payload information to the first device 502 based on the second information. Simultaneously, in the opposite direction, the first device 502 may receive path payload information from the second device 504 based on the second information.

[0130] Figure 6 An example signaling procedure 600 is shown according to some embodiments of the present disclosure for negotiating payload information on the path that should be sent from the application server (AS) 606 to the user plane function (UPF) 604. Figure 6 It may also include UE 602. UE 602 can refer to Figure 1Terminal device 102-1, UPF 604 can refer to Figure 1 UPF 104 or Figure 5 The first device 502, and AS 606 may refer to Figure 1 AS 106 or Figure 5 The second device, 504. Figure 6 In this context, UPF 604 can be an HTTP client, and AS 606 can be a UDP proxy.

[0131] At 605, UE 602 sends a UL traffic plane packet to UPF 604. After the UL traffic plane packet is received, and / or after being instructed by an SMF with an AS proxy address to establish an HTTP connection to AS 606 using a UDP connection before or during the receipt of the first UL traffic plane packet from UE 602, UPF 604 will need to establish an HTTP connection to AS 606.

[0132] At 610, UPF 604 sends an HTTP connection request to AS 606, which instructs UPF 604 to support the use of HTTP capsules. At 620, UPF 604 receives a 200 OK response from AS 606, indicating that UPF 604 is permitted to use capsules. Therefore, UPF 604 and AS 606 have negotiated support for the use of HTTP capsules, and the HTTP connection has been established.

[0133] At 630, UPF 604 determines the MRI (and / or other path payload information) it supports receiving and / or transmitting in (multiple) formats / (multiple) versions and / or (multiple) contents. The MRI format / version may be a GMRI container format / version. The MRI content may include, for example, Protocol Data Unit (PDU) set information, data burst end indication, accelerated transmission indication, data burst size, or time to the next burst. If a UDP proxy is used (including the alternative of using the UDP option to carry path payload information), UPF 604 may determine the context ID to be used to receive the path payload information. UPF 604 may also determine that it needs to receive the path payload information from AS 606 carrying the MRI. Note that the order of 610 to 630 can be arbitrary. The (multiple) formats / (multiple) versions need to be negotiated between UPF 604 and AS 606, as UPF 604 and AS 606 may support different versions, or AS 606 may not support all versions supported by UPF 604. For example, UPF 604 may only support version 1, while AS 606 may support both version 1 and version 2.

[0134] At 640, UPF 604 sends a first HTTP capsule (e.g., a Request_MRIContextID version capsule) to AS 606. This first HTTP capsule includes information about payload information on the paths it supports receiving from and / or sending to AS 606. For example, the first HTTP capsule may include the GMRI container(s) format / (s) version and / or specific type of the MRI that UPF 604 supports receiving (e.g., PDU set information, burst end indication, accelerated transmission indication, burst size, or time to the next burst). As another example, the header may indicate the GMRI container(s) format / (s) version and / or specific type of the MRI that it supports sending (e.g., throughput recommendation). If a UDP proxy is used, the first HTTP capsule may include a context ID that will be used to transmit signaling information on the transmission path.

[0135] At 650, AS 606 determines, based on the received information, the path-on signaling it needs to send from AS 606 carrying the MRI, and determines the MRI (and / or other path-on payload information) it needs to send and / or is expected to receive in (multiple) formats / (multiple) versions and / or (multiple) contents. If a UDP proxy is used and no context ID is received in the HTTP connection request, AS 606 can determine the context ID that will be used to send the path-on payload information.

[0136] At 660, AS 606 may send a second HTTP capsule (e.g., a Response_MRIContextID version capsule) to UPF 604. The second HTTP capsule includes information about the payload information on the path that AS 606 will send to UPF 604 and / or expect to receive from UPF 604. For example, the second HTTP capsule may include the GMRI container(s) format / (s) version and / or specific type (e.g., PDU set information, burst end indication, accelerated delivery indication, burst size, or time to the next burst) of the MRI that AS 606 will send. As another example, the header may indicate the GMRI container(s) format / (s) version and / or specific type (e.g., throughput recommendation) of the MRI it expects to receive. If a UDP proxy is used, the second HTTP capsule may include a context ID that will be used to transmit signaling information on the path. Alternatively or additionally, the second HTTP capsule may include an indication that the first capsule has been accepted or that AS 606 will send the MRI based on the information in the first capsule. If AS 606 agrees to provide payload information on the path indicated in the first HTTP capsule, it will respond with the same information in the second HTTP capsule. Otherwise, AS 606 may propose new values ​​for the format(s) and / or version(s) and / or specific type or context ID of the MRI used in the second HTTP capsule.

[0137] At 670, AS 606 sends UDP datagrams to UPF 604. The UDP datagrams may include end-to-end (e2e) secure DL user plane packets. The UDP datagrams may also include an MRI based on the format(s), content(s), and / or context ID indicated in 660. Upon receiving the UDP datagrams, UPF 604 may send these UDP datagrams to UE 602 and use the MRI to control the Quality of Service (QoS) to be provided for the delivery of end-to-end (e2e) secure DL user plane packets to UE 602 via the access network serving UE 602 (e.g., RAN or non-3GPP access network). This may include using the received MRI to populate the tunneling protocol (such as GPRS Tunneling Protocol-User Plane (GTP-u)) used to deliver end-to-end (e2e) secure DL user plane packets to the access network.

[0138] By implementing the embodiments described with reference to FIG660, UPF 604 (i.e., the HTTP client) and AS 606 (i.e., the UDP proxy) can use capsule negotiation to associate information with payload information on the path, so that UPF 604 and AS 606 will know the payload information on the path to be transmitted and transmit the payload information on the path as negotiated.

[0139] Figure 7 Example signaling procedures 700 are shown according to some embodiments of the present disclosure for negotiating payload information on the path that should be sent from user equipment (UE) 702 to user plane function (UPF) 704. Figure 7 It may also include AS 706. UE702 may refer to... Figure 1 Terminal device 102-1 or Figure 5 The first device 502, UPF 704 in the text can refer to Figure 1 UPF104 or Figure 5 The second device 504 in the text, and AS 706 may refer to Figure 1 AS 106 in. Figure 7 In this context, UE 702 can be an HTTP client, and UPF 704 can be a UDP proxy.

[0140] UE 702 can generate path payload information (e.g., MRI) on the UL path pointing to UPF 704. This path payload information will be used by UPF 704 to support optimizations for the delivery of any (XRM) media traffic when forwarded to another UE (e.g., PDU collection processing). The uplink MRI from UE 702 to UPF 704 can support downlink services for remote UEs. If UE 702 is located on a different UPF, the remote UE can benefit from receiving path payload information via an intermediate UPF 704 or an intermediate AS 706.

[0141] At 710, UE 702 sends an HTTP connection request to UPF 704, which instructs UE 702 to support the use of HTTP capsules. At 720, UE 702 receives a 200 OK response from UPF 704, indicating that UPF 704 is permitted to use capsules. Therefore, UE 702 and UPF 704 negotiate support for the use of HTTP capsules, and an HTTP connection is established.

[0142] At 730, UE 702 may determine the MRI (and / or other path payload information) formats / versions and / or content that it supports for transmission and / or expects to receive. The MRI format / version may be a GMRI container format / version. The MRI content may include, for example, Protocol Data Unit (PDU) set information, data burst end indication, expedited transmission indication, data burst size, or time to the next burst. The path payload information that UE 702 expects to receive may include, for example, throughput recommendation information to inform the network how much throughput of the UL media stream that UE 702 wants to send to the network is acceptable. If a UDP proxy is used (including the alternative of using the UDP option to carry path payload information), UE 702 may determine the context ID that will be used to transmit the path payload information. UE 702 may determine that it needs to send the path payload information to UPF 704. Note that the order of 710 to 730 can be arbitrary.

[0143] At 740, UE 702 sends a first HTTP capsule (e.g., a Request_MRIContextID version capsule) to UPF 704. This first HTTP capsule includes information about payload information on paths it supports sending to UPF 704 and / or expects to support receiving from UPF 704. For example, the first HTTP capsule may include the GMRI container format / version(s) and / or specific type (e.g., PDU set information, data burst end indication, accelerated transmission indication, data burst size, or time to the next burst) of the MRI it supports sending. As another example, the first HTTP capsule may include the GMRI container format / version(s) and / or specific type (e.g., throughput recommendation) of the MRI it supports receiving. If a UDP proxy is used, the first HTTP capsule may also include a context ID used for signaling information on the transmission path.

[0144] At 750, UPF 704 determines, based on the received information, the signaling on the path it will receive from UE 702, and determines the MRI (and / or other path payload information) it expects to receive from UE 702 and / or to send to UE 702 in (multiple) formats / (multiple) versions and / or (multiple) contents. If a UDP proxy is used and no context ID is received in the HTTP connection request, AS 706 can determine the context ID that will be used for the payload information on the path sent by UE 702.

[0145] At 760, UPF 704 may send a second HTTP capsule (e.g., a Response_MRIContextID version capsule) to UE 702. The second HTTP capsule includes information about the payload information on the path that UPF 704 expects to receive from and / or send to UE 702. For example, the second HTTP capsule may include the GMRI container(s) format / (s) version and / or specific type (e.g., PDU set information, data burst end indication, accelerated transmission indication, data burst size, or time to next burst) of the MRI that UPF 704 expects to receive from UE 702. As another example, the header may indicate the GMRI container(s) format / (s) version and / or specific type (e.g., throughput suggestion) of the MRI it will send. If a UDP proxy is used, the second HTTP capsule may include a context ID that will be used for signaling information on the path sent by UE 702. Alternatively or additionally, the second HTTP capsule may include an indication that the first capsule has been accepted or that UPF 704 expects to receive the MRI based on information in the first capsule. If UPF 704 agrees to receive payload information on the path indicated in the first HTTP capsule, it will reply with the same information in the second HTTP capsule. Otherwise, UPF 704 may propose new values ​​for the format(s) and / or version(s) and / or specific type or context ID of the MRI used in the second HTTP capsule.

[0146] At 770, UE 702 sends a UDP datagram to UPF 704. This UDP datagram may include end-to-end (e2e) secure UL user plane packets. The UDP datagram may also include an MRI based on the format(s), content(s), and / or context ID indicated in 760. Upon receiving this UDP datagram, UPF 704 may send it to AS 706.

[0147] By implementing reference Figure 7 In these embodiments, UE 702 (i.e., the HTTP client) and UPF 704 (i.e., the UDP proxy) can use capsule negotiation to associate information with the payload information on the path, so UE 702 and UPF 704 will know the payload information on the path to be transmitted and transmit the payload information on the path according to the negotiation.

[0148] Figure 8A flowchart of an example method 800 implemented at a first device (e.g., terminal device 102-1, UPF 104, first device 202, UE 302, UPF 304, UE 402, or UPF 404) according to some embodiments of the present disclosure is shown. For ease of understanding, method 800 will be referenced to Figure 2 Described from the perspective of the first device 202.

[0149] At block 810, first device 202 sends a request message to second device 204, the request message including first information associated with payload information on the path, the first device 202 supporting receiving or sending the payload information on the path. At block 820, second device 204 receives a response message from second device 204, the response message including second information associated with the payload information on the path, the second device 204 intending to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0150] In some example embodiments, the payload information on the path includes: payload information received by the first device 202 from or sent to the second device 204 along with the user plane traffic transmitted between the first device and the second device, and the payload information is used by the first device or the second device 204 to support or influence the transmission of user plane traffic.

[0151] In some example embodiments, the first information includes at least one of the following: one or more types of payload information on the path that the first device 202 supports receiving or sending; the content of the payload information on the path that the first device 202 supports receiving or sending; or a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram, which the first device 202 supports receiving or sending when receiving or sending the payload information on the path using a User Datagram Protocol (UDP) proxy.

[0152] In some example embodiments, the second information includes at least one of the following: one or more types of payload information on the path that the second device 204 wants to send or receive; the content of the payload information on the path that the second device 204 wants to send or receive; a context ID for an HTTP datagram that the second device 204 wants to send or receive when using a UDP proxy to send or receive the payload information on the path; or an indication that the request message was successful, or that the second device 204 will send or receive the payload information on the path based on the first information.

[0153] In some example embodiments, the first device 202 is also configured to: determine first information associated with payload information on the path that the first device 202 supports receiving or transmitting.

[0154] In some example embodiments, the first device 202 is also configured to: be triggered to send path payload information to the second device 204, or receive path payload information from the second device 204.

[0155] In some example embodiments, the first device 202 is also configured to receive payload information on the path from the second device 204 based on the second information.

[0156] In some example embodiments, the first device 202 is also configured to send path payload information to the second device 204 based on the second information.

[0157] In some example implementations, the request message is an HTTP connection request message, and the response message is an HTTP 200 OK response message.

[0158] In some example embodiments, the first information is carried in the first HTTP header of the HTTP connection request, and the second information is carried in the second HTTP header of the HTTP 200 OK response message.

[0159] In some example embodiments, the payload information on this path includes media-related information (MRI).

[0160] In some example embodiments, first and second information are associated with the MRI, which is signaled within a General Media-Related Information (GMRI) container.

[0161] In some example embodiments, at least one of the following is satisfied: one or more types of payload information on the path include at least one of the following: one or more formats of signaling on the path carrying the MRI; or one or more formats for encoding the MRI; the content of the payload information on the path includes one or more types of the MRI; and the context ID for the HTTP datagram includes a context ID value that will be used to send or receive the MRI.

[0162] In some example embodiments, the one or more formats include one or more versions of the GMRI container.

[0163] In some example embodiments, one or more types of the MRI include at least one of the following: Protocol Data Unit (PDU) collection information; data burst end indication; expedited transmission indication; data burst size; or time to the next burst.

[0164] In some example embodiments, the first device 202 is an HTTP client and the second device 204 is a UDP proxy.

[0165] In some example embodiments, the HTTP client is a User Plane Function (UPF), and the UDP proxy is an Application Server (AS).

[0166] In some example embodiments, the payload information on this path is associated with end-to-end secure traffic between the AS and the end device.

[0167] In some example embodiments, the first device 202 is also configured to send payload information on the path to the network device serving the terminal device.

[0168] In some example embodiments, the HTTP client is a terminal device, and the UDP proxy is a UPF.

[0169] In some example embodiments, the payload information on the path is associated with end-to-end secure traffic between the terminal device and the AS or another terminal device.

[0170] Figure 9 A flowchart of an example method 900 implemented at a second device (e.g., UPF 104, AS 106, second device 204, UPF 304, AS 306, UPF 404, or AS 406) according to some embodiments of the present disclosure is shown. For ease of understanding, method 900 will refer to Figure 2 It is described from the perspective of the second device 204.

[0171] At block 910, the second device 204 receives a request message from the first device 202, the request message including first information associated with payload information on the path, the first device 202 supporting the reception or transmission of the payload information on the path. At block 920, the second device 204 sends a response message to the first device 202, the response message including second information associated with the payload information on the path, the second device 204 intending to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0172] In some example embodiments, the payload information on the path includes: payload information received by the first device 202 from or sent to the second device 204 along with the user plane traffic transmitted between the first device and the second device, and the payload information is used by the first device or the second device to support or influence the transmission of the user plane traffic.

[0173] In some example embodiments, the first information includes at least one of the following: the first device 202 supports receiving or sending one or more types of payload information on the path; the first device 202 supports receiving or sending the content of the payload information on the path; or a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram, wherein the first device 202 supports receiving or sending the HTTP datagram when receiving or sending the payload information on the path using a User Datagram Protocol (UDP) proxy.

[0174] In some example embodiments, the second information includes at least one of the following: one or more types of payload information that the second device 204 wants to send or receive on the path; the content of the payload information that the second device 204 wants to send or receive on the path; a context ID for an HTTP datagram that the second device 204 wants to send or receive when using a UDP proxy to send or receive the payload information on the path; or an indication that the request message was successful, or that the second device 204 will send or receive the payload information on the path based on the first information.

[0175] In some example embodiments, the second device 204 is also configured to: determine, based on the first information, second information associated with the payload information that the second device 204 is to send or receive on the path.

[0176] In some example embodiments, the second device 204 is also configured to send payload information on the path to the first device 202 based on the second information.

[0177] In some example embodiments, the second device 204 is also configured to receive payload information on the path from the first device 202 based on the second information.

[0178] In some example implementations, the request message is an HTTP connection request message, and the response message is an HTTP 200 OK response message.

[0179] In some example embodiments, the first information is carried in the first HTTP header of the HTTP connection request, and the second information is carried in the second HTTP header of the HTTP 200 OK response message.

[0180] In some example embodiments, the payload information on this path includes media-related information (MRI).

[0181] In some example embodiments, the first and second information are associated with the MRI, which is signaled within a General Media-Related Information (GMRI) container.

[0182] In some example embodiments of the second aspect, at least one of the following is satisfied: one or more types of payload information on the path include at least one of the following: one or more formats of signaling on the path carrying the MRI; or one or more formats for encoding the MRI; the content of the payload information on the path includes one or more types of the MRI; and the context ID for the HTTP datagram includes a context ID value that will be used to send or receive the MRI.

[0183] In some example embodiments, one or more formats include one or more versions of the GMRI container.

[0184] In some example embodiments, one or more types of MRI include at least one of the following: Protocol Data Unit (PDU) collection information; data burst end indication; expedited transmission indication; data burst size; or time to the next burst.

[0185] In some example embodiments, the first device 202 is an HTTP client and the second device 204 is a UDP proxy.

[0186] In some example implementations, the HTTP client is a user plane function (UPF), and the UDP proxy is an application server (AS).

[0187] In some example embodiments, the payload information on this path is associated with end-to-end secure traffic between the AS and the end device.

[0188] In some example implementations, the HTTP client is a terminal device, and the UDP proxy is a UPF.

[0189] In some example embodiments, the payload information on the path is associated with end-to-end secure traffic between the terminal device and an AS or another terminal device.

[0190] In some example embodiments, the second device 204 is also configured to send payload information on the path to the network device serving the terminal device.

[0191] In some example embodiments, the apparatus capable of performing method 800 (e.g., the first device 202) may include components for performing the corresponding steps of method 800. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.

[0192] In some example embodiments, the apparatus may include: components for sending a request message to a second device 204, the request message including first information associated with payload information on a path, the first device 202 supporting receiving or sending the payload information on the path; and components for receiving a response message from the second device 204, the response message including second information associated with the payload information on a path, the second device 204 to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0193] In some embodiments, the apparatus further includes components for performing other steps in some embodiments of method 800. In some embodiments, the components include at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured, together with the at least one processor, to cause execution of the apparatus.

[0194] In some example embodiments, the apparatus capable of performing method 900 (e.g., second device 204) may include components for performing the corresponding steps of method 900. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.

[0195] In some example embodiments, the apparatus may include: components for receiving a request message from a first device 202, the request message including first information associated with payload information on a path, the first device 202 supporting receiving or sending the payload information on the path; and components for sending a response message to the first device 202, the response message including second information associated with the payload information on the path, the second device 204 to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0196] In some embodiments, the apparatus further includes components for performing other steps in some embodiments of method 900. In some embodiments, the components include at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured, together with the at least one processor, to cause execution of the apparatus.

[0197] Figure 10 A flowchart of an example method 1000 implemented at a first device (e.g., terminal device 102-1, UPF 104, first device 502, UE 602, UPF 604, UE 702, or UPF 704) according to some other embodiments of the present disclosure is shown. For ease of understanding, method 1000 will be referenced to Figure 5Described from the perspective of the first device 502.

[0198] At block 1010, first device 502 sends a first capsule to second device 504, the first capsule including first information associated with payload information on the path, and first device 502 supports receiving or sending the payload information on the path. At block 1020, second device 504 receives a second capsule from second device 504, the second capsule including second information associated with the payload information on the path, and second device 504 is to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0199] In some example embodiments, the payload information on the path includes: payload information received by the first device 502 from or sent to the second device 504 along with the user plane traffic transmitted between the first device and the second device, and the payload information is used by the first device or the second device 504 to support or influence the transmission of user plane traffic.

[0200] In some example embodiments, the first information includes at least one of the following: one or more types of payload information on the path that the first device 502 supports receiving or sending; the content of the payload information on the path that the first device 502 supports receiving or sending; or a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram, which the first device 502 supports receiving or sending when receiving or sending the payload information on the path using a User Datagram Protocol (UDP) proxy.

[0201] In some example embodiments, the second information includes at least one of the following: one or more types of path payload information to be sent or received by the second device 504; the content of the path payload information to be sent or received by the second device 504; a context ID for an HTTP datagram, which the second device 504 will send or receive when using a UDP proxy to send or receive the path payload information; or an indication that the first capsule is accepted, or that the second device 504 will send or receive the path payload information based on the first information.

[0202] In some example embodiments, the first device 502 is also configured to: determine first information associated with payload information on the path that the first device 504 supports receiving or transmitting.

[0203] In some example embodiments, the first device 502 is also configured to: be triggered to send path payload information to the second device 504, or receive path payload information from the second device 504.

[0204] In some example embodiments, the first device 502 is also configured to receive payload information on the path from the second device 504 based on the second information.

[0205] In some example embodiments, the first device is also configured to: send path payload information to the second device 504 based on the second information.

[0206] In some example embodiments, before sending the first capsule, the first device 502 is also configured to: send a request message to the second device 504, the request message instructing the first device 502 to support the use of the capsule; and receive a response message from the second device 504, the response message indicating permission to use the capsule.

[0207] In some example implementations, the request message is an HTTP connection request message, and the response message is an HTTP 200 OK response message.

[0208] In some example embodiments, the payload information on this path includes media-related information (MRI).

[0209] In some example embodiments, at least one of the following is satisfied: one or more types of payload information on the path include at least one of the following: one or more formats of signaling on the path carrying the MRI; or one or more formats for encoding the MRI; the content of the payload information on the path includes one or more types of the MRI; and the context ID for the HTTP datagram includes a context ID value that will be used to send or receive the MRI.

[0210] In some example embodiments, one or more types of the MRI include at least one of the following: Protocol Data Unit (PDU) collection information; data burst end indication; expedited transmission indication; data burst size; or time to the next burst.

[0211] In some example embodiments, the first device 502 is an HTTP client and the second device 504 is a UDP proxy.

[0212] In some example embodiments, the HTTP client is a User Plane Function (UPF), and the UDP proxy is an Application Server (AS).

[0213] In some example embodiments, the payload information on this path is associated with end-to-end secure traffic between the AS and the end device.

[0214] In some example embodiments, the first device 502 is also configured to send payload information on the path to the network device serving the terminal device.

[0215] In some example embodiments, the HTTP client is a terminal device, and the UDP proxy is a UPF.

[0216] In some example embodiments of the first aspect, the payload information on the path is associated with end-to-end secure traffic between the terminal device and the AS or another terminal device.

[0217] Figure 11 A flowchart of an example method 1100 implemented at a second device (e.g., UPF 104, AS 106, second device 504, UPF 604, AS 606, UPF 704, or AS 706) according to some other embodiments of the present disclosure is shown. For ease of understanding, method 1100 will be referenced to Figure 5 It is described from the perspective of the second device 504.

[0218] At block 1110, second device 504 receives a first capsule from first device 502, the first capsule including first information associated with payload information on the path, and first device 502 supports receiving or sending the payload information on the path. At block 1120, second device 504 sends a second capsule to first device 502, the second capsule including second information associated with the payload information on the path, the second device 504 intending to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0219] In some example embodiments, the payload information on the path includes: payload information received by the first device 502 from or sent to the second device 504 along with the user plane traffic transmitted between the first device and the second device, and the payload information is used by the first device or the second device 504 to support or influence the transmission of user plane traffic.

[0220] In some example embodiments, the first information includes at least one of the following: one or more types of payload information on the path that the first device 502 supports receiving or sending; the content of the payload information on the path that the first device 502 supports receiving or sending; or a context identifier (ID) for a Hypertext Transfer Protocol (HTTP) datagram, which the first device 502 supports receiving or sending when receiving or sending the payload information on the path using a User Datagram Protocol (UDP) proxy.

[0221] In some example embodiments, the second information includes at least one of the following: one or more types of payload information on the path that the second device 504 wants to send or receive; the content of the payload information on the path that the second device 504 wants to send or receive; a context ID for an HTTP datagram that the second device 504 will send or receive when sending or receiving the payload information on the path using a UDP proxy; or an indication that the first capsule is accepted, or that the second device 504 will send or receive the payload information on the path based on the first information.

[0222] In some example embodiments, the second device 504 is also configured to: determine, based on the first information, second information associated with the payload information on the path to be sent or received by the second device 504.

[0223] In some example embodiments, the second device is also configured to send payload information on the path to the first device 502 based on the second information.

[0224] In some example embodiments, the second device is also configured to receive payload information on the path from the first device 502 based on the second information.

[0225] In some example embodiments, prior to receiving the first capsule, the second device 504 is also configured to: receive a request message from the first device 502 indicating that the first device 502 is authorized to use the capsule; and send a response message to the first device 502 indicating permission to use the capsule.

[0226] In some example implementations, the request message is an HTTP connection request message, and the response message is an HTTP 200 OK response message.

[0227] In some example embodiments, the payload information on this path includes media-related information (MRI).

[0228] In some example embodiments, at least one of the following is satisfied: one or more types of payload information on the path include at least one of the following: one or more formats of signaling on the path carrying the MRI; or one or more formats for encoding the MRI; the content of the payload information on the path includes one or more types of the MRI; and the context ID for the HTTP datagram includes a context ID value that will be used to send or receive the MRI.

[0229] In some example embodiments, one or more types of MRI include at least one of the following: Protocol Data Unit (PDU) collection information; data burst end indication; expedited transmission indication; data burst size; or time to the next burst.

[0230] In some example embodiments, the first device 502 is an HTTP client and the second device 504 is a UDP proxy.

[0231] In some example implementations, the HTTP client is a user plane function (UPF), and the UDP proxy is an application server (AS).

[0232] In some example embodiments, the payload information on this path is associated with end-to-end secure traffic between the AS and the end device.

[0233] In some example implementations, the HTTP client is a terminal device, and the UDP proxy is a UPF.

[0234] In some example embodiments, the payload information on the path is associated with end-to-end secure traffic between the terminal device and the AS or another terminal device.

[0235] In some example embodiments, the second device 504 is also configured to send payload information on the path to the network device serving the terminal device.

[0236] In some example embodiments, the apparatus capable of performing method 1000 (e.g., the first device 502) may include components for performing the corresponding steps of method 1000. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.

[0237] In some example embodiments, the apparatus may include: components for sending a first capsule to a second device 504, the first capsule including first information associated with payload information on a path, the first device 502 supporting receiving or sending the payload information on the path; and components for receiving a second capsule from the second device 504, the second capsule including second information associated with the payload information on a path, the second device 504 to send or receive the payload information on the path, wherein the second information is determined based on the first information.

[0238] In some embodiments, the apparatus further includes components for performing other steps in some embodiments of method 1000. In some embodiments, the components include at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured, together with the at least one processor, to cause execution of the apparatus.

[0239] In some example embodiments, the apparatus capable of performing method 1100 (e.g., the second device 504) may include components for performing the corresponding steps of method 1100. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.

[0240] In some example embodiments, the apparatus may include: components for receiving a first capsule from a first device 502, the first capsule including first information associated with payload information on a path, the first device 502 supporting receiving or transmitting the payload information on the path; and components for transmitting a second capsule to the first device 502, the second capsule including second information associated with the payload information on a path, the second device 504 to transmit or receive the payload information on the path, wherein the second information is determined based on the first information.

[0241] In some embodiments, the apparatus further includes components for performing other steps in some embodiments of method 1100. In some embodiments, the components include at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code being configured, together with the at least one processor, to cause execution of the apparatus.

[0242] Figure 12 A simplified example block diagram of a device 1200 suitable for implementing embodiments of the present disclosure is shown. Device 1200 may be provided to implement a communication device or network element, such as... Figure 1 The terminal devices 102-1, UPF 104, and AS 106 are shown. As shown, device 1200 includes one or more processors 1210, one or more memories 1220 that can be coupled to processor 1210, and one or more communication modules 1240 that can be coupled to processor 1210.

[0243] The communication module 1240 is used for bidirectional communication. The communication module 1240 has at least one antenna to facilitate communication. The communication interface can represent any interface required for communication with other network elements; for example, the communication interface can be wireless or wired to other network elements, or a software-based interface for communication.

[0244] Processor 1210 can be of any type suitable for a local technology network, and by way of non-limiting example, can include one or more of the following: a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), a graphics processing unit (GPU), and a processor based on a multi-core processor architecture. Device 1200 can have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock synchronized with the main processor.

[0245] Memory 1220 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1224, electrically programmable read-only memory (EPROM), flash memory, hard disk, optical disc (CD), digital video disc (DVD), and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1222 and other volatile memories that will not persist during power outages.

[0246] Computer program 1230 includes computer-executable instructions that are executed by the associated processor 1210. Program 1230 may be stored in ROM 1224. Processor 1210 may perform any suitable actions and processes by loading program 1230 into RAM 1222.

[0247] The embodiments of this disclosure can be implemented by a program, enabling device 1200 to execute references. Figures 1 to 11 Any process discussed in this disclosure. Embodiments of this disclosure may also be implemented by hardware or by a combination of software and hardware.

[0248] In some embodiments, program 1230 may be tangibly contained in a computer-readable medium, which may be included in device 1200 (e.g., in memory 1220) or in other storage devices accessible to device 1200. Device 1200 may load program 1230 from the computer-readable medium into RAM 1222 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Figure 13 An example of a computer-readable medium 1300 in the form of a CD or DVD is shown. The computer-readable medium has a program 1230 stored thereon.

[0249] Generally, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, as non-limiting examples, the blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0250] This disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in a program module, which are executed in a device on a target real or virtual processor to perform the above-mentioned... Figure 2 or Figure 11 The method described is 200 or 1100. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of a program module can be combined or split among program modules as needed. The machine-executable instructions for a program module can be executed on a local or distributed device. In a distributed device, the program module can reside on both local and remote storage media.

[0251] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0252] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0253] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples of computer-readable storage media will include electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The term “non-transient” as used herein is a limitation on the medium itself (i.e., tangible, not signaling), not a limitation on the persistence of data storage (e.g., RAM and ROM).

[0254] Furthermore, although operations are described in a specific order, this should not be construed as requiring the operations to be performed in the specific order shown or sequentially, or to perform all of the shown operations, to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0255] Although this disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that the disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features or actions described above are disclosed as exemplary forms of implementing the claims.

Claims

1. A first device for communication, the first device comprising: At least one processor; as well as At least one memory, the at least one memory storing instructions, the instructions, when executed by the at least one processor, cause the first device to at least: Sending a first capsule to a second device, the first capsule including first information associated with payload information on the path, the first device supporting receiving or sending the payload information on the path; and The second device receives a second capsule, the second capsule including second information associated with payload information on the path, the second device will send or receive the payload information on the path, wherein the second information is determined based on the first information.

2. The first device of claim 1, wherein the in-path payload information comprises: The payload information received by the first device from or sent to the second device along with the user plane traffic transmitted between the first device and the second device, and the payload information used by the first device or the second device to support or influence the transmission of the user plane traffic.

3. The first device according to claim 1, wherein the first information includes at least one of the following: The first device supports receiving or sending one or more types of payload information on the path; The first device supports receiving or sending the content of the payload information on the path; or A context identifier ID for a Hypertext Transfer Protocol (HTTP) datagram, wherein the first device supports receiving or sending the HTTP datagram when receiving or sending payload information on the path using a User Datagram Protocol (UDP) proxy.

4. The first device according to claim 1, wherein the second information includes at least one of the following: The second device needs to send or receive one or more types of payload information on the path; The content of the payload information on the path that the second device needs to send or receive; The context ID used for the HTTP datagram, which the second device will send or receive when sending or receiving payload information on the path using a UDP proxy; or The first capsule is accepted, or the second device will send or receive an indication of payload information on the path based on the first information.

5. The first device according to claim 1, wherein the first device is further configured to: The first information is determined to be associated with payload information on the path that the first device supports receiving or sending.

6. The first device according to claim 1, wherein the first device is further configured to: It is triggered to send payload information on the path to the second device or to receive payload information on the path from the second device.

7. The first device according to claim 1, wherein the first device is further configured to: Based on the second information, the payload information on the path is received from the second device.

8. The first device according to claim 1, wherein the first device is further configured to: Based on the second information, the payload information on the path is sent to the second device.

9. The first device according to claim 1, wherein before delivering the first capsule, the first device is further configured to: Send a request message to the second device, the request message instructing the first device to support the use of the capsule; and Receive a response message from the second device, the response message indicating permission to use the capsule.

10. The first device of claim 9, wherein the request message is an HTTP connection request message and the response message is an HTTP 200 OK response message.

11. The first device according to any one of claims 1 to 10, wherein the payload information on the path includes media-related information MRI.

12. The first device according to claim 1, wherein at least one of the following: The one or more types of payload information on the path include at least one of the following: one or more formats of on-path signaling carrying the MRI; or one or more formats for encoding the MRI; The content of the payload information on the path includes one or more types of the MRI; and The context ID used for the HTTP datagram includes a context ID value that will be used to send or receive the MRI.

13. The first device of claim 12, wherein the one or more types of the MRI include at least one of the following: Protocol Data Unit (PDU) set information; Data burst termination instruction; Urgent delivery instruction; Data burst size; or Until the next emergency.

14. The first device of claim 1, wherein the first device is an HTTP client and the second device is a UDP proxy.

15. The first device of claim 14, wherein the HTTP client is a User Plane Function (UPF) and the UDP proxy is an Application Server (AS); and The payload information on the path is associated with the end-to-end secure traffic between the AS and the terminal device.

16. The first device of claim 14, wherein the HTTP client is a terminal device and the UDP proxy is a UPF; and The payload information on the path is associated with end-to-end secure traffic between the terminal device and the AS or another terminal device.

17. A second device for communication, the second device comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the second device to at least: A first capsule is received from a first device, the first capsule including first information associated with payload information on the path, the first device supporting receiving or sending the payload information on the path; A second capsule is sent to the first device, the second capsule including second information associated with payload information on the path, the second device sending or receiving the payload information on the path, wherein the second information is determined based on the first information.

18. A method for communication, the method comprising: Sending a first capsule to a second device, the first capsule including first information associated with payload information on the path, the first device supporting receiving or sending the payload information on the path; and The second device receives a second capsule, the second capsule including second information associated with payload information on the path, the second device will send or receive the payload information on the path, wherein the second information is determined based on the first information.

19. A method for communication, the method comprising: A first capsule is received from a first device, the first capsule including first information associated with payload information on the path, the first device supporting receiving or sending the payload information on the path; A second capsule is sent to the first device, the second capsule including second information associated with payload information on the path, the second device sending or receiving the payload information on the path, wherein the second information is determined based on the first information.

Images