Exchanging local address information for a set of PDUs of a media communication session

Abstract

An example user equipment (UE) device for exchanging media data via a network includes: a memory configured to store media data; and a processing system including one or more processors implemented in circuitry, the processing system being configured to: receive data from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; establish a media communication session with the second network device; transmit data representing the local IP address type and MTU size for the second network device to a gateway device associated with the RAN; and receive packets of Protocol Data Units (PDUs) derived from the media communication session of the second network device via the RAN.

Description

[0001] This application claims priority to U.S. Patent Application No. 18 / 938,052, filed November 5, 2024, and U.S. Provisional Application No. 63 / 596,415, filed November 6, 2023, the entire contents of each of these applications are incorporated herein by reference. U.S. Patent Application No. 18 / 938,052 claims the benefit of U.S. Provisional Application No. 63 / 596,415. Technical Field

[0002] This disclosure relates to the storage and transmission of encoded media data. Background Technology

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcasting systems, wireless broadcasting systems, personal digital assistants (PDAs), laptops or desktop computers, digital cameras, digital recording devices, digital media players, video game devices, video game consoles, cellular or satellite broadcast phones, video conferencing equipment, and more. Digital video devices implement video compression technologies (such as those described in standards defined by MPEG-2, MPEG-4, ITU-T H.263 or ITU-T H.264 / MPEG-4, Part 10, Advanced Video Decoding (AVC), ITU-T H.265 (also known as Advanced Video Decoding (HEVC)), and extensions to these standards) to send and receive digital video information more efficiently.

[0004] Video compression techniques perform spatial and / or temporal prediction to reduce or remove inherent redundancy in video sequences. For block-based video decoding, video frames or slices can be divided into macroblocks. Each macroblock can be further subdivided. Macroblocks in intra-frame decoding (I) frames or slices can be encoded using spatial prediction of adjacent macroblocks. Macroblocks in inter-frame decoding (P or B) frames or slices can be encoded using spatial prediction of adjacent macroblocks in the same frame or slice, or temporal prediction of other reference frames.

[0005] After video data is encoded, it can be packaged for transmission or storage. Video data can be assembled into video files that conform to any of various standards, such as the International Organization for Standardization (ISO) Basic Media File Format and its extensions, such as AVC. Summary of the Invention

[0006] Generally, this disclosure describes techniques for exchanging media data over a computer-based network, such as a 3GPP-compliant network, e.g., 5G. When media data is transmitted over a network, the media data may include datasets that will be presented simultaneously, such as video data frames, audio data, timed text data (e.g., closed caption data), etc. The datasets that will be presented simultaneously may be referred to as a set of Protocol Data Units (PDUs). Because the data in the PDU set will be presented simultaneously, it is important that the packets of the PDU set arrive at the destination (e.g., a User Equipment (UE) device) or are available at the destination substantially simultaneously. Therefore, a PDU set size (PSSize) value may be added to one or more packets of the PDU set to indicate the size of the data for the PDU set.

[0007] However, IP segmentation may occur during network transmission, which could change the number of PDUs included in the PDU set. This can happen because different devices in the network between the source device and the destination device (e.g., the UE) have different Maximum Transmission Unit (MTU) sizes or different IP address types (e.g., IPv4 vs. IPv6). Therefore, according to the techniques of this disclosure, the UE device can determine the IP address type and MTU size for the source device (which may be another UE device) and signal the source device's IP address type and MTU size to a gateway device, such as a device performing User Plane Functions (UPF). If necessary, the gateway device can then recalculate the PSSize value using the IP address type and MTU size.

[0008] In one example, a method for exchanging media data over a network includes: a user equipment (UE) receiving data from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; the UE establishing a media communication session with the second network device; the UE transmitting data representing the local IP address type and MTU size for the second network device to a gateway device of the RAN; and the UE receiving packets of Protocol Data Units (PDUs) from the media communication session originating from the second network device via the RAN.

[0009] In another example, a user equipment (UE) device for exchanging media data over a network includes: a memory configured to store media data; and a processing system including one or more processors implemented in a circuit, the processing system being configured to: receive data from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; establish a media communication session with the second network device; transmit data representing the local IP address type and MTU size for the second network device to a gateway device of the RAN; and receive packets of Protocol Data Units (PDUs) originating from the media communication session of the second network device via the RAN.

[0010] In another example, a method for exchanging media data over a network includes: receiving data from a user equipment (UE) device, and from a gateway device, representing a local Internet Protocol (IP) address type and a maximum transmission unit (MTU) size for a second network device, wherein the gateway device is within a radio access network (RAN) to which the UE device is communicatively coupled; receiving a first data packet of a first Protocol Data Unit (PDU) by the gateway device; determining that the source IP address of the first data packet matches the IP address of the second network device by the gateway device; adjusting a PDU set size (PSSize) value by the gateway device based on the local IP address type, the MTU size, and the number of PDUs for the first PDU; encapsulating the first data packet in a GPRS Tunneling Protocol (GTP-U) packet by the gateway device; adding the adjusted PSSize value to the header of the GTP-U packet by the gateway device; and transmitting the GTP-U packet to the UE device via the RAN by the gateway device.

[0011] In another example, a gateway device for a radio access network (RAN) includes: a memory configured to store network packets; and a processing system implemented in circuitry configured to: receive data representing a local Internet Protocol (IP) address type and a maximum transmission unit (MTU) size for a second network device from a user equipment (UE) device communicatively coupled to the RAN; receive a first data packet of a first Protocol Data Unit (PDU); determine that the source IP address of the first data packet matches the IP address of the second network device; adjust a PDU set size (PSSize) value based on the local IP address type, MTU size, and the number of PDUs for the first PDU; encapsulate the first data packet in a GPRS Tunneling Protocol (GTP-U) packet; add the adjusted PSSize value to the header of the GTP-U packet; and transmit the GTP-U packet to the UE device via the RAN.

[0012] Details of one or more examples are set forth in the accompanying drawings and the following description. Other features, objects, and advantages will be apparent from these descriptions and drawings, and from the claims. Attached Figure Description

[0013] Figure 1 This is a block diagram illustrating an example system for implementing a technology for streaming media data over a network.

[0014] Figure 2 This is a block diagram illustrating the elements of the example video file.

[0015] Figure 3 This is a block diagram illustrating an example set of devices that can participate in media communication sessions according to the technology of this disclosure.

[0016] Figure 4 This is a flowchart illustrating an example method for transmitting local / private address types according to the technology disclosed herein.

[0017] Figure 5 This is a flowchart illustrating another example method for transmitting local / private address types according to the technology of this disclosure. Detailed Implementation

[0018] Generally, this disclosure describes techniques for exchanging media data over a network. The network may be a 5G network, a 6G network, or another radio access network (RAN). A Protocol Data Unit (PDU) set represents one or more PDUs, each carrying a payload of information units generated at the application level. Thus, for example, a PDU may include video data frames, slices of video data frames, audio data, computer graphics data, or other media data for extended reality (XR) services. This definition of a PDU set is included in 3GPP TS 23.501 v.18.1.0.

[0019] When two (or more) devices participate in an XR session, one device can transmit the PDU set size to another device. The PDU set size can represent the total size of all PDUs in the PDU set to which a particular PDU belongs, including the RTP / UDP / IP header encapsulation overhead for the corresponding PDU. The RTP (Real-Time Transport Protocol) transmitter can calculate the PDU set size value (PSSize) and include it in the RTP header extension of the RTP packets transmitted to the RTP receiver. However, due to network tunneling (e.g., IPv4-IPv6 tunneling, Carrier-Grade Network Address Translation (CGNAT), or Network Address Translation-Protocol Translation (NAT-PT)), the IP address version (e.g., IPv4 or IPv6) used locally by the RTP transmitter to generate IP packets encapsulating RTP (and / or, in some cases, UDP (User Datagram Protocol)) packets may differ from the IP version transmitted to the gateway device (e.g., a device performing User Plane Functions (UPF)).

[0020] Therefore, without the techniques disclosed herein, the PSSize value provided by the RTP transmitter may be inaccurate. That is, without these techniques, PSSize may not accurately reflect the size of the PDU set due to the inclusion or exclusion of local and / or global network addresses. In RFC 4566 (which specifies the Session Description Protocol (SDP) standard), the address types and addresses defined in the "c=" and "o=" lines are for global or public addresses, not local or private addresses.

