DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/13/2025 and 05/09/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 6-11 and 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over Stoica et al. (2026/0129110), Stoica hereinafter, in view of 3GPP TS 26.522 V0.1.1 (2023-08), 3GPP TS 26.522_ V0.1.1, hereinafter.
Re. claims 1 and 8, Stoica teaches a method of exchanging media data via a network (Fig. 10-12 & ¶0104¶0106/¶0118/¶0140-¶0141), and a user equipment (UE) (Fig. 16) device for exchanging media data (Fig. 10-12 & ¶0104¶0106/¶0118/¶0140-¶0141) via a network (Fig. 10), the UE device comprising: a memory (Fig. 16, 1604) configured to store media data; and a processing system comprising one or more processors (Fig. 16, 1602) implemented in circuitry, the processing system being configured to: receive data from a second network device via a radio access network (RAN) (Fig. 10-12 & ¶0104 - In DL, the PCF 1002 decides on the PCC rules for a QoS flow and PDU set awareness (i.e., RTP header extension configuration capturing RTP header extensions containing PDU set information) based on requirements provided by an AF 1004 over the NEF/PCF interface for or based on operator configuration for a particular type of application, e.g., XR, CG etc. The PCC rules include information to enable PDU set filtering based on application in-band signaling of PDU set information via RTP header extensions. Fig. 10-12 & ¶0105 - The PCC rules with PDU set-aware policies are sent to the SMF 1006 over the N7 interface which in turns establishes a QoS flow and provides further N4 rules to the UPF 1008, instructing the UPF 1008 to enable PDU set filtering and QoS mapping to a particular QoS flow given the PDU set acquired information from the RTP header extensions as signaled by the AS 1010 over N6 user plane interface. The UPF 1008 extracts the PDU set awareness and encapsulates the latter with the PDU set payloads within GTP-U headers of the selected QoS flow given the PDU set information and QoS rules with PDU set awareness. The user plane data is transferred to the RAN 1012 over the N3 reference point. The RAN 1012 applies the AMF 1014 signaled QoS profile information via the SM container which includes the new PDU set awareness acquired over the GTP-U headers. The RAN 1012 handles the mapping of the QoS flows to specific DRBs according to the QoS rules and the available PDU set information to fulfill QoS requirements of the application, including 5QIs, PSDB, and PSER constraints), 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 (Fig. 10-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC, or alternatively, dynamically determined based on ICMP and MTU path discovery procedures. Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. In this flow, the application further provides the RTP stack control to the UDP socket and UDP socket configuration. Consequently, the RTP stack can further determine necessary socket options, i.e., IP version of the transport layer, to determine the protocol headers overhead on the PDU set size. Thus, an RTP stack with PDU set marking capabilities can be aware of the UDP/IP header overhead per packet and take it into account in determining the PDU set size while performing RTP fragmentation and packetization. As such, the RTP stack uses this information with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PDU set size field in Bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU set. In one example, if UDP/IPv4 is used to transport the RTP packets of the application RTP sender the RTP stack can determine an overhead of 20 Bytes (IPv4)+8 Bytes (UDP)=28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6)+8 Bytes (UDP)=48 Bytes per RTP packet. As a result, the RTP stack can so compute the PDU set size in bytes corresponding to the PDU set size including RTP payload size and the additional UDP/IP protocol headers overheads. This information can in return be signaled further downstream to other media-aware network nodes, or alternatively, to one or more receivers in band for each PDU set as part of a PDU set RTP header extension); establish a media communication session with the second network device (Fig. 10-12 & ¶0106 - In UL, the UE 1016 negotiates within the session management (i.e., establishment, update operations) process the PDU set and PDU set information determination and associated signaling via RTP header extensions. This may include direct signaling via AMF 1014 from the SMF 1006 of PDU set filtering policies and QoS rules associated with PDU sets. A PDU set-aware UE 1016 applies the QoS rules and the PDU set policies to process incoming media (including encoding) and determine the PDU set and PDU set information at runtime. Post-packetization of the PDU set and PDU set information into RTP PDUs and RTP header extensions, the UE 1016 will transmit in the UL the data over the Uu interface to the RAN 1012. In doing so, the UE 1016 will further signal its PDU set awareness by selecting a DRB given the SMF QoS rules, PDU set policies and its acquired PDU set awareness. The RAN 1012 will in turn remap the selected DRBs to QoS flows based on SDAP processing of UL data from the UE 1016 and based on the QoS rules and PDU set policies received from the SMF 1006 via the AMF 1014 over the N2 reference point. As a result, the RAN 1012 will transmit uplink data to the UPF 1008 via the N3 interface over an optimized QoS flow and the UPF 1008 will in turn communicate the data with a remote data network over the N6 interface.); and receive packets of a protocol data unit (PDU) set of the media communication session originating from the second network device via the RAN (Fig. 10-12 & ¶0005 - method and apparatuses … receive an RTP PDU set, an RTP PDU comprising an extension header with an extension header element comprising PDU set information and a PDU payload, extract the PDU set information from the extension header element for each RTP PDU of the PDU set, the PDU set information comprising identifiers for the PDU set and the PDUs within the PDU set, and a set of PDU set attributes of the PDU set, packetize each of the RTP PDUs of the PDU set and the corresponding PDU set information within a general packet radio service (GPRS) tunnelling protocol for user plane (GTP-U) PDU, the GTP-U PDU comprising each of the RTP PDUs of the PDU set encapsulated as a GTP-U payload and each of the corresponding PDU set information encapsulated as a GTP-U header field, and transmit the GTP-U encapsulated PDU set and corresponding PDU set information. Fig. 10-12 & ¶0140 - The PDU set information is formed in an embodiment by a common information shared by all the PDUs within a PDU set (e.g., PDU set identifier 1202, PDU set size 1204, PDU set reference list flag 1216, PDU set temporal/spatial layer ID 1218, 1220, etc.), and a PDU-specific information (e.g., PDU sequence number 1206, PDU set start flag 1208, PDU set stop flag 1210), …. the PDU set information includes the identification of the PDU set and of the PDUs within the PDU set, and a set of attributes of the PDU set. … the PDU set identification data and the set of attributes of the PDU set are PDUs-common information of the PDU set, whereas the identification data of the PDUs within the PDU set is PDU-specific PDU set information. Fig. 10-12 & ¶0141 - each RTP PDU of a PDU set contains an RTP header extension including an RTP header extension element that consists of corresponding PDU set information data, i.e., both PDUs-common and the PDU-specific PDU set information of the RTP PDU. Also, see ¶0104-¶0105).
Yet, Stoica does not expressly teach send data representing the local IP address type and the MTU size for the second network device to a gateway device associated with the RAN;
However, in the analogous art, 3GPP TS 26.522_ V0.1.1 explicitly discloses send data representing the local IP address type and the MTU size for the second network device to a gateway device associated with the RAN (§4.4.2.1 - The RTP Header Extension for PDU Set marking can be used by an AS (e.g., MRF) or a sender UE that sends media to a receiver UE over RTP. §4.4.2.6.3 - The PDU Set Size value of a PDU Set should be determined by the RTP sender based on the RTP payload corresponding to the PDU Set, transmission path MTU Size, or alternatively, maximum RTP SDU size, and network IP transport configuration. The RTP sender should follow the corresponding steps in determining the PDU Set Size. Step 1 - The RTP sender should receive from a media encoder (e.g., a H.264 encoder, a H.265 encoder) an RTP payload corresponding to a PDU Set. The size of the received RTP payload (R) should be determined in bytes. Step 2 - The RTP sender should perform next RTP fragmentation and packetization of the RTP payload. The maximum size of an RTP packet SDU (S) should be determined given a transmission path MTU size, or alternatively, a preconfigured maximum RTP SDU payload size less than the path MTU size. Step 4 - The RTP sender should further determine per RTP packet the size of the UDP/IP headers overhead associated with an OS UDP socket sending out the RTP packets. This may be done by the RTP sender using UDP socket options available programmatically over OS network stack API calls or based on SDP-configured IP endpoints and corresponding transmission IP addresses. The RTP sender should determine the type of the underlying IP version used for transport, i.e., IPv4 or IPv6, and determine accordingly the IP header overhead (Ih_p) for each encapsulated RTP packet. If IPv4 options are configured for the UDP socket, or alternatively, if IPv6 header extensions are sent over the UDP socket, the RTP sender should consider the additional incurred size these have to the IP header overhead (Ih_p) of each RTP packet. The RTP sender should consider a fixed size UDP header overhead (Uh) of 8 bytes for each RTP packet…. In case no IPv4 header options are used, the RTP sender should consider Ih_p corresponding to 20 bytes per RTP packet for IPv4. Whereas, in case no IPv6 extension headers are used, the RTP sender should consider Ih_p corresponding to 40 bytes per RTP packet for IPv6. Step 5 - The RTP sender should determine the PDU Set Size as the sum in bytes of all RTP/UDP/IP headers overhead of each one of the P packets and the received RTP payload corresponding to the PDUs of the PDU Set, e.g., PSSize =R +
∑
p
=
1
P
(Ih_p + Uh_p + Rh_p) . The value should be indicated in the PSSize field of the RTP HE for PDU Set marking for all PDUs of the PDU Set before the corresponding RTP PDUs are sent over the UDP socket. §A.2 RTP payload - The PDU Set information identification based on the RTP payload format is present in this clause, including the RTP payload format for H.264/AVC and H.265/HEVC codecs. It is assumed that the 5GC (i.e. UPF) is aware of the RTP payload format in advance);
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Stoica’s invention of a system and a method for PDU < protocol data unit > set-aware multimedia applications and associated signaling in a 5G/NR <New Radio> wireless communication system to include 3GPP TS 26.522_ V0.1.1’s invention of Multiple Simultaneous RTP < Real-Time Transport Protocol> Streams in an RTP Session in a wireless communication system, because it provides an efficient mechanism for an RTP sender in determining a type of underlying IP version used for transport i.e., IPv4 or IPv6, , subsequently enables in determining an IP header overhead for each encapsulated RTP packet, in turns, helps in determining per RTP packet size of UDP/IP headers overhead in RTP transmission/reception in the wireless communication system. (§4.4.2.6.3, 3GPP TS 26.522_ V0.1.1)
Re. Claims 2 and 9, Stoica and 3GPP TS 26.522_ V0.1.1 teach claims 1 and 8.
Stoica further teaches wherein receiving the data including the local IP address type and the MTU size comprises receiving one of a Real-time Transport Protocol (RTP) packet including an RTP header extension specifying the local IP address type for the second network device and the MTU size or a Session Description Protocol (SDP) message specifying the local IP address type for the second network device and the MTU size. (Fig. 10-12 & ¶0117 - a PDU set-aware media application running acts as an RTP sender. The RTP sender determines based as per the above details and FIG. 11 an RTP payload size, i.e., the size of one or more ADUs produced by a media encoder. The RTP payload available in the RTP sender input buffer is further passed on to the RTP protocol stack implemented in the user space of an Operation System. The application further enables based on an application or network configuration the PDU set feature and informs the RTP stack of it requesting additional PDU set information (e.g., PDU set sequence number, PDU sequence within PDU set, PDU set size, PDU set end marker, PDU set importance etc.). to the RTP payload. Fig. 10-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC, or alternatively, dynamically determined based on ICMP and MTU path discovery procedures. Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. In this flow, the application further provides the RTP stack control to the UDP socket and UDP socket configuration. Consequently, the RTP stack can further determine necessary socket options, i.e., IP version of the transport layer, to determine the protocol headers overhead on the PDU set size. Thus, an RTP stack with PDU set marking capabilities can be aware of the UDP/IP header overhead per packet and take it into account in determining the PDU set size while performing RTP fragmentation and packetization. As such, the RTP stack uses this information with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PDU set size field in Bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU set. In one example, if UDP/IPv4 is used to transport the RTP packets of the application RTP sender the RTP stack can determine an overhead of 20 Bytes (IPv4)+8 Bytes (UDP)=28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6)+8 Bytes (UDP)=48 Bytes per RTP packet. As a result, the RTP stack can so compute the PDU set size in bytes corresponding to the PDU set size including RTP payload size and the additional UDP/IP protocol headers overheads. This information can in return be signaled further downstream to other media-aware network nodes, or alternatively, to one or more receivers in band for each PDU set as part of a PDU set RTP header extension).
Re. Claims 3 and 10, Stoica and 3GPP TS 26.522_ V0.1.1 teach claims 2 and 9.
Stoica further teaches wherein the RTP extension header includes data representing one or more of an end PDU of the PDU set, an end of 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. (Fig. 10-12 & ¶0126 - a PDU set information can therefore be formed of a combination of a PDU set identifier field, a PDU sequence number field, a PDU set start marker field, a PDU set end marker field, a PDU set size field, a PDU set importance marker field, a PDU set discarding marker bit field, a PDU set error resilience information field, and a PDU set reference field containing a list of references to one or more PDU sets sequence numbers/identifiers. Fig. 10-12 & ¶0127 - PDU set size may be signaled in an absolute unit, such as bits, bytes, words etc., or alternatively, may be indicated relative to the concept of PDUs within a PDU set, as the number of PDUs that form the PDU set. Fig. 10-12 & ¶0129 - A ‘PDU set identifier’ field 1202 enclosing a PDU set sequence number meant to identify the PDU set. In an example, the PDU set sequence number is associated with a RTP media flow and the first value of the PDU set sequence number is ‘1’, whereby ‘0’ is RESERVED. This is incremented by ‘1’ with each subsequent PDU set generated by the media encoder associated with the RTP media flow, irrespective of the temporal or spatial layer of the encoded ADU. In one example, this field may be encoded within 16 bits. Fig. 10-12 & ¶0130 - A ‘PDU set size’ 1204 indicating the size of the PDU set in number of PDUs grouped within the PDU set spanning for example an encoding over 8 bits. In another example this field may indicate the PDU set size in terms of bytes spanning in one example a width of 32 bits. The latter example may comprise in some implementations the PDU set size in bytes including the RTP/UDP/IP encapsulation. Fig. 10-12 & ¶0131 - A ‘PDU sequence number’ 1206 identifying the PDUs forming a PDU set and aiding their in-sequence delivery. In one example this field may span a width of 8 bits limiting a PDU set to contain a maximum number of 256 PDUs, in line with the ‘PDU set size’ value encoding the PDU set size in the number of enclosed PDUs. Fig. 10-12 & ¶0134 - A ‘PDU set importance’ bit field 1212 indicating a binary importance value for the PDU set, for example a value of ‘1’ indicating a HIGH importance PDU set (i.e., corresponding to an intra-decodable frame/slice, intra-frame, keyframe for VP8/9, IDR for H.264, IDR/CRA/BLA/RAP for H.265 etc.), and a value of ‘0’ indicating a LOW/DEFAULT importance PDU set (i.e., corresponding to inter-decodable frame/slice, inter-frame, non-keyframe for V8/9, non-IDR for H.264 etc.).)
Re. Claims 4 and 11, Stoica and 3GPP TS 26.522_ V0.1.1 teach claims 1 and 8.
Stoica further teaches wherein receiving the data including the MTU size comprises receiving a Session Description Protocol (SDP) message specifying the MTU size as an SDP attribute. (Fig.6-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC,… Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. Fig.6-12 & ¶0121 - extracted PDU set information is signaled together with the RTP PDUs encapsulating the PDUs of the PDU set. In such examples, the PDU set information is enclosed within an RTP extension header element of fixed size injected by the media packetizer into the final RTP PDU stream, as outlined by FIG. 8. In these examples, the RTP extension header is enabled by means of SDP offer/answer procedure and the configuration is available to the media packetizer. In addition, the packetization considers in mapping the ADU to PDUs of a PDU set the length of the RTP extension header element together with the length of other SDP-enabled RTP extension headers given the MTU size constraint.)
Re. Claims 6 and 13, Stoica and 3GPP TS 26.522_ V0.1.1 teach claims 4 and 11.
Stoica further teaches wherein the SDP attribute expresses the MTU size in bytes or in a multiple of bytes. (Fig.6-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC,.. Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure.)
Re. Claims 7 and 14, Stoica and 3GPP TS 26.522_ V0.1.1 teach claims 1 and 8.
Stoica further teaches wherein sending the data representing the local IP address type and the MTU size for the second network device to the gateway device comprises sending the data representing the local IP address type and the MTU size for the second network device to an application function (AF) device to cause the AF device to forward the data representing the local IP address type and the MTU size for the second network device to the gateway device. (Fig. 10-12 & ¶0107 - PDU set information determination with uniform processing and logic on both server and client sides: interoperable in-band signaling procedure between an AS and 5GS UPF entity over N6 over well-established RTP and WebRTC transport protocols; and reduced processing complexity of UPF/5GS implementation for DL/UL PDU set-aware QoS integrated handling where, in DL, the UPF needs to identify PDU sets based on in-band indication over RTP header extensions coming from an AS by applying a PDU set aware packet filter associated with a 5 tuple for a service data flow of an application and where, in UL, the legacy SDAP based DRB selection mechanisms can be used by a PDU set-aware UE given PDU set-aware QoS rules are negotiated and established over the control plane by the AF. Fig. 10-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC, or alternatively, dynamically determined based on ICMP and MTU path discovery procedures. Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. In this flow, the application further provides the RTP stack control to the UDP socket and UDP socket configuration. Consequently, the RTP stack can further determine necessary socket options, i.e., IP version of the transport layer, to determine the protocol headers overhead on the PDU set size. Thus, an RTP stack with PDU set marking capabilities can be aware of the UDP/IP header overhead per packet and take it into account in determining the PDU set size while performing RTP fragmentation and packetization. As such, the RTP stack uses this information with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PDU set size field in Bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU set. In one example, if UDP/IPv4 is used to transport the RTP packets of the application RTP sender the RTP stack can determine an overhead of 20 Bytes (IPv4)+8 Bytes (UDP)=28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6)+8 Bytes (UDP)=48 Bytes per RTP packet. As a result, the RTP stack can so compute the PDU set size in bytes corresponding to the PDU set size including RTP payload size and the additional UDP/IP protocol headers overheads. This information can in return be signaled further downstream to other media-aware network nodes, or alternatively, to one or more receivers in band for each PDU set as part of a PDU set RTP header extension.)
Re. claims 15 and 17, Stoica teaches a method of exchanging media data via a network (Fig. 10-12 & ¶0104¶0106/¶0118/¶0140-¶0141), and a gateway device (UPF, 1008 in Fig. 10/Fig. 18) of a radio access network (RAN) (Fig. 10), the gateway device comprising: a memory (Fig. 18, 1804) configured to store network packets (Fig. 18 & ¶0191-¶0195); and a processing system (1802, Fig. 18) implemented in circuitry, the processing system being configured to: receive a first data packet of a first protocol data unit (PDU) (Fig. 10-12 & ¶0106 - In UL, the UE 1016 negotiates within the session management (i.e., establishment, update operations) process the PDU set and PDU set information determination and associated signaling via RTP header extensions. This may include direct signaling via AMF 1014 from the SMF 1006 of PDU set filtering policies and QoS rules associated with PDU sets. A PDU set-aware UE 1016 applies the QoS rules and the PDU set policies to process incoming media (including encoding) and determine the PDU set and PDU set information at runtime. Post-packetization of the PDU set and PDU set information into RTP PDUs and RTP header extensions, the UE 1016 will transmit in the UL the data over the Uu interface to the RAN 1012. In doing so, the UE 1016 will further signal its PDU set awareness by selecting a DRB given the SMF QoS rules, PDU set policies and its acquired PDU set awareness. The RAN 1012 will in turn remap the selected DRBs to QoS flows based on SDAP processing of UL data from the UE 1016 and based on the QoS rules and PDU set policies received from the SMF 1006 via the AMF 1014 over the N2 reference point. As a result, the RAN 1012 will transmit uplink data to the UPF 1008 via the N3 interface over an optimized QoS flow and the UPF 1008 will in turn communicate the data with a remote data network over the N6 interface); determine that a source IP address of the first data packet matches an IP address of the second network device (Fig. 10-12 & ¶0118 - RTP stack can further determine necessary socket options, i.e., IP version of the transport layer, to determine the protocol headers overhead on the PDU set size. Thus, an RTP stack with PDU set marking capabilities can be aware of the UDP/IP header overhead per packet and take it into account in determining the PDU set size while performing RTP fragmentation and packetization. As such, the RTP stack uses this information with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PDU set size field in Bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU set. In one example, if UDP/IPv4 is used to transport the RTP packets of the application RTP sender the RTP stack can determine an overhead of 20 Bytes (IPv4)+8 Bytes (UDP)=28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6)+8 Bytes (UDP)=48 Bytes per RTP packet. As a result, the RTP stack can so compute the PDU set size in bytes corresponding to the PDU set size including RTP payload size and the additional UDP/IP protocol headers overheads. This information can in return be signaled further downstream to other media-aware network nodes, or alternatively, to one or more receivers in band for each PDU set as part of a PDU set RTP header extension.); adjust a PDU set size value (PSSize) value based on the local IP address type, the MTU size, and a number of PDUs for the first PDU (Fig. 10-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC, or alternatively, dynamically determined based on ICMP and MTU path discovery procedures. Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. In this flow, the application further provides the RTP stack control to the UDP socket and UDP socket configuration. Consequently, the RTP stack can further determine necessary socket options, i.e., IP version of the transport layer, to determine the protocol headers overhead on the PDU set size. Thus, an RTP stack with PDU set marking capabilities can be aware of the UDP/IP header overhead per packet and take it into account in determining the PDU set size while performing RTP fragmentation and packetization. As such, the RTP stack uses this information with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PDU set size field in Bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU set. In one example, if UDP/IPv4 is used to transport the RTP packets of the application RTP sender the RTP stack can determine an overhead of 20 Bytes (IPv4)+8 Bytes (UDP)=28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6)+8 Bytes (UDP)=48 Bytes per RTP packet. As a result, the RTP stack can so compute the PDU set size in bytes corresponding to the PDU set size including RTP payload size and the additional UDP/IP protocol headers overheads. This information can in return be signaled further downstream to other media-aware network nodes, or alternatively, to one or more receivers in band for each PDU set as part of a PDU set RTP header extension. Also, see claims 1 and 5 & ¶0130); encapsulate the first data packet in a GPRS tunneling protocol (GTP-U) packet (Fig. 6- 12 & ¶0005 - method and apparatuses …. receive an RTP PDU set, an RTP PDU comprising an extension header with an extension header element comprising PDU set information and a PDU payload, extract the PDU set information from the extension header element for each RTP PDU of the PDU set, the PDU set information comprising identifiers for the PDU set and the PDUs within the PDU set, and a set of PDU set attributes of the PDU set, packetize each of the RTP PDUs of the PDU set and the corresponding PDU set information within a general packet radio service (GPRS) tunnelling protocol for user plane (GTP-U) PDU, the GTP-U PDU comprising each of the RTP PDUs of the PDU set encapsulated as a GTP-U payload and each of the corresponding PDU set information encapsulated as a GTP-U header field, and transmit the GTP-U encapsulated PDU set and corresponding PDU set information. Also, see step 2015 in Fig. 20); add the adjusted PSSize value to a header of the GTP-U packet (Fig. 10-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC, or alternatively, dynamically determined based on ICMP and MTU path discovery procedures. Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. In this flow, the application further provides the RTP stack control to the UDP socket and UDP socket configuration. Consequently, the RTP stack can further determine necessary socket options, i.e., IP version of the transport layer, to determine the protocol headers overhead on the PDU set size. Thus, an RTP stack with PDU set marking capabilities can be aware of the UDP/IP header overhead per packet and take it into account in determining the PDU set size while performing RTP fragmentation and packetization. As such, the RTP stack uses this information with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PDU set size field in Bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU set. In one example, if UDP/IPv4 is used to transport the RTP packets of the application RTP sender the RTP stack can determine an overhead of 20 Bytes (IPv4)+8 Bytes (UDP)=28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6)+8 Bytes (UDP)=48 Bytes per RTP packet. As a result, the RTP stack can so compute the PDU set size in bytes corresponding to the PDU set size including RTP payload size and the additional UDP/IP protocol headers overheads. This information can in return be signaled further downstream to other media-aware network nodes, or alternatively, to one or more receivers in band for each PDU set as part of a PDU set RTP header extension. Also, see ¶0005, ¶0065, ¶0105 & step 2015 in Fig. 20.); and send the GTP-U packet to the UE device via the RAN (Fig. 6- 12 & ¶0005 - transmit the GTP-U encapsulated PDU set and corresponding PDU set information. See at least step 2020 in Fig. 20).
Yet, Stoica does not expressly teach receive, from a user equipment (UE) device communicatively coupled to the RAN, data representing a local Internet protocol (IP) address type and a maximum transmission unit (MTU) size for a second network device; determine that a source IP address of the first data packet matches an IP address of the second network device;
However, in the analogous art, 3GPP TS 26.522_ V0.1.1 explicitly discloses receive, from a user equipment (UE) device communicatively coupled to the RAN, data representing a local Internet protocol (IP) address type and a maximum transmission unit (MTU) size for a second network device (§4.4.2.1 - The RTP Header Extension for PDU Set marking can be used by an AS (e.g., MRF) or a sender UE that sends media to a receiver UE over RTP. §4.4.2.6.3 - The PDU Set Size value of a PDU Set should be determined by the RTP sender based on the RTP payload corresponding to the PDU Set, transmission path MTU Size, or alternatively, maximum RTP SDU size, and network IP transport configuration. The RTP sender should follow the corresponding steps in determining the PDU Set Size. Step 1 - The RTP sender should receive from a media encoder (e.g., a H.264 encoder, a H.265 encoder) an RTP payload corresponding to a PDU Set. The size of the received RTP payload (R) should be determined in bytes. Step 2 - The RTP sender should perform next RTP fragmentation and packetization of the RTP payload. The maximum size of an RTP packet SDU (S) should be determined given a transmission path MTU size, or alternatively, a preconfigured maximum RTP SDU payload size less than the path MTU size. Step 4 - The RTP sender should further determine per RTP packet the size of the UDP/IP headers overhead associated with an OS UDP socket sending out the RTP packets. This may be done by the RTP sender using UDP socket options available programmatically over OS network stack API calls or based on SDP-configured IP endpoints and corresponding transmission IP addresses. The RTP sender should determine the type of the underlying IP version used for transport, i.e., IPv4 or IPv6, and determine accordingly the IP header overhead (Ih_p) for each encapsulated RTP packet. If IPv4 options are configured for the UDP socket, or alternatively, if IPv6 header extensions are sent over the UDP socket, the RTP sender should consider the additional incurred size these have to the IP header overhead (Ih_p) of each RTP packet. The RTP sender should consider a fixed size UDP header overhead (Uh) of 8 bytes for each RTP packet…. In case no IPv4 header options are used, the RTP sender should consider Ih_p corresponding to 20 bytes per RTP packet for IPv4. Whereas, in case no IPv6 extension headers are used, the RTP sender should consider Ih_p corresponding to 40 bytes per RTP packet for IPv6. Step 5 - The RTP sender should determine the PDU Set Size as the sum in bytes of all RTP/UDP/IP headers overhead of each one of the P packets and the received RTP payload corresponding to the PDUs of the PDU Set, e.g., PSSize =R +
∑
p
=
1
P
(Ih_p + Uh_p + Rh_p) . The value should be indicated in the PSSize field of the RTP HE for PDU Set marking for all PDUs of the PDU Set before the corresponding RTP PDUs are sent over the UDP socket. §A.2 RTP payload - The PDU Set information identification based on the RTP payload format is present in this clause, including the RTP payload format for H.264/AVC and H.265/HEVC codecs. It is assumed that the 5GC (i.e. UPF) is aware of the RTP payload format in advance);
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Stoica’s invention of a system and a method for PDU < protocol data unit > set-aware multimedia applications and associated signaling in a 5G/NR <New Radio> wireless communication system to include 3GPP TS 26.522_ V0.1.1’s invention of Multiple Simultaneous RTP < Real-Time Transport Protocol> Streams in an RTP Session in a wireless communication system, because it provides an efficient mechanism for an RTP sender in determining a type of underlying IP version used for transport i.e., IPv4 or IPv6, , subsequently enables in determining an IP header overhead for each encapsulated RTP packet, in turns, helps in determining per RTP packet size of UDP/IP headers overhead in RTP transmission/reception in the wireless communication system. (§4.4.2.6.3, 3GPP TS 26.522_ V0.1.1)
Re. Claims 16 and 18, Stoica and 3GPP TS 26.522_ V0.1.1 teach claims 15 and 17.
Stoica further teaches wherein receiving the data representing the local IP address type and the MTU size comprises receiving the local IP address type and the MTU size from a device executing an application function (AF) that received the local IP address type and the MTU size from the UE device. (Fig. 10-12 & ¶0107 - PDU set information determination with uniform processing and logic on both server and client sides: interoperable in-band signaling procedure between an AS and 5GS UPF entity over N6 over well-established RTP and WebRTC transport protocols; and reduced processing complexity of UPF/5GS implementation for DL/UL PDU set-aware QoS integrated handling where, in DL, the UPF needs to identify PDU sets based on in-band indication over RTP header extensions coming from an AS by applying a PDU set aware packet filter associated with a 5 tuple for a service data flow of an application and where, in UL, the legacy SDAP based DRB selection mechanisms can be used by a PDU set-aware UE given PDU set-aware QoS rules are negotiated and established over the control plane by the AF. Fig. 10-12 & ¶0118 - for an identified RTP payload mapped to a PDU set, the RTP stack uses the MTU knowledge for the RTP packet fragmentation based on the link MTU size. The MTU size may be statically configured, e.g., to 1280 Bytes for RTP SDUs as in WebRTC, or alternatively, dynamically determined based on ICMP and MTU path discovery procedures. Once the RTP fragmentation is determined, the RTP stack can perform packetization and further release the RTP packets corresponding to the RTP payload, i.e., the PDU set, to the corresponding UDP socket as agreed upon session establishment via the SDP offer/answer procedure. In this flow, the application further provides the RTP stack control to the UDP socket and UDP socket configuration. Consequently, the RTP stack can further determine necessary socket options, i.e., IP version of the transport layer, to determine the protocol headers overhead on the PDU set size. Thus, an RTP stack with PDU set marking capabilities can be aware of the UDP/IP header overhead per packet and take it into account in determining the PDU set size while performing RTP fragmentation and packetization. As such, the RTP stack uses this information with the RTP payload size during RTP packet fragmentation and RTP packetization to determine the PDU set size field in Bytes corresponding to both the size of the RTP payload and the overhead of the UDP/IP headers of the corresponding RTP packets forming the PDU set. In one example, if UDP/IPv4 is used to transport the RTP packets of the application RTP sender the RTP stack can determine an overhead of 20 Bytes (IPv4)+8 Bytes (UDP)=28 Bytes per RTP packet. In another example, if UDP/IPv6 is used to transport the RTP packets the RTP stack can determine an overhead of 40 Bytes (IPv6)+8 Bytes (UDP)=48 Bytes per RTP packet. As a result, the RTP stack can so compute the PDU set size in bytes corresponding to the PDU set size including RTP payload size and the additional UDP/IP protocol headers overheads. This information can in return be signaled further downstream to other media-aware network nodes, or alternatively, to one or more receivers in band for each PDU set as part of a PDU set RTP header extension.)
Allowable Subject Matter
Claims objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 5- wherein the SDP attribute has a format comprising “a = mtu: <mtu-size>,” where mtu-size corresponds to the MTU size for the second network device..
Claim 12 - wherein the SDP attribute has a format comprising “a = mtu: <mtu-size>,” where mtu-size corresponds to the MTU size for the second network device..
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
TSG SA4 WG #125 Meeting; Tdoc S4-231305; Source: Lenovo; Title: [5G_RTP] On Origin IP Version and PDU Set Size; Gothenburg, 21nd – 25th August 2023. See §3 as shown in the snapshot below.
PNG
media_image2.png
376
661
media_image2.png
Greyscale
Kammachi Sreedhar et al. (2024/0259454); See ¶0194-¶0213 along with Fig. 8-16B.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMED SHAMSUL CHOWDHURY whose telephone number is (571)272-0485. The examiner can normally be reached on Monday-Thursday 9 AM- 6 PM EST (Friday Var.).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hassan Phillips can be reached on 571-272-3940. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHAMMED S CHOWDHURY/Primary Examiner, Art Unit 2467
Prosecution Insights