[0021] This disclosure describes techniques for exchanging local address information related to a media communication session, for example, between devices involved in a media communication session or with other intermediate devices, which may use the local address information to, for example, recalculate or interpret the PDU set size value.

[0022] U.S. Provisional Application No. 63 / 580,250, filed September 1, 2023, entitled “Exchanging Local Address Information for Media Communication Session,” describes the use of SDP attributes to transmit local / private address types for RTP packet sources. In other words, Provisional Application '250 describes a control plane solution that can assist in processing PDU set information at the gateway device and can be used for other purposes.

[0023] This disclosure describes alternative data plane solutions. It describes techniques for carrying local / private address types along with PDU set data. This can eliminate control plane signaling overhead and is more robust in certain scenarios, such as when IP address types change due to mobile device mobility / movement between cells.

[0024] In order for a gateway device to adjust the PDU set size (PSSize), the gateway device needs to determine the number of PDUs in the PDU set. However, IP fragmentation may occur in the network, which may change the number of PDUs processed by the gateway device, because IP reassembly is usually done at the destination rather than at intermediate routers to reduce the load on intermediate routers.

[0025] This disclosure also describes techniques for signaling the raw MTU size. In some examples, this can be done via RTP header extension or via SDP signaling.

[0026] Figure 1 This is a block diagram illustrating an example system 10 for implementing techniques for streaming media data over a network. In this example, system 10 includes a content preparation device 20, a server device 60, and a client device 40. Client device 40 and server device 60 are communicatively coupled via a network 74, which may include the Internet. In some examples, content preparation device 20 and server device 60 may also be coupled via network 74 or another network, or may be directly communicatively coupled. In some examples, content preparation device 20 and server device 60 may include the same device.

[0027] exist Figure 1 In the example, content preparation device 20 includes an audio source 22 and a video source 24. Audio source 22 may include, for example, a microphone that generates electrical signals representing captured audio data to be encoded by audio encoder 26. Alternatively, audio source 22 may include: a storage medium storing previously recorded audio data; an audio data generator, such as a computerized synthesizer; or any other audio data source. Video source 24 may include: a video camera that generates video data to be encoded by video encoder 28; a storage medium encoding previously recorded video data; a video data generation unit, such as a computer graphics source; or any other video data source. Content preparation device 20 is not necessarily communicatively coupled to server device 60 in all examples, but multimedia content may be stored on a separate medium that is read by server device 60.

[0028] The raw audio and video data may include analog or digital data. Analog data may be digitized before being encoded by audio encoder 26 and / or video encoder 28. While a speaker is speaking, audio source 22 may obtain audio data from that speaker, and video source 24 may simultaneously obtain video data of that speaker. In other examples, audio source 22 may include a computer-readable storage medium containing stored audio data, and video source 24 may include a computer-readable storage medium containing stored video data. Thus, the techniques described in this disclosure can be applied to live, streaming, real-time audio and video data, or to archived, pre-recorded audio and video data.

[0029] An audio frame corresponding to a video frame is typically an audio frame containing audio data, which is simultaneously captured (or generated) by audio source 22 and video data captured (or generated) by video source 24 and contained within the video frame. For example, when a speaker typically generates audio data by speaking, audio source 22 captures the audio data, and video source 24 simultaneously (i.e., while audio source 22 is capturing audio data) captures the speaker's video data. Therefore, an audio frame can temporally correspond to one or more specific video frames. Thus, an audio frame corresponding to a video frame typically corresponds to the following situation: in which audio data and video data are captured simultaneously, and in this situation, the audio frame and video frame respectively include the simultaneously captured audio data and video data.

[0030] In some examples, audio encoder 26 may encode a timestamp into each encoded audio frame, where the timestamp indicates the time when the audio data for the encoded audio frame was recorded, and similarly, video encoder 28 may encode a timestamp into each encoded video frame, where the timestamp indicates the time when the video data for the encoded video frame was recorded. In such examples, the audio frame corresponding to the video frame may include: an audio frame including a timestamp, and a video frame including the same timestamp. Content preparation device 20 may include an internal clock, which audio encoder 26 and / or video encoder 28 may use to generate timestamps, or audio source 22 and video source 24 may use the internal clock to associate audio and video data with timestamps, respectively.

[0031] In some examples, audio source 22 may transmit data corresponding to the time when the audio data was recorded to audio encoder 26, and video source 24 may transmit data corresponding to the time when the video data was recorded to video encoder 28. In some examples, audio encoder 26 may encode sequence identifiers into the encoded audio data to indicate the relative time order of the encoded audio data, rather than the absolute time when the audio data was recorded; similarly, video encoder 28 may use sequence identifiers to indicate the relative time order of the encoded video data. Similarly, in some examples, sequence identifiers may be mapped or otherwise associated with timestamps.

[0032] Audio encoder 26 typically produces encoded audio data streams, while video encoder 28 produces encoded video data streams. Each individual data stream (whether audio or video) can be referred to as an elementary stream. An elementary stream is a single, digitally decoded (possibly compressed) component of a media presentation. For example, the decoded video or audio portion of a media presentation can be an elementary stream. Elementary streams can be converted into Packed Elementary Streams (PES) before being encapsulated into a video file. Within the same media presentation, stream IDs can be used to distinguish PES packets belonging to one elementary stream from those belonging to another. The basic unit of data in an elementary stream is the packed elementary stream (PES) packet. Therefore, decoded video data typically corresponds to an elementary video stream. Similarly, audio data corresponds to one or more corresponding elementary streams.

[0033] exist Figure 1 In one example, the encapsulation unit 30 of the content preparation device 20 receives a base stream of video data including decoded data from the video encoder 28 and a base stream of audio data including decoded data from the audio encoder 26. In some examples, both the video encoder 28 and the audio encoder 26 may include packers for forming PES packets based on the encoded data. In other examples, both the video encoder 28 and the audio encoder 26 may interface with corresponding packers for forming PES packets based on the encoded data. In other examples, the encapsulation unit 30 may include packers for forming PES packets based on the encoded audio and video data.

[0034] Video encoder 28 is capable of encoding video data of multimedia content in various ways to produce different representations of the multimedia content at various bit rates and utilizing various characteristics such as pixel resolution, frame rate, compliance with various decoding standards, compliance with various profiles and / or profile levels used for various decoding standards, representations with one or more views (e.g., for two-dimensional or three-dimensional playback), or other such characteristics. As used in this disclosure, the representation may include one of the following: audio data, video data, text data (e.g., for closed captions), or other such data. The representation may include a primary stream, such as an audio primary stream or a video primary stream. Each PES packet may include a stream_id, which identifies the primary stream to which the PES packet belongs. Encapsulation unit 30 is responsible for assembling the primary streams into streamable media data.

[0035] Encapsulation unit 30 receives PES packets from audio encoder 26 and video encoder 28 for media presentation of the basic stream, and forms corresponding Network Abstraction Layer (NAL) units based on the PES packets. Decoded video segments can be organized into NAL units that provide a “network-friendly” video representation for addressing applications such as video telephony, storage, broadcasting, or streaming. NAL units can be classified as Video Decoding Layer (VCL) NAL units and non-VCL NAL units. VCL units may contain the core compression engine and may include block, macroblock, and / or slice-level data. Other NAL units may be non-VCL NAL units. In some examples, a picture of the decoded data in a time instance (typically presented as a picture of the main decoded data) may be included in an access unit, which may include one or more NAL units.

[0036] Non-VCL NAL units can include parameter set NAL units and SEI NAL units, etc. Parameter sets can contain sequence-level header information (in the Sequence Parameter Set (SPS)) and picture-level header information that changes very little (in the Picture Parameter Set (PPS)). Using parameter sets (e.g., PPS and SPS), it is not necessary to repeat information that changes very little for each sequence or picture; therefore, decoding efficiency can be improved. Furthermore, the use of parameter sets allows for out-of-band transmission of important header information, thus avoiding redundant transmissions required for error recovery. In an example of out-of-band transmission, parameter set NAL units can be transmitted on a different channel than other NAL units (such as SEI NAL units).

[0037] Supplemental Enhancement Information (SEI) can contain information that is not essential for decoding image samples from VCL NAL units but can assist in processes related to decoding, display, error recovery, and other purposes. SEI messages can be included in non-VCL NAL units. SEI messages are a specification part of some standards and are therefore not always mandatory for specific implementations of standards-compliant decoders. SEI messages can be sequence-level or image-level. Some sequence-level information can be included in SEI messages, such as the scalability information SEI message in the SVC example and the view scalability information SEI message in MVC. These example SEI messages can convey information such as the extraction and characteristics of operation points.

[0038] Server device 60 includes a Real-Time Transport Protocol (RTP) sending unit 70 and a network interface 72. In some examples, server device 60 may include multiple network interfaces. Furthermore, any or all of the features of server device 60 may be implemented on other devices in the content delivery network, such as routers, bridges, proxy devices, switches, or other devices. In some examples, intermediate devices in the content delivery network may cache data for multimedia content 64 and include components that substantially conform to the components of server device 60. Generally, network interface 72 is configured to transmit and receive data via network 74.

[0039] RTP sending unit 70 is configured to deliver media data to client device 40 via network 74 according to RTP, which is standardized in Internet Engineering Task Force (IETF) Request for Comments (RFC) 3550. RTP sending unit 70 may also implement RTP-related protocols such as RTP Control Protocol (RTCP), Real-time Streaming Protocol (RTSP), Session Initiation Protocol (SIP), and / or Session Description Protocol (SDP). RTP sending unit 70 can transmit media data via network interface 72, which implements Uniform Datagram Protocol (UDP) and / or Internet Protocol (IP). Therefore, in some examples, server device 60 may use network 74 to transmit media data via RTP and RTSP over UDP.

[0040] RTP sending unit 70 may receive RTSP description requests from, for example, client device 40. RTSP description requests may include data indicating what types of data the client device 40 supports. RTP sending unit 70 may respond to client device 40 with data indicating a media stream (such as media content 64), which may be transmitted to client device 40 together with a corresponding network location identifier (such as a Uniform Resource Locator (URL) or Uniform Resource Name (URN)).

[0041] Then, RTP sending unit 70 can receive an RTSP establishment request from client device 40. The RTSP establishment request typically indicates how the media stream will be transmitted. The RTSP establishment request may include a network location identifier and transmission specifier for the requested media data (e.g., media content 64), such as the local port used to receive RTP data and control data (e.g., RTCP data) on client device 40. RTP sending unit 70 can respond to the RTSP establishment request with acknowledgments and data representing the port of server device 60, through which the RTP data and control data will be transmitted. RTP sending unit 70 can then receive an RTSP playback request to allow the media stream to be "played," i.e., transmitted to client device 40 via network 74. RTP sending unit 70 can also receive an RTSP teardown request to terminate the streaming session; in response to this RTSP teardown request, RTP sending unit 70 can stop transmitting media data for the corresponding session to client device 40.

[0042] Similarly, RTP receiving unit 52 can initiate a media stream by initially sending an RTSP description request to server device 60. The RTSP description request can indicate the data types supported by client device 40. RTP receiving unit 52 can then receive from server device 60 a reply specifying an available media stream (such as media content 64) that can be transmitted to client device 40 along with a corresponding network location identifier (such as a Uniform Resource Locator (URL) or Uniform Resource Name (URN)).

[0043] Then, RTP receiving unit 52 can generate an RTSP establishment request and transmit it to server device 60. As noted above, the RTSP establishment request may include a network location identifier for the requested media data (e.g., media content 64) and a transport specification, such as the local port used to receive RTP data and control data (e.g., RTCP data) on client device 40. In response, RTP receiving unit 52 can receive an acknowledgment from server device 60, including the port of server device 60 used to transmit media data and control data.

[0044] After a media streaming session is established between server device 60 and client device 40, the RTP sending unit 70 of server device 60 can transmit media data (e.g., packets of media data) to client device 40 according to the media streaming session. Server device 60 and client device 40 can exchange control data (e.g., RTCP data) indicating, for example, the receive statistics of client device 40, so that server device 60 can perform congestion control or otherwise diagnose and resolve transmission failures.

[0045] According to the technology disclosed herein, the RTP sending unit 70 can transmit additional PDU set information via an RTP header extension. For example, the RTP sending unit 70 may include at least one of the following: local address type, MTU size at the source (e.g., server device 60), and / or the number of PDUs in the RTP header extension. The RTP header extension may be an RTP header extension for PDU set marking, which includes any or all of the following information: an indication of the last PDU in the PDU set, a data burst end indication, a PDU set importance indication, a PDU set sequence number indication, a PDU sequence number indication within the PDU set, and / or the PDU set size (PSSize).

[0046] The local address type can be the type of IP address based on its calculated PSSize. In some examples, the local address type can be, for example, IPv4, IPv6, Ethernet, or unstructured. The local address type can occupy 1 or 2 bits, for example, in the RTP header extension.

[0047] The MTU size at the source can be the MTU size of the network at the source of the PDU set. The gateway device can use the MTU size on incoming links receiving the PDU set. The gateway device can compare the indicated MTU size with the MTU size at the source and adjust the number of PDUs accordingly. The number of PDUs can be the number of PDUs in the PDU set.

[0048] Additionally or alternatively, the SDP attribute can be used to indicate the MTU size. The SDP attribute can have the following format: "a=mtu: <mtu-size>The MTU size attribute is specified in the SDP message's header file, where mtu-size is the size of the MTU at the transmitter. The unit of mtu-size can be bytes or multiple bytes, for example, x bytes, where x can be, for example, 4, 8, 10, or other values. The MTU size attribute can be included in the SDP proposal message or the SDP response message.

[0049] Additional or alternative locations, application functions (AF) Figure 1 (Not shown) can be configured to process related session data. The UE (e.g., client device 40) can extract at least one of a local IP address type indicator and / or an MTU size indicator from the session establishment message (e.g., SDP proposal message / SDP response message). The UE can transmit the extracted information to the AF along with identifiers of other endpoints in the session (e.g., application server (AS)) (e.g., server device 60 or content preparation device 20). Identifiers may include one or more of the following: the public IP address of the other endpoint, the port number of the other endpoint, an IP 5-tuple (e.g., {source IP address, destination IP address, source port, destination port, protocol}), a service flow identifier (ID), and / or other data associated with the session. The AF can forward the extracted information to the gateway device via the Policy and Charging Function (PCF) and / or the Session Management Function (SMF).

[0050] The gateway device can then extract information, identifying downlink data packets (e.g., RTP packets) by identifiers and extracting the PSSize, and optionally, the number of PDUs (if any). If necessary, the gateway device can further adjust the PSSize and add data representing the resulting PSSize to the GTP-U packet header of the GPRS Tunneling Protocol (GTP) GTP-U packet encapsulating the downlink data packet. GTP-U is an IP-based protocol used to carry user data within the GPRS core network between the Radio Access Network (RAN) and the core network. GTP-U can transmit packets using IPv4, IPv6, Point-to-Point Protocol (PPP), or any of these other tunneling transport formats.

[0051] Network interface 54 can receive selected media presentation and provide it to RTP receiving unit 52, which in turn can provide the media data to decapsulation unit 50. Decapsulation unit 50 can decapsulate the elements of a video file into a PES stream, unpack the PES stream to retrieve encoded data, and transmit the encoded data to audio decoder 46 or video decoder 48, depending on whether the encoded data is part of an audio stream or a video stream (e.g., as indicated by the PES packet header of the stream). Audio decoder 46 decodes the encoded audio data and transmits the decoded audio data to audio output 42, while video decoder 48 decodes the encoded video data and transmits the decoded video data (which may include multiple views of the stream) to video output 44.

[0052] The video encoder 28, video decoder 48, audio encoder 26, audio decoder 46, encapsulation unit 30, RTP receiver unit 52, and decapsulation unit 50 can all be implemented as any of a variety of suitable processing circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic circuits, software, hardware, firmware, or any combination thereof. Each of the video encoder 28 and video decoder 48 can be included in one or more encoders or decoders, and either the video encoder or the video decoder can be integrated as part of a combined video encoder / decoder (CODEC). Similarly, each of the audio encoder 26 and audio decoder 46 can be included in one or more encoders or decoders, and either the audio encoder or the audio decoder can be integrated as part of a combined CODEC. The apparatus including the video encoder 28, video decoder 48, audio encoder 26, audio decoder 46, encapsulation unit 30, RTP receiver unit 52, and / or decapsulation unit 50 can include integrated circuits, microprocessors, and / or wireless communication devices, such as cellular phones.

[0053] Client device 40, server device 60, and / or content preparation device 20 may be configured to operate according to the techniques of this disclosure. For illustrative purposes, these techniques are described with respect to client device 40 and server device 60. However, it should be understood that content preparation device 20 may also be configured to perform these techniques as an alternative to (or other than) server device 60.

[0054] Encapsulation unit 30 can form NAL units, which include a header identifying the program to which the NAL unit belongs and a payload, such as audio data, video data, or data describing the transport or program stream corresponding to the NAL unit. For example, in H.264 / AVC, a NAL unit includes a 1-byte header and a payload of varying size. NAL units whose payloads include video data can include video data at various granularities. For example, a NAL unit can include video data blocks, multiple blocks, video data slices, or entire frames of video data. Encapsulation unit 30 can receive encoded video data in PES packet format with elementary streams from video encoder 28. Encapsulation unit 30 can associate each elementary stream with its corresponding program.

[0055] The encapsulation unit 30 can also assemble access units based on multiple NAL units. Generally, an access unit may include one or more NAL units representing a video data frame, and the corresponding audio data (when the audio data is available). Access units typically include all NAL units for a single output time instance, such as all audio and video data for a single time instance. For example, if each view has a frame rate of 20 frames per second (fps), each time instance may correspond to a time interval of 0.05 seconds. During this time interval, specific frames for all views with the same access unit (same time instance) can be rendered simultaneously. In one example, an access unit may include a decoded image within a time instance, which can be rendered as the primary decoded image.

[0056] Therefore, the access unit can include all audio and video frames of a common time instance, such as those related to time. X All corresponding views. This disclosure also refers to the encoded image of a particular view as a "view component". That is, a view component may include an image (or frame) used for encoding a particular view at a particular time. Therefore, an access unit can be defined as all view components including a common time instance. The decoding order of the access units need not be the same as the output order or display order.

[0057] After the encapsulation unit 30 has assembled the NAL units and / or access units into a video file based on the received data, the encapsulation unit 30 passes the video file to the output interface 32 for output. In some examples, the encapsulation unit 30 may store the video file locally or transmit the video file to a remote server via the output interface 32, instead of transmitting the video file directly to the client device 40. The output interface 32 may include, for example, a transmitter, a transceiver, a device for writing data to a computer-readable medium (such as, for example, an optical drive, a magnetic media drive (e.g., a floppy disk drive)), a universal serial bus (USB) port, a network interface, or other output interface. The output interface 32 outputs the video file to a computer-readable medium, such as, for example, a transmitting signal, a magnetic medium, an optical medium, a memory, a flash drive, or other computer-readable media.

[0058] Network interface 54 can receive NAL units or access units via network 74 and provide NAL units or access units to decapsulation unit 50 via RTP receiving unit 52. Decapsulation unit 50 can decapsulate the elements of the video file into a PES stream, unpack the PES stream to retrieve encoded data, and transmit the encoded data to audio decoder 46 or video decoder 48, depending on whether the encoded data is part of an audio stream or a video stream (e.g., as indicated by the PES packet header of the stream). Audio decoder 46 decodes the encoded audio data and transmits the decoded audio data to audio output 42, while video decoder 48 decodes the encoded video data and transmits the decoded video data (which may include multiple views of the stream) to video output 44.

[0059] Figure 2 This is a block diagram illustrating the elements of example video file 150. As described above, video files, according to the ISO Basic Media File Format and its extensions, store data in a series of objects called "boxes". Figure 2 In the example, video file 150 includes a file type (FTYP) box 152, a movie (MOOV) box 154, a segment index (sidx) box 162, a movie clip (MOOF) box 164, and a movie clip random access (MFRA) box 166. Although Figure 2 The example shown is a video file, but it should be understood that other media files may include other types of media data (e.g., audio data, timed text data, etc.) constructed similarly to those in video file 150, depending on the ISO Basic Media File Format and its extensions.

[0060] The File Type (FTYP) box 152 generally describes the file type of the video file 150. The File Type box 152 may include data identifying the specifications for the best use of the video file 150. The File Type box 152 may optionally be placed before the MOOV box 154, the Movie Clip box 164, and / or the MFRA box 166.

[0061] exist Figure 2 In the example, MOOV box 154 includes a Movie Header (MVHD) box 156, a Track (TRAK) box 158, and one or more Movie Extension (MVEX) boxes 160. Generally, the MVHD box 156 can describe the general characteristics of the video file 150. For example, the MVHD box 156 may include data describing when the video file 150 was initially created, when the video file 150 was last modified, the timestamp of the video file 150, the playback duration of the video file 150, or other data generally describing the video file 150.

[0062] TRAK box 158 may include track data of video file 150. TRAK box 158 may include a Track Header (TKHD) box that describes the characteristics of the track corresponding to TRAK box 158. In some examples, TRAK box 158 may include decoded video images, while in other examples, the decoded video images of the track may be included in movie clip 164, which may be referenced by data from TRAK box 158 and / or sidx box 162.

[0063] In some examples, video file 150 may include more than one track. Therefore, MOOV box 154 may include TRAK boxes in a number equal to the number of tracks in video file 150. TRAK boxes 158 may describe the characteristics of the corresponding tracks in video file 150. For example, TRAK boxes 158 may describe the temporal and / or spatial information of the corresponding tracks. When encapsulation unit 30 ( Figure 1 When a parameter set track is included in a video file (such as video file 150), a TRAK box similar to the TRAK box 158 of the MOOV box 154 can describe the characteristics of the parameter set track. The encapsulation unit 30 can signal the presence of a sequence level SEI message in the parameter set track within the TRAK box describing the parameter set track.

[0064] The MVEX box 160 can describe the characteristics of the corresponding movie clip 164, for example, by signaling to the video file 150 that, in addition to the video data (if any) included in the MOOV box 154, the movie clip 164 is also included. In the context of streaming video data, decoded video images may be included in the movie clip 164 instead of the MOOV box 154. Therefore, all decoded video samples may be included in the movie clip 164 instead of the MOOV box 154.

[0065] MOOV boxes 154 may include an equal number of MVEX boxes 160 as the number of movie segments 164 in the video file 150. Each MVEX box in the MVEX boxes 160 may describe the characteristics of a corresponding movie segment in the movie segment 164. For example, each MVEX box may include a Movie Extended Header Box (MEHD) box, which describes the time duration of a corresponding movie segment in the movie segment 164.

[0066] As noted above, encapsulation unit 30 may store a set of sequence data in a video sample that does not include the actual decoded video data. The video sample may typically correspond to an access unit, which is a representation of a decoded picture at a specific time instance. In the context of AVC, the decoded picture includes one or more VCL NAL units (containing information about all pixels used to construct the access unit) and other associated non-VCL NAL units (such as SEI messages). Therefore, encapsulation unit 30 may include a set of sequence data in a movie clip of movie clip 164, which may include a sequence-level SEI message. Encapsulation unit 30 may also signal the presence of the set of sequence data and / or the sequence-level SEI message as being present in a movie clip of movie clip 164 within an MVEX box of MVEX box 160 corresponding to a movie clip of movie clip 164.

[0067] SIDX box 162 is an optional element of video file 150. That is, video files conforming to 3GPP file formats or other such file formats do not necessarily include SIDX box 162. According to the example of the 3GPP file format, SIDX boxes can be used to identify sub-segments of a segment (e.g., a segment contained within video file 150). The 3GPP file format defines a sub-segment as "a self-contained set of one or more consecutive movie clip boxes having a corresponding media data box and a media data box containing data referenced by a movie clip box that must follow that movie clip box and precede the next movie clip box containing information about the same track." The 3GPP file format also instructs that the SIDX box "contains a series of references to sub-segments of the (sub)segment recorded by that box. The referenced sub-segments are consecutive in presentation time. Similarly, bytes referenced by the segment index box are always consecutive within the segment. The size of the reference gives a count of the number of bytes in the referenced material."

[0068] SIDX box 162 typically provides information representing one or more sub-segments of a segment included in video file 150. For example, such information may include the playback time of the start and / or end of the sub-segment, the byte offset of the sub-segment, whether the sub-segment includes (e.g., begins at) a Stream Access Point (SAP), the type of SAP (e.g., whether the SAP is an Instant Decoder Refresh (IDR) picture, a Clean Random Access (CRA) picture, a Broken Link Access (BLA) picture, etc.), the location of the SAP within the sub-segment (in terms of playback time and / or byte offset), etc.

[0069] Movie clip 164 may include one or more decoded video pictures. In some examples, movie clip 164 may include one or more groups of pictures (GOPs), where each GOP may include several decoded video pictures, such as frames or images. Additionally, as described above, in some examples, movie clip 164 may include a sequence of data. Each movie clip in movie clip 164 may include a movie clip header box (MFHD). Figure 2 (Not shown in the image). The MFHD box can describe the characteristics of the corresponding movie clip, such as the movie clip's sequence number. Movie clips 164 can be included in video file 150 in the order of their sequence numbers.

[0070] MFRA box 166 can describe random access points within movie segments 164 of video file 150. This can help perform special effects modes, such as searching for specific time positions (i.e., playback times) within segments encapsulated by video file 150. In some examples, MFRA box 166 is typically optional and does not need to be included in the video file. Similarly, client devices (such as client device 40) do not necessarily need to refer to MFRA box 166 to correctly decode and display the video data of video file 150. MFRA box 166 can include a number equal to the number of tracks in video file 150, or in some examples, a number equal to the number of media tracks (e.g., non-cue tracks) in video file 150 (TFRA) boxes (not shown).

[0071] In some examples, movie clip 164 may include one or more streaming access points (SAPs), such as IDR pictures. Similarly, MFRA box 166 can provide an indication of the location within the SAP video file 150. Therefore, a temporal subsequence of video file 150 can be formed from the SAP of video file 150. The temporal subsequence may also include other pictures, such as SAP-dependent P-frames and / or B-frames. Frames and / or slices of the temporal subsequence can be arranged within segments such that frames / slices of the temporal subsequence that depend on other frames / slices of the subsequence can be correctly decoded. For example, in a hierarchical arrangement of data, data used for prediction of other data may also be included in the temporal subsequence.

[0072] Figure 3 This is a block diagram illustrating an example set of devices that can participate in media communication sessions according to the technology of this disclosure. Figure 3 The example depicts a User Equipment (UE) device 200, a gNodeB (gNB) device 212, an Intermediate User Plane Function (I-UPF) device 214, a UPF device 216 (which may also be referred to as a "gateway device"), a network 220, and a UE device 230. The UE device 200 may correspond to... Figure 1 The client device 40, and the UE device 230 can correspond to Figure 1 Content preparation equipment 20 and / or server equipment 60.

[0073] In this example, gNB device 212, I-UPF device 214, and UPF device 216 form part of radio access network (RAN) 210. In this example, UE device 200 represents an endpoint of RAN 210, gNB device 212 and I-UPF device 214 are included in the access network of RAN 210, and UPF device 216 is included in the core network of RAN 210. Network 220 may correspond to a data network, such as the Internet. UE device 230 may be communicatively coupled to a separate RAN (not shown) or communicatively coupled to network 220 via other access technologies such as Wi-Fi, Ethernet, etc.

[0074] In this example, UE device 200 and UE device 230 establish a media communication session 240, through which UE device 200 and UE device 230 exchange media data, such as audio data, image data, video data, text data, extended reality (XR) data (such as augmented reality (AR) data, mixed reality (MR) data, or virtual reality (VR) data), etc.

[0075] As part of establishing a media communication session 240, UE device 230 may transmit data to UE device 200 indicating the IP address type for UE device 230 and the maximum transmission unit (MTU) size for UE device 230. For example, UE device 230 may transmit Real-Time Transport Protocol (RTP) packets including an RTP header extension that includes data indicating the IP address type and MTU size. Additionally or alternatively, UE device 230 may transmit Session Description Protocol (SDP) messages specifying the IP address type and MTU size (e.g., SDP proposals or SDP responses).

[0076] According to the technology disclosed herein, UE device 200 can transmit data to UPF 216 representing the local IP address type for UE device 230 and the MTU size for UE device 230. For example, UE device 200 can transmit data directly to UPF 216, or UE device 200 can transmit data to an application function (AF) device to cause the AF device to forward the IP address type and MTU size to UPF 216. UPF 216 can use the IP address type and MTU size to recalculate the PSSize value for packets in media communication session 2140 from UE device 230 to UE device 200.

[0077] Therefore, when UPF 216 receives packets of a PDU set from UE device 230, UPF 216 can initially determine that the packets of the PDU set originate from UE device 230 by comparing the source IP address with the IP address for UE device 230. UPF 216 can then recalculate the PSSize value for the PDU set using the local IP address type and MTU size for UE device 230. UPF 216 can forward the packets of the PDU set to UE device 200 via I-UPF 214 and gNB device 212. For example, UPF 216 can encapsulate the packets with a GTP-U packet header to tunnel the packets to gNB device 212. UPF 216 can advertise the recalculated PSSize value for the packets in the GTP-U header. gNB device 212 can use the recalculated PSSize value advertised in the GTP-U header to, for example, allocate resources for delivering the packets of the PDU set to UE device 200.

[0078] Thus, UE device 200 represents an example of a user equipment (UE) device for exchanging media data via a network, comprising: a memory configured to store media data; and a processing system including one or more processors implemented in a circuit, the processing system being configured to: receive data from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; establish a media communication session with the second network device; transmit data representing the local IP address type and MTU size for the second network device to a gateway device of the RAN; and receive packets of Protocol Data Units (PDUs) derived from the media communication session of the second network device via the RAN.

[0079] Similarly, UPF device 216 represents an example of a gateway device for a radio access network (RAN), which includes: a memory configured to store network packets; and a processing system implemented in circuitry configured to: receive data representing a local Internet Protocol (IP) address type and a maximum transmission unit (MTU) size for a second network device from a user equipment (UE) device communicatively coupled to the RAN; receive a first data packet of a first Protocol Data Unit (PDU); determine that the source IP address of the first data packet matches the IP address of the second network device; adjust a PDU set size (PSSize) value based on the local IP address type, MTU size, and the number of PDUs for the first PDU; encapsulate the first data packet in a GPRS Tunneling Protocol (GTP-U) packet; add the adjusted PSSize value to the header of the GTP-U packet; and transmit the GTP-U packet to the UE device via the RAN.

[0080] Figure 4 This is a flowchart illustrating an example method for transmitting local / private address types according to the technology of this disclosure. In this example, device A represents a UE (e.g., Figure 1 Client device 40 or Figure 3 UE device 200), and device B represents a non-3GPP device, for example. Figure 1 60 server devices or 20 content preparation devices Figure 3 UE device 230. Figure 4 Other devices refer to 3GPP / 5G devices that perform various functions, such as NG-RAN, PCF, SMF, and UPF (e.g., gateway devices), as discussed above. Figure 4 The UPF can correspond to Figure 3 UPF 216. Figure 4 NG-RAN equipment can correspond to Figure 3 gNB device 212.

[0081] In this example, initially, device B sends an SDP proposal (250) containing the local IP address type and MTU size to device A. Device A responds to device B with an SDP acknowledgment (252). Device A then sends the local IP address type, public IP address, and MTU size to the NG-RAN, PCF, and / or SMF (254). Device B then sends the first data packet of the PDU set to the UPF (256).

[0082] Then, the UPF performs PSSize value adjustment (258) according to the techniques of this disclosure. Specifically, the UPF uses the public IP address of device B, such as that received from device A, to detect that the first data packet originates from device B. In response, the UPF adjusts the PSSize value based on the MTU size, the number of PDUs, and the local IP address type of device B. The UPF can then add the adjusted PSSize to the GTP-U packet header and transmit the GTP-U packet to the NG-RAN (260).

[0083] The NG-RAN (e.g., a base station such as a gNB, or other equipment in the RAN) can then use the PSSize value (262) when delivering packets of the PDU set to device A. For example, the NG-RAN can extract the adjusted PSSize and the first data packet received from the UPF. The NG-RAN can also allocate resources for the PDU set based on the adjusted PSSize header. The NG-RAN can then transmit the first data packet of the PDU set to device A (264).

[0084] Device B may later transmit a second data packet of the PDU set to the UPF (266). The UPF may generate an updated PSSize value and add the adjusted PSSize value to the header of the second GTP-U packet (268). The UPF may then transmit a second GTP-U packet carrying the second data packet to the NG-RAN (270).

[0085] NG-RAN can extract the second data packet (272) from the second GTP-U packet and transmit the second data packet (274) to device A.

[0086] so, Figure 4 The method represents an example of a method for exchanging media data over a network, including: a user equipment (UE) receiving data from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; the UE establishing a media communication session with the second network device; the UE transmitting data representing the local IP address type and MTU size for the second network device to a user plane function (UPF) device of the RAN; and the UE receiving packets of Protocol Data Unit (PDU) sets originating from the media communication session of the second network device via the RAN.

[0087] Figure 4 The method also represents an example of a method for exchanging media data over a network, comprising: receiving data representing the local Internet Protocol (IP) address type and maximum transmission unit (MTU) size for a second network device from a device performing a User Plane Function (UPF) and from a User Equipment (UE) device, wherein the device performing the UPF is within a Radio Access Network (RAN) to which the UE device is communicatively coupled; receiving a first data packet of a first Protocol Data Unit (PDU) by the device performing the UPF; determining that the source IP address of the first data packet matches the IP address of the second network device by the device performing the UPF; adjusting a PDU set size (PSSize) value by the device performing the UPF based on the local IP address type, MTU size, and the number of PDUs for the first PDU; encapsulating the first data packet in a GPRS Tunneling Protocol (GTP-U) packet by the device performing the UPF; adding the adjusted PSSize value to the header of the GTP-U packet by the device performing the UPF; and transmitting the GTP-U packet to the UE device via the RAN by the device performing the UPF.

[0088] Figure 5 This is a flowchart illustrating another example method for transmitting local / private address types according to the technology of this disclosure. In this example, it is assumed that two devices (device A and device B) with 5G / 3GPP capabilities communicate with each other, but are simultaneously connected to a separate 5G core (5GC) network. Device A may correspond to... Figure 1 Client device 40 or Figure 3 UE device 200, and device B can correspond to Figure 1 Content preparation equipment 20 and / or server equipment 60 or Figure 3 UE device 230. The first 5GC network (first RAN) for device A includes the first NG-RAN (e.g., Figure 3 gNB device 212), first AF and first UPF (e.g., Figure 3 The UPF 216), and the second 5GC network (second RAN) for device B includes the second NG-RAN, the second AF and the second UPF.

[0089] In this example, device B initially sends an SDP proposal (300) to device A containing the local IP address type and MTU size for device B. Device A responds to device B with an SDP response (302) containing the local IP address type and MTU size for device A.

[0090] Device A also transmits the local IP address type and MTU size for device B to the AF and UPF of the first 5GC (304), while device B transmits the local IP address type and MTU size for device A to the AF and UPF of the second 5GC (306).

[0091] In this example, device B then transmits a set of PDU data packets (308), which are received by the UPF of the first 5GC. The UPF of the first 5GC adjusts the PSSize value (310) and transmits a GTP-U packet (312) carrying the data packet and the adjusted PSSize value to the NG-RAN of the first 5GC.

[0092] The first 5GC's NG-RAN allocates resources (314) for the PDU set and transmits data packets (316) to device A.

[0093] Device A then transmits data packets (318) for a separate set of PDUs, which are received by the UPF of the second 5GC. The UPF of the second 5GC adjusts the PSSize (320) and transmits a second GTP-U packet (322) carrying the data packets from device A and the adjusted PSSize of the PDU set from device A to the NG-RAN of the second 5GC. The NG-RAN of the second 5GC allocates resources (324) for the PDU set from device A and transmits data packets (326) to device B.

[0094] so, Figure 5 The method represents an example of a method for exchanging media data over a network, including: a user equipment (UE) receiving data from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; the UE establishing a media communication session with the second network device; the UE transmitting data representing the local IP address type and MTU size for the second network device to a user plane function (UPF) device of the RAN; and the UE receiving packets of Protocol Data Unit (PDU) sets originating from the media communication session of the second network device via the RAN.

[0095] Figure 5 The method also represents an example of a method for exchanging media data over a network, comprising: receiving data representing the local Internet Protocol (IP) address type and maximum transmission unit (MTU) size for a second network device from a device performing a User Plane Function (UPF) and from a User Equipment (UE) device, wherein the device performing the UPF is within a Radio Access Network (RAN) to which the UE device is communicatively coupled; receiving a first data packet of a first Protocol Data Unit (PDU) by the device performing the UPF; determining that the source IP address of the first data packet matches the IP address of the second network device by the device performing the UPF; adjusting a PDU set size (PSSize) value by the device performing the UPF based on the local IP address type, MTU size, and the number of PDUs for the first PDU; encapsulating the first data packet in a GPRS Tunneling Protocol (GTP-U) packet by the device performing the UPF; adding the adjusted PSSize value to the header of the GTP-U packet by the device performing the UPF; and transmitting the GTP-U packet to the UE device via the RAN by the device performing the UPF.

[0096] The following clauses summarize various examples of the technology disclosed herein.

[0097] Clause 1: A method for exchanging media data over a network, the method comprising: receiving data from a second network device by a first network device, the data including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; transmitting data representing the local IP address type and the MTU size for the second network device to a User Plane Function (UPF) device by the first network device; and receiving packets of Protocol Data Unit (PDU) sets by the first network device.

[0098] Clause 2: According to the method of Clause 1, receiving the data including the local IP address type includes receiving either a Real-Time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the local IP address type for the second network device, and the SDP message specifying the local IP address type for the second network device.

[0099] Clause 3: The method according to any one of Clauses 1 and 2, wherein receiving the data including the MTU size includes receiving either a Real-time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the MTU size for the second network device, and the SDP message specifying the MTU size for the second network device.

[0100] Clause 4: The method according to any one of Clauses 2 and 3, wherein the RTP extended header includes data representing one or more of the following: the end PDU of the PDU set, the end of a data burst, the PDU set importance value for the PDU set, the PDU set sequence number for the PDU set, or the PDU set size (PSSize) value.

[0101] Clause 5: The method according to any one of Clauses 1 to 4, wherein receiving the data including the MTU size includes receiving an SDP message specifying the MTU size as a Session Description Protocol (SDP) attribute.

[0102] Clause 6: The method described in Clause 5, wherein the SDP attribute has "a=mtu: <mtu-size>The format is "", where mtu-size is the size of the MTU at the second network device.

[0103] Clause 7: The method according to any one of Clauses 5 and 6, wherein the SDP attribute expresses the MTU size in bytes or multiple bytes.

[0104] Clause 8: The method according to any one of Clauses 1 to 7, wherein transmitting the data representing the local IP address type and the MTU size for the second network device to the UPF device comprises transmitting the data representing the local IP address type and the MTU size for the second network device to an Application Function (AF) device, such that the AF device forwards the data representing the local IP address type and the MTU size for the second network device to the UPF device.

[0105] Clause 9: The method according to Clause 1, wherein receiving the data including the local IP address type includes receiving either a Real-Time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the local IP address type for the second network device, and the SDP message specifying the local IP address type for the second network device.

[0106] Clause 10: The method described in Clause 9, wherein the RTP extended header includes data representing one or more of the following: the end PDU of the PDU set, the end of a data burst, the PDU set importance value for the PDU set, the PDU set sequence number for the PDU set, or the PDU set size (PSSize) value.

[0107] Clause 11: The method according to Clause 1, wherein receiving the data including the MTU size includes receiving either a Real-time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the MTU size for the second network device, and the SDP message specifying the MTU size for the second network device.

[0108] Clause 12: The method described in Clause 11, wherein the RTP extended header includes data representing one or more of the following: the end PDU of the PDU set, the end of a data burst, the PDU set importance value for the PDU set, the PDU set sequence number for the PDU set, or the PDU set size (PSSize) value.

[0109] Clause 13: The method according to Clause 1, wherein receiving the data including the MTU size includes receiving an SDP message specifying the MTU size as a Session Description Protocol (SDP) attribute.

[0110] Clause 14: The method described in Clause 13, wherein the SDP attribute has "a=mtu: <mtu-size>The format is "", where mtu-size is the size of the MTU at the second network device.

[0111] Clause 15: The method described in Clause 14, wherein the SDP attribute expresses the MTU size in bytes or multiple bytes.

[0112] Clause 16: The method according to Clause 1, wherein transmitting the data representing the local IP address type and the MTU size for the second network device to the UPF device includes transmitting the data representing the local IP address type and the MTU size for the second network device to the Application Function (AF) device, so that the AF device forwards the data representing the local IP address type and the MTU size for the second network device to the UPF device.

[0113] Clause 17: A method for exchanging media data over a network, the method comprising: receiving, by a device performing a User Plane Function (UPF) and from a first network device, data representing a local Internet Protocol (IP) address type and a Maximum Transmission Unit (MTU) size for a second network device; receiving, by the device, a first data packet of a first Protocol Data Unit (PDU); determining, by the device, that the source IP address of the first data packet matches the IP address of the second network device; adjusting, by the device, a PDU Set Size (PSSize) value based on the local IP address type, the MTU size, and the number of PDUs for the first PDU; encapsulating, by the device, the first data packet in a GPRS Tunneling Protocol (GTP-U) packet; adding, by the device, the adjusted PSSize value to the header of the GTP-U packet; and transmitting, by the device, the GTP-U packet to the first network device.

[0114] Clause 18: The method according to Clause 17, wherein receiving the data representing the local IP address type and the MTU size includes receiving the local IP address type and the MTU size from a device performing an application function (AF), the device receiving the local IP address type and the MTU size from the first network device.

[0115] Clause 19: An apparatus for retrieving media data, the apparatus comprising one or more components for performing the method according to any one of Clauses 1 to 18.

[0116] Clause 20: The device according to Clause 19, wherein the one or more components include a processing system, the processing system including one or more processors implemented in a circuit.

[0117] Clause 21: The apparatus according to Clause 19, wherein the apparatus includes at least one of: an integrated circuit; a microprocessor; or a wireless communication device.

[0118] Clause 22: A computer-readable storage medium having instructions stored thereon, which, when executed, cause a processing system to perform the method according to any one of Clauses 1 to 18.

[0119] Clause 23: A first network device for exchanging media data via a network, the first network device comprising: means for receiving data from a second network device, the data including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; means for transmitting data representing the local IP address type and the MTU size for the second network device to a User Plane Function (UPF) device; and means for receiving packets of Protocol Data Unit (PDU) sets.

[0120] Clause 24: An apparatus for exchanging media data over a network, the apparatus performing a User Plane Function (UPF), the apparatus comprising: components for receiving data from a first network device representing a local Internet Protocol (IP) address type and a Maximum Transmission Unit (MTU) size for a second network device; components for receiving a first data packet of a first Protocol Data Unit (PDU); components for determining that the source IP address of the first data packet matches an IP address of the second network device; components for adjusting a PDU Set Size (PSSize) value based on the local IP address type, the MTU size, and the number of PDUs for the first PDU; components for encapsulating the first data packet in a GPRS Tunneling Protocol (GTP-U) packet; components for adding the adjusted PSSize value to the header of the GTP-U packet; and components for transmitting the GTP-U packet to the first network device.

[0121] Clause 25: A method for exchanging media data over a network, the method comprising: receiving data from a second network device via a radio access network (RAN) by a user equipment (UE) device, the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; establishing a media communication session between the UE device and the second network device; transmitting data representing the local IP address type and the MTU size for the second network device to a user plane function (UPF) device of the RAN by the UE device; and receiving packets of Protocol Data Unit (PDU) sets originating from the media communication session of the second network device via the RAN by the UE device.

[0122] Clause 26: The method according to Clause 25, wherein receiving the data including the local IP address type and the MTU size includes receiving either a Real-Time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the local IP address type and the MTU size for the second network device, and the SDP message specifying the local IP address type and the MTU size for the second network device.

[0123] Clause 27: The method according to Clause 26, wherein the RTP extended header includes data representing one or more of the following: the end PDU of the PDU set, the end of a data burst, the PDU set importance value for the PDU set, the PDU set sequence number for the PDU set, or the PDU set size (PSSize) value.

[0124] Clause 28: The method according to Clause 25, wherein receiving the data including the MTU size includes receiving an SDP message specifying the MTU size as a Session Description Protocol (SDP) attribute.

[0125] Clause 29: The method described in Clause 28, wherein the SDP attribute has "a=mtu: <mtu-size>The format is “”, where mtu-size corresponds to the MTU size for the second network device.

[0126] Clause 30: The method described in Clause 28, wherein the SDP attribute expresses the MTU size in bytes or multiple bytes.

[0127] Clause 31: The method according to Clause 25, wherein transmitting the data representing the local IP address type and the MTU size for the second network device to the UPF device includes transmitting the data representing the local IP address type and the MTU size for the second network device to the Application Function (AF) device, so that the AF device forwards the data representing the local IP address type and the MTU size for the second network device to the UPF device.

[0128] Clause 32: A user equipment (UE) device for exchanging media data via a network, the UE device comprising: a memory configured to store media data; and a processing system including one or more processors implemented in a circuit, the processing system being configured to: receive data from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; establish a media communication session with the second network device; transmit data representing the local IP address type and the MTU size for the second network device to a user plane function (UPF) device of the RAN; and receive packets of Protocol Data Unit (PDU) sets originating from the media communication session of the second network device via the RAN.

[0129] Clause 33: The UE device according to Clause 32, wherein, in order to receive the data including the local IP address type and the MTU size, the processing system is configured to receive either a Real-Time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the local IP address type and the MTU size for the second network device, and the SDP message specifying the local IP address type and the MTU size for the second network device.

[0130] Clause 34: The UE device according to Clause 33, wherein the RTP extended header includes data representing one or more of the following: the end PDU of the PDU set, the end of a data burst, the PDU set importance value for the PDU set, the PDU set sequence number for the PDU set, or the PDU set size (PSSize) value.

[0131] Clause 35: The UE device according to Clause 32, wherein, in order to receive the data including the MTU size, the processing system is configured to receive an SDP message specifying the MTU size as a Session Description Protocol (SDP) attribute.

[0132] Clause 36: The UE device as described in Clause 35, wherein the SDP attribute has "a=mtu: <mtu-size>The format is “”, where mtu-size corresponds to the MTU size for the second network device.

[0133] Clause 37: The UE device as described in Clause 35, wherein the SDP attribute expresses the MTU size in bytes or multiple bytes.

[0134] Clause 38: The UE device according to Clause 32, wherein, in order to transmit the data representing the local IP address type and the MTU size for the second network device to the UPF device, the processing system is configured to transmit the data representing the local IP address type and the MTU size for the second network device to the RAN Application Function (AF) device, so that the AF device forwards the data representing the local IP address type and the MTU size for the second network device to the UPF device.

[0135] Clause 39: A method for exchanging media data via a network, the method comprising: receiving, by a device performing a User Plane Function (UPF) and from a User Equipment (UE) device, data representing a local Internet Protocol (IP) address type and a Maximum Transmit Unit (MTU) size for a second network device, wherein the device performing the UPF is within a Radio Access Network (RAN) communicatively coupled to the UE device; receiving, by the device performing the UPF, a first data packet of a first Protocol Data Unit (PDU); and determining, by the device performing the UPF, the source IP address of the first data packet and... The second network device's IP address is matched; the device performing the UPF adjusts the PDU set size (PSSize) value based on the local IP address type, the MTU size, and the number of PDUs for the first PDU; the device performing the UPF encapsulates the first data packet in a GPRS Tunneling Protocol (GTP-U) packet; the device performing the UPF adds the adjusted PSSize value to the header of the GTP-U packet; and the device performing the UPF transmits the GTP-U packet to the UE device via the RAN.

[0136] Clause 40: The method according to Clause 39, wherein receiving the data representing the local IP address type and the MTU size includes receiving the local IP address type and the MTU size from a device performing an application function (AF), the device receiving the local IP address type and the MTU size from the UE device.

[0137] Clause 41: An apparatus for performing user plane functions (UPF) of a radio access network (RAN), the apparatus comprising: a memory configured to store network packets; and a processing system implemented in circuitry, the processing system being configured to: receive data representing a local Internet Protocol (IP) address type and a maximum transmission unit (MTU) size for a second network device from a user equipment (UE) device communicatively coupled to the RAN; receive a first data packet of a first Protocol Data Unit (PDU); determine that the source IP address of the first data packet matches the IP address of the second network device; adjust a PDU set size (PSSize) value based on the local IP address type, the MTU size, and the number of PDUs for the first PDU; encapsulate the first data packet in a GPRS Tunneling Protocol (GTP-U) packet; add the adjusted PSSize value to the header of the GTP-U packet; and transmit the GTP-U packet to the UE device via the RAN.

[0138] Clause 42: The device according to Clause 41, wherein in order to receive the data representing the local IP address type and the MTU size, the processing system is configured to receive the local IP address type and the MTU size from the device performing the application function (AF), the device receiving the local IP address type and the MTU size from the UE device.

[0139] In one or more examples, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a computer-readable medium or transmitted via a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium (which corresponds to a tangible medium such as a data storage medium) or a communication medium, including, for example, any medium that facilitates the transfer of a computer program from one place to another according to a communication protocol. Thus, a computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to extract instructions, code, and / or data structures for implementing the techniques described in this disclosure. Computer program products may include computer-readable media.

[0140] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other medium capable of storing desired program code in the form of instructions or data structures and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies (such as infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies (such as infrared, radio, and microwave) are included in the definition of medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but instead refer to non-transient tangible storage media. As used herein, disks and optical discs include: compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. The combinations described above should also be included within the scope of computer-readable media.

[0141] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, as used herein, the term "processor" can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein can be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into combined codecs. Furthermore, these techniques can be fully implemented in one or more circuit or logic elements.

[0142] The techniques disclosed herein can be implemented in a wide variety of devices or apparatuses, including wireless mobile phones, integrated circuits (ICs), or IC sets (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but implementation by different hardware units is not necessarily required. Specifically, as described above, various units may be combined within a codec hardware unit, or may be provided by a collection of interoperable hardware units (including one or more processors as described above) combined with appropriate software and / or firmware.

[0143] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

1. A method for exchanging media data via a network, the method comprising: Data is received by a user equipment (UE) device from a second network device via a radio access network (RAN), the data from the second network device including a local Internet Protocol (IP) address type for the second network device and a maximum transmission unit (MTU) size for the second network device; The UE device establishes a media communication session with the second network device; The UE device transmits data representing the local IP address type and the MTU size for the second network device to the gateway device associated with the RAN; as well as The UE device receives packets of Protocol Data Unit (PDU) sets from the media communication session originating from the second network device via the RAN.

2. The method of claim 1, wherein receiving the data including the local IP address type and the MTU size includes receiving either a Real-Time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the local IP address type and the MTU size for the second network device, and the SDP message specifying the local IP address type and the MTU size for the second network device.

3. The method of claim 2, wherein the RTP extended header includes data representing one or more of the following: the end PDU of the PDU set, the end of a data burst, the PDU set importance value for the PDU set, the PDU set sequence number for the PDU set, or the PDU set size (PSSize) value.

4. The method of claim 1, wherein receiving the data including the MTU size includes receiving an SDP message specifying the MTU size as a Session Description Protocol (SDP) attribute.

5. The method of claim 4, wherein the SDP attribute includes "a=mtu: <mtu-size> The format is “”, where mtu-size corresponds to the MTU size for the second network device.

6. The method of claim 4, wherein the SDP attribute expresses the MTU size in bytes or multiple bytes.

7. The method of claim 1, wherein transmitting the data representing the local IP address type and the MTU size for the second network device to the gateway device comprises transmitting the data representing the local IP address type and the MTU size for the second network device to an application function (AF) device, such that the AF device forwards the data representing the local IP address type and the MTU size for the second network device to the gateway device.

8. A user equipment (UE) device for exchanging media data over a network, the UE device comprising: A memory configured to store media data; and A processing system comprising one or more processors implemented in a circuit, the processing system being configured to: Data is received from a second network device via a radio access network (RAN), the data from the second network device including the local Internet Protocol (IP) address type for the second network device and the maximum transmission unit (MTU) size for the second network device; Establish a media communication session with the second network device; Data representing the local IP address type and MTU size for the second network device is transmitted to the gateway device associated with the RAN; as well as The RAN receives packets of Protocol Data Units (PDUs) from the media communication session originating from the second network device.

9. The UE device of claim 8, wherein, in order to receive the data including the local IP address type and the MTU size, the processing system is configured to receive either a Real-Time Transport Protocol (RTP) packet or a Session Description Protocol (SDP) message, the RTP packet including an RTP header extension specifying the local IP address type and the MTU size for the second network device, and the SDP message specifying the local IP address type and the MTU size for the second network device.

10. The UE device of claim 9, wherein the RTP extended header includes data representing one or more of the following: the end PDU of the PDU set, the end of a data burst, a PDU set importance value for the PDU set, a PDU set sequence number for the PDU set, or a PDU set size (PSSize) value.

11. The UE device of claim 8, wherein, in order to receive the data including the MTU size, the processing system is configured to receive an SDP message specifying the MTU size as a Session Description Protocol (SDP) attribute.

12. The UE device of claim 11, wherein the SDP attribute includes "a=mtu: <mtu-size> The format is “”, where mtu-size corresponds to the MTU size for the second network device.

13. The UE device of claim 11, wherein the SDP attribute expresses the MTU size in bytes or multiple bytes.

14. The UE device of claim 8, wherein, in order to transmit the data representing the local IP address type and the MTU size for the second network device to the gateway device, the processing system is configured to transmit the data representing the local IP address type and the MTU size for the second network device to the RAN application function (AF) device, such that the AF device forwards the data representing the local IP address type and the MTU size for the second network device to the gateway device.

15. A method for exchanging media data via a network, the method comprising: The gateway device receives data from the user equipment (UE) device representing the local Internet Protocol (IP) address type and maximum transmission unit (MTU) size for a second network device, wherein the gateway device is within the radio access network (RAN) to which the UE device is communicatively coupled; The gateway device receives a first data packet of a first protocol data unit (PDU); The gateway device determines that the source IP address of the first data packet matches the IP address of the second network device; The gateway device adjusts the PDU set size (PSSize) value based on the local IP address type, the MTU size, and the number of PDUs for the first PDU. The gateway device encapsulates the first data packet in a GPRS Tunneling Protocol (GTP-U) packet; The gateway device adds the adjusted PSSize value to the header of the GTP-U packet; as well as The gateway device transmits the GTP-U packet to the UE device via the RAN.

16. The method of claim 15, wherein receiving the data representing the local IP address type and the MTU size includes receiving the local IP address type and the MTU size from a device performing an application function (AF), the device receiving the local IP address type and the MTU size from the UE device.

17. A gateway device for a radio access network (RAN), the gateway device comprising: A memory configured to store network packets; and A processing system implemented in a circuit, the processing system being configured to: The user equipment (UE) device, coupled to the RAN, receives data indicating the local Internet Protocol (IP) address type and maximum transmission unit (MTU) size for the second network device; Receive the first data packet of the first Protocol Data Unit (PDU); Determine that the source IP address of the first data packet matches the IP address of the second network device; The PDU set size (PSSize) value is adjusted based on the local IP address type, the MTU size, and the number of PDUs for the first PDU. The first data packet is encapsulated in a GPRS Tunneling Protocol (GTP-U) packet; Add the adjusted PSSize value to the header of the GTP-U packet; as well as The GTP-U packet is transmitted to the UE device via the RAN.

18. The device of claim 17, wherein, in order to receive the data representing the local IP address type and the MTU size, the processing system is configured to receive the local IP address type and the MTU size from a device performing an application function (AF), the device receiving the local IP address type and the MTU size from the UE device.

Images