Multiplexed media identification information optimization

Abstract

Disclosed herein is a method performed by wireless device. The method comprises: obtaining packet filters comprising one or more (S)RTP multiplexed media identification information to identify one or more media flows in one or more IP flows, wherein each (S)RTP multiplexed media identification information includes MID identification-tag and / or RTP SDES header extension id; and storing the packet filters.

Description

Applicant’s Ref.: P113005W001Multiplexed Media identification information optimization Technical Field

[0001] The present disclosure relates to a cellular communications system and, more particularly to traffic mapping of different media flows.Background

[0002] The 3GPP networks introduced support for high data rate low latency services which include support for extended Reality (XR) and interactive media services e.g. cloud gaming and tactile / multi-modal communication services. 3GPP technical specification TS 23.501 V. 19.1.0 clause 5.37 describe the required capability to support these types of services. As part of the capabilities to support these services is the Quality of Service (QoS) mechanisms required to support the different media requirements which include support of Packet data Unit (PDU) Set based QoS handling including PDU Set identification and marking.TS 23.501 V.19.1.0 describes the PDU set based handling as follows (please refer to TS 23.501 V.19.0 for the cross references):A PDU Set is comprised of one or more PDUs carrying an application layer payload such as a video frame or video slice. The PDU Set based QoS handling by the NG-RAN is determined by PDU Set QoS Parameters in the QoS profile of the QoS Flow (specified in clause 5.7.7) and PDU Set Information provided by the PSA UPF via N3 / N9 interface as described in clause 5.37.5.2. The PDU Set based Handling can be applied for GBR and non-GBR QoS Flows. The AF should provide PDU Set related assistance information for dynamic PCC control. One or more of the following PDU Set related assistance information may be provided to the NEF / PCF using the AF session with required QoS procedures in clauses 4.15.6.6 and 4.15.6.6a of TS 23.502 [3],- PDU Set QoS Parameters as described in clause 5.7.7- Protocol Description: Indicates the transport protocol used by the service data flow (e.g. RTP, SRTP) and information, e.g. the following:- RTP

[0185] or SRTP

[0186] ;- RTP or SRTP with RTP Header Extensions, including:- RTP Header Extensions for PDU Set Marking as defined in TS 26.522

[0179] ;- Other RTP Header Extensions as defined RFC 8285

[0189] ;- RTP or SRTP without RTP Header Extensions, but together with RTP Payload Format (e.g.H.264

[0187] or H.265

[0188] );- RTP or SRTP with RTP Header Extensions for PDU Set Marking as defined in TS 26.522

[0179] , and together with RTP Payload Format (e.g. H.264

[0187] or H.265

[0188] );- RTP or SRTP with other RTP Header Extensions following RFC 8285

[0189] , and together with RTP Payload Format (e.g. H.264

[0187] or H.265

[0188] ).[…]The Protocol Description can be UL only, DL only or UL and DL. The Protocol Description for UL and DL traffic may be different.Applicant’s Ref.: P113005W001AF provided PDU Set QoS Parameters and UL and / or DL Protocol Description may be used in determining the PCC Rule by the PCF as defined in clause 6.1.3.27.4 of TS 23.503

[0045] and the DL Protocol Description may be used for identifying the PDU Set Information and PDU Set Information marking by the PSA UPF.When the SMF receives the PCC rule, the SMF performs binding of the PCC rule to one QoS Flow as described in clause 6.1.3.2.4 of TS 23.503

[0045] . At least one of the following shall be included in the PCC rule to enable PDU Set based handling: 1) a PSIHI and / or 2) both PSDB and PSER. Based on the PCC rule, the SMF adds the PDU Set QoS Parameters to the QoS Profile of the QoS Flow as described in clause 6.2.2.4 of TS 23.503

[0045] , Alternatively, the SMF may be configured to support PDU Set based Handling without receiving PCC rules from a PCF.[…]For the uplink direction, the UE may identify PDU Sets, and how this is done is left up to UE implementation. The SMF may send the UL Protocol Description associated with the QoS rule to UE.

[0003] As stated in the section above the session Management Function (that handles the UE PDU session(s) (SMF) determines from the PCC rules the downlink (DL) Protocol Description and uplink (UL) Protocol Description. The DL Protocol Description is provided to the associated User plane function for the PDU session and The UL Protocol Description is provided to the UE in the QoS rules. 3GPP TS 23.501 V.19.1.0 clause 5.7.6 as Packet Filter set. The Packet Filter Set is used in the QoS rule and the Packet Detection Rule (PDR) to identify one or more packet (IP) flow(s).The Packet Filter Set may contain one or more Packet Filter(s). Every Packet Filter is applicable for the DL direction, the UL direction or both directions.There are two types of Packet Filter Set, i.e. IP Packet Filter Set, and Ethernet Packet Filter Set, corresponding to those PDU Session Types.

[0004] The following is the IP Packet Filter Set as described in TS 23.501 V. 19.1.0 clause 5.7.6.2 is specified to identify IP flows:For IP PDU Session Type, the Packet Filter Set shall support Packet Filters based on at least any combination of:- Source / destination IP address or IPv6 prefix.- Source / destination port number.- Protocol ID of the protocol above IP / Next header type.- Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.- Flow Label (IPv6).- Security parameter index.- Packet Filter direction.NOTE 1: A value left unspecified in a Packet Filter matches any value of the corresponding information in a packet.NOTE 2: An IP address or Prefix can be combined with a prefix mask.NOTE 3: Port numbers can be specified as port ranges.NOTE 4: Type of Service (IPv4) / Traffic class (IPv6) can be used to define packet filters for DSCP and ECN as described in RFC 3168

[0193] ,Applicant’s Ref.: P113005W001

[0005] In 3GPP SA2 #166 meeting, the CR5958 (S2-2501108) was agreed to update the IP Packet Filter Set to identify the media in a specific flow. The proposed addition to the IP Packet Filter Set (as described in clause 5.7.6.2 of 3GPP TS 23.501) to further identify the media are as follows:

[0006] (S)RTP Multiplexed Media Identification Information including a combination of at least one of the following:- Synchronization Source (SSRC), as defined by IETF RFC 3550;- Payload Type (PT), as defined by IETF RFC 3550;- RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID, as defined by IETF RFC 9143- RTCP packet type.

[0007] The two newly introduced information elements contains RTCP SDES item Media Identification (MID) as specified in IETF RFC 9143 and RTP SDES header extension for MID as specified in IETF RFC 9143.RFC 9143 states: The SDES item and RTP SDES header extension make it possible for a receiver to associate each RTP stream with a specific "m=" section with which the receiver has associated an identification-tag, even if those "m=" sections are part of the same RTP session. The RTP SDES header extension also ensures that the media recipient gets the identification-tag upon receipt of the first decodable media and is able to associate the media with the correct application.Figure 4

[0008] The RTCP MID SDES item is defined in IETF [RFC 9143] clause 15.1 and is illustrated in Figure 4.The RTP SDES header extension for MID is defined in IETF [RFC 9143] clause 15.2. The payload, containing the identification-tag, of the RTP SDES header extension element can be encoded using either the 1 -byte or the 2-byte header [RFC7941], The identification-tag payload is UTF-8 encoded, as in SDP.Figure 5The 1 -byte header is illustrated in Figure 5. According to [RFC7941] the one-byte header format for an SDES item extension element consists of the one-byte header (defined in Section 4.2 of [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length field (len) that identifies the number of data bytes (len value +1) following the header. The data part consists of len+1 bytes of UTF-8 [RFC3629] text. The type of text and its mapping to the SDES item type are determined by the ID field value.Figure 6

[0009] The 2-byte header in [RFC7941] is illustrated in Figure 6. According to [RFC7941], the two-byte header format for an SDES item extension element consists of the two-byte header (defined in Section 4.3 of [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length field (len) that identifies the number of data bytes following the header. The data part consists of len bytes of UTF-8 text. The type of text and its mapping to the SDES item type are determined by the ID field value.Applicant’s Ref.: P113005W001

[0010] IETF [RFC5285] describes that the RTP specification [RFC3550] provides a capability to extend the RTP header. It defines the header extension format and rules for its use in Section 5.3.1 of [RFC3550], The existing header extension method permits at most one extension per RTP packet, identified by a 16-bit identifier and a 16-bit length field specifying the length of the header extension in 32-bit words.Figure 7

[0011] In section 5.3.1 of [RFC3550], it defines the RTP header extension as illustrated in Figure 7. There are two variant of header extension type, as indicated in [RFC5285], the type is determined by the field "defined by profile”. Each RTP packet with an RTP header extension will indicate whether it contains one-byte or two-byte header extension through the use of the "defined profile” as illustrated in Figure 7.Figure 8

[0012] Figure 8 illustrates the format of the RTP SDES extension header for MID based on the header extension format described in Figure 7.

[0013] Based on the proposal in S2-2501108 that proposed adding the RTCP SDES item Media Identification (MID) (Figure 4) and RTP SDES header extension for MID (Figure 8), as defined by IETF RFC 9143 in the protocol description, i.e., Packet Filter sets (described in 5.7.6.2 of TS 23.501), each of the RTP SDES header extension for MID, the header extension identifier and the associated identification-tag are to be sent to the UE as part of QoS rules and to the UPF as part of PDR as specified in clause 5.7.6.1 of TS 23.501 V. 19.1.0 " The Packet Filter Set is used in the QoS rule and the PDR to identify one or more packet (IP or Ethernet) flow(s).NOTE 1: A QoS Flow is characterized by PDR(s) and QoS rule(s) as described in clause 5.7.1.1.NOTE 2: DL Packet Filter in a Packet Filter Set of a QoS rule may be needed by the UE e.g. for the purpose of IMS precondition.The Packet Filter Set may contain one or more Packet Filter(s). Every Packet Filter is applicable for the DL direction, the UL direction or both directions.”Briefof the

[0014] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented;Figures 2 and 3 illustrate example embodiments of the cellular communication system of Figure 1;Figure 4 illustrates RTCP MID SDES item as specified in IETF [RFC9143];Applicant’s Ref.: P113005W001Figure 5 illustrates a one byte RTP header extension type;Figure 6 illustrates a two bytes RTP header extension type;Figure 7 illustrates an RTP header extension as illustrated in [RFC3550];Figure 8 illustrates the RTP SDES header extension for MID based on Figure 5 or 6 and 7;Figure 9 illustrates a flow diagram of creating / updating packet filters with media identification according to embodiments of the present disclosure;Figures 10 and 11 are schematic block diagrams of example embodiments of a network node;Figures 12 and 13 are schematic block diagrams of example embodiments of a wireless device.Detailed

[0015] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0016] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0017] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.

[0018] Radio Node: As used herein, a "radio node” is either a radio access node or a wireless communication device.

[0019] Radio Access Node: As used herein, a "radio access node” or "radio network node” or "radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and / or receive signals. Some examples of a radio access node include, but areApplicant’s Ref.: P113005W001not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network or future 6G base station), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

[0020] Core Network Node: As used herein, a "core network node” is any type of node in a core network or any node that implements a core network function. The node can be a server or system of distributed servers. Some examples of a core network node include, e.g., an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Short message service function (SMSF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), a Network slice Admission Control function (NSACF) or the like. The Core network functions may be virtualized / containerized on a node, server, distributed servers, or implemented as a dedicated function on a dedicated physical node (compute, memory, and network). Other future core network functions in future core networks such as 6G and beyond are also applicable for this invention.

[0021] Communication Device: As used herein, a "communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and / or data via a wireless or wireline connection.

[0022] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and / or data via a wireless connection.

[0023] Network Node: As used herein, a "network node” is any node that is either part of the RAN or the core network of a cellular communications network / system.Applicant’s Ref.: P113005W001

[0024] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0025] Note that, in the description herein, reference may be made to the term "cell”; however, particularly with respect to 5G NR concepts or even 6G, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.Figure 1

[0026] Figure 1 illustrates one example of a cellular communications system 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 100 is for example a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC), but it is applicable to other systems such as 6G systems comprising a 6G access network and 6G Core network and the present disclosure is not limited thereto. All embodiments described herein are described using the 5G system as an example, but it would apparent for a person skilled in the art that the embodiments would be applicable to 6G or beyond supporting the applications requiring the QoS capability described herein.

[0027] Going back to Figure 1, in this example, the RAN includes base stations 102-1 and 102-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. Likewise, the (macro) cells 104-1 and 104-2 are generally referred to herein collectively as (macro) cells 104 and individually as (macro) cell 104. The RAN may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106. Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108.

[0028] In particular when the NG-RAN consists of gNBs (5G or beyond) connected to the 5GC through the NG interface, a gNB may further consist of a gNB-control unit (CU) and one or more gNB-Distribution Unit(s) (DU(s)). A gNB-CU and a gNB-DU is connected via F1 interface.

[0029] The cellular communications system 100 also includes a core network 110, which in the 5G System (5GS) is referred to as the 5GC. The base stations 102 (and optionally the low power nodes 106) are connected to the core network 110.

[0030] The base stations 102 and the low power nodes 106 provide service to wireless communication devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication device 112. In the following description, the wireless communicationApplicant’s Ref.: P113005W001devices 112 are oftentimes UEs and as such sometimes referred to herein as UEs 112, but the present disclosure is not limited thereto.Figure 2

[0031] Figure 2 illustrates a wireless communication system based on 5G. The 5G system of Figure 2 represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 2 can be viewed as one particular implementation of the system 100 of Figure 1.

[0032] Seen from the access side the 5G network architecture shown in Figure 2 comprises a plurality of UEs 112 connected to either a RAN 102 or an Access Network (AN) as well as an AMF 200. Typically, the R(AN) 102 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in Figure 2 includes but not limited to a NSSF 202, an AUSF 204, a UDM 206, the AMF 200, a SMSF 220, a SMF 208, a PCF 210, and an Application Function (AF) 212.

[0033] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 112 and AMF 200. The reference points for connecting between the AN 102 and AMF 200 and between the AN 102 and UPF 214 are defined as N2 and N3, respectively. There is a reference point, N11, between the AMF 200 and SMF 208, which implies that the SMF 208 is at least partly controlled by the AMF 200. N4 is used by the SMF 208 and UPF 214 so that the UPF 214 can be set using the control signal generated by the SMF 208, and the UPF 214 can report its state to the SMF 208. The SMSF 220 communicates with the AMF 200 over the N20 reference point, and with UDM 206 over the N21 reference point, and AMF 200 communicates with UDM 206 over the N8 reference point as illustrated in Figure 2. N9 is the reference point for the connection between different UPFs 214, and N14 is the reference point connecting between different AMFs 200, respectively. N15 and N7 are defined since the PCF 210 applies policy to the AMF 200 and SMF 208 respectively. N5 is the reference point linking an AF 212 with the PCF 210. N12 is required for the AMF 200 to perform authentication of the UE 112. N8 and N10 are defined because the subscription data of the UE 112 is required for the AMF 200 and SMF 208. N80 is the reference point between AMF 200 and NSACF 207 and N81 reference point is between SMF 208 and NSACF 207.

[0034] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In Figure 2, the UPF 214 is in the UP and all other NFs, i.e., the AMF 200, SMF 208, PCF 210, AF 212, NSSF 202, AUSF 204, and UDM 206, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0035] The 5G core network architecture is composed of modularized functions. For example, the AMF 200, SMF 208 are independent functions in the CP. Separated AMF 200 and SMF 208 allow independentApplicant’s Ref.: P113005W001evolution and scaling. Other CP functions like the PCF 210 and AUSF 204 can be separated as shown in Figure 2. Modularized function design enables the 5GC network to support various services flexibly.

[0036] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.Figure 3

[0037] Figure 3 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points / i nterf aces used in the 5G network architecture of Figure 2. The NFs described above with reference to Figure 2 correspond to the NFs shown in Figure 3. The NFs provide and expose service(s) to be consumed by other authorized NF(s) through the service-based interface using APIs. In Figure 3 the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 200 and Nsmf for the service based interface of the SMF 208, Nsmsf for service based interface exposing services of SMSF 220, etc. Any NFs depicted in Figure 2 can interact with the NEF 216 and / or NRF 218 of Figure 3 as necessary, though not explicitly indicated in Figure 2.

[0038] Some properties of some NFs shown in Figures 2 and 3 may be described in the following manner. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. A UE 112 even using multiple access technologies is basically connected to a single AMF 200 because the AMF 200 is independent of the access technologies. The SMF 208 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 214 for data transfer and determines the QoS to be provisioned in the UE, bas station and User plane function UPF 214 based on PCC rules provided by the PCF 210. If a UE 112 has multiple sessions, different SMFs 208 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AUSF 204 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 206 stores subscription data of the UE 112. The PCF 212 interacts with AF 210 to obtain authorization requests such as request for QoS for a specific application or media. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

[0039] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0040] As stated in the introduction, there currently exist certain challenges for support of optimizing the IP Packet Filter Set that are transmitted to the UE and to the UPF. Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of the solutions described herein enable

[0041] Instead of sending the full headers, i.e., RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID, as defined by IETF RFC 9143, as suggested in S2-2501108 that was agreed inApplicant’s Ref.: P113005W0013GPP, this document proposed to optimize the information that is used and transmitted to the UE and optimize the use of air interface resources by reducing the number of information signalled over the air interface resources. When both of the RTCP MID SDES item and RTP SDES header extension for MID are used, it's efficient to send the identification-tag and the RTP SDES header extension ID, otherwise the NW should encode the identificationtag twice.

[0042] In addition by reducing the size of the IP Packet filter sets that are stored in the UE and UPF, it optimizes the use of resources by minimizing the amount of storage used as those filters have to be maintained in the UE and the UPF for as long as the PDU session used for the above mentioned services for a particular UE is active. In addition simplifying the IP Packet Filter set optimizes the processing resources when mapping the application packets to the IP Packet filter set as the UE is not required to match the full headers.

[0043] As stated above, instead of transmitting the complete RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID, this document proposes to transmit only the identification-tag (of Figure 4) for RTCP and not the full header, hence excluding the MID and length, and for RTP, only the RTP header extension identifier and the identification-tag. This optimized information is referred to as multiplexed media identification (MID).

[0044] The multiplexed media identification (MID) information can be provided from an Application Function AF 210 to a NEF or to a PCF 212. The PCF 212 may receive the MID information from the AF 210 over N5 or from NEF and the PCF 212 will include the MID information in service data flows (SDF) in the PCC rule to the SMF 208. Then, SMF 208 includes the SDF in packet filters in the QoS rules to the UE and in the PDRs to the UPF. Alternatively, the AF 210 may provide the full RTCP MID SDES item and RTP SDES header extension for MID to the NEF or PCF 212 and the PCF 212 can select the identification-tag for RTCP and the RTP header extension identifier and the identification-tag for RTP.Figure 9

[0045] Figure 9 illustrates an example of procedure described using 5G system as an example. The procedure illustrates an AF 210 requesting QoS for a UE connected over a PDU session using an application that require that require high data rate and low latency communication (e.g., AR / VR application, cloud gaming, metaverse). If the AF 210 is trusted, it sends the QoS request (new or updated) directly to a PCF 212 in the 5G system, if not trusted, the AF communicates with the 5G system through the NEF (Network exposure function) which then communicates with the PCF 212 serving the UE 112. In Figure 9, the assumption is a PDU session is already established for the UE (step 0), and the AF requests to create / update a QoS for the application (e.g., cloud gaming, AR / VR), which then would result in modifying the PDU session for binding the application to a QoS flow having QoS according to the application needs. However, the QoS can be established at PDU session establishment procedure, in which case PCF 212 obtains flow information from User data repository and step 0 is not necessary.

[0046] Step 1a and Step 1b (optional) cover the untrusted AF where a NEF is used. More specifically step 1a, the AF sends a request to reserve / update resources for an AF session usingApplicant’s Ref.: P113005WQ01Nnef_AFsession WithQoS_Create / update request message. When " MultiMedia" feature is supported, the AF may include the multi-modal Service ID within the "multiModalld" attribute; and / or the multi-modal dataflow(s) information of the multi-modal service in the "multlModDatFlows" attribute. The AF shall include for each single-modal data flow(s) of the multi-modal service at least one of:1. the single-modal data identification number within the "medCompN" attribute;2. the IP data flow(s) description for the single-modal data flow within the "flowinfo" attribute; and3. parameters that describe the requested QoS for the single-modal data flow.The flowinfo attribute that includes the packet description includes the following information as transmitted from AF to NEF:Attribute name Data type Cardinality Description Applicability flowld integer 1 Indicates the IP flow.flowDescriptions array(string) 0..2 Indicates the packet filters ofthe IP flow.Refer to clause 5.3.8 of3GPP TS 29.214

[0010] forencoding. It shall contain ULand / or DL IP flow description.tosTC TosTrafficClass 0..1 Type of service or TrafficClass.mpxMediaUHnfos array(MpxMedialnfo) O.. N Contains the Multiplexed MpxMedia Media information for theUplink or IP flows based onthe flow description.mpxMediaDIInfos array(MpxMedialnfo) O.. N Contains the Multiplexed MpxMedia Media Information for theDownlink IP flows based onthe flow description.An MpxMedialnfo item from the array comprises the following informationApplicant’s Ref.: P113005WQ01MpxMedialnfoAttribute name Data type P Cardinality Description Applicability ssrcld Uinteger C 0..1 Contains the synchronization source asdefined in IETF RFC 3550

[0058] (NOTE 1) (NOTE 2)payloadType integer C 0..1 Integer between and including 1 and127.When present, this IE shall contain thePayload Type (PT) values in the RTPheader of RTP packets, as defined inIETF RFC 3550

[0058] (NOTE 2)midldTag string c 1 Contains the MID identification -tagas defined in IETF RFC 9143

[0059] , rtpHeaderExtld integer c 1 Integer between and including 1 and255.Contains the RTP Header extensionId as defined in IETF RFC 8285

[0061] ,rtcpPt integer c 0..1 Integer between and including 200 and204.When present, this IE shall contain thePacket Type (PT) values of RTCPpackets, as defined inIETF RFC 3550

[0058] (NOTE 1)NOTE 1: The multiplexed media information for the (s)RTCP streams shall contain the attribute "rtcpPt", and at least one of the attributes "ssrcld" and "midldTag", and the other attributes shall not be present.NOTE 2: The multiplexed media information for the (s)RTP steams shall contain at least one one of the combinations:a) "ssrcld", b) "payloadType", and c) "rtpHeaderExtld" and "midldTag", and the other attributes shall not bepresent.Alternatively, the AF may instead of only sending the MID identification-tag and RTP Header extension Id, may include the full header, it could send the full header RTCP MID SDES item and RTP SDES header extension to the NEF, and either the NEF or the PCF 212 determines the MID identification-tag and the RTP header extension ID to be included in the packet filters to be sent to the SMF 208.

[0047] (alternatively) Step 1c can be used if the AF is trusted in which case, it communicates directly with the PCF 212 in the 5G system. The AF 210 then either sends a request to create or update QoS for the application that requires QoS corresponding to high data rate low latency application. The request also includes the multi-modal data flow(s) information of the multi-modal service in for example a multi-Modal Data Flow attribute which comprise the IP data flow(s) description for the single-modal data flow within the "flowinfo" attribute as described above.

[0048] Step 2. The PCF 212 may receive from the AF 210 or NEF the flowinfo attribute as described above or may receive the header RTCP MID SDES item and RTP SDES header extension as illustrated in Figure 4 and Figure 8. If the PCF 212 receives the header RTCP MID SDES item and RTP SDES header extension as illustrated in Figure 4 and Figure 8, it is proposed that the PCF 212 extracts the MID identification-tag and RTPApplicant’s Ref.: P113005WC01Header extension Id from the header to include them in the service data flow information (SDF)Zflow information of the PCC Rules. The PCF 212 (as described in TS 23.501, 5.7) determines the PCC rules using the information obtained from AF 210 or NEF. The PCC rules include the requested QoS and service data flow information, i.e., the filter information as flow information data type. The filter information is derived from the received Flowinfo attribute from the AF 210 or NEF. The structure of Flow information data type included in the PCC Rules transmitted from the PCF 212 to the SMF 208 associated to the UE PDU session is illustrated in the table below:FlowinformationAttribute name Data type P Cardinality Description Applicability flowDescription FlowDescription O 0..1 Contains the packet filters of the IPflow(s).ethFlowDescription EthFlowDescription O 0..1 Defines a packet filter for an Ethernetflow. If the "fDir" attribute is included, itshall be set to " DOWNLINK". If the"fDir" attribute is never provided, theaddress information within the "ethFlowDescription" attribute shall beencoded in downlink direction.packFiltld string o 0..1 An identifier of packet filter. (NOTE) packetFilterUsage boolean o 0..1 Indicates whether the packet filter shallbe sent to the UE.- "true" indicates that the packet filtershall be sent to the UE.- "false" indicates that the packetfilter shall not be sent to the UE.- The default value is "false", if theattribute is not present and has notbeen supplied previously.tosTrafficClass string o 0..1 2-octet string. The first octet containsthe Ipv4 Type-of-Service or the Ipv6Traffic-Class field and the second octetcontains the ToS / Traffic mask field in hexadecimal representation. Eachcharacter in the string shall take avalue of "0" to "9" or " A" to " F" andshall represent 4 bits. One example isthat of a TFT packet filter as defined in3GPP TS 24.008

[0041] ,Applicant’s Ref.: P113005WQ01spi string O 0..1 4 octet string, representing the security parameter index of the IPSec packet in hexadecimal representation. Eachcharacter in the string shall take avalue of "0" to "9" or " A" to " F" andshall represent 4 bits. One example isthat of a TFT packet filter as defined in3GPP TS 24.008

[0041] ,flowLabel string O 0..1 3-octet string, representing the Ipv6flow label header field in hexadecimal representation. Each character in thestring shall take a value of "0" to "9" or" A" to " F" and shall represent 4 bits.One example is that of a TFT packetfilter as defined in3GPP TS 24.008

[0041] ,flowDirection FlowDirectionRm O 0..1 Indicates the direction / directions that afilter is applicable, downlink only,uplink only or both down- and uplink (bidirectional).mpxMediaUHnfos array(MpxMedialnf O 1.. N Contains the Multiplexed Media MpxMedia o) Information for the Uplink or DownlinkIP flows based on the flow description. mpxMediaDIInfos array(MpxMedialnf O 1.. N Contains the Multiplexed Media MpxMedia o) Information for the Downlink IP flowsbased on the flow description.NOTE: The PCF shall only assign the "packFiltld" attribute for PCC rules created as a result of UE-initiated resource allocation.One MpxMedilnfo item include the MID identification-tag and rtpHeaderExtld as described in MpxMedilnfo table above.Note that step 1a, 1b and 1c are optional. Flow information comprising the MpxMedlnfo can be stored in User Data Repository (UDR) and the PCF 212 can retrieve the flow information from the UDR if the UE executed a procedure of establishing the PDU session instead, in which case step 0 in the figure is not a prerequisite.

[0049] At step 3 and step 4, the SMF 208 performs the binding of PCC rules to QoS Flows for the PDU session based on the QoS and service requirements (as defined in TS 23.503). The SMF 208 may assign a QFI for a new QoS Flow and derives corresponding UPF instructions and QoS Rule(s) from the PCC rule(s) bound to the QoS Flow and other information provided by the PCF 212. For each PCC rule bound to a QoS Flow, the SMF 208 provides by sending a request message (step 3) over the N4 reference point to the UPF 214 to create or update the PDR to enable the UPF 214 to perform classification, bandwidth enforcement and marking of User Plane traffic. The request message includes:Applicant’s Ref.: P113005W001a DL PDR containing the DL part of the SDF template;an UL PDR containing the UL part of the SDF template;The SMF 208 includes in the PDR the packet filters that contain one or more MID identification-tag and RTP Header extension Id to identify different medias on an IP flow for the downlink traffic and may include one or more MID identification-tag and RTP Header extension Id to identify different medias on an IP flow for the uplink traffic. The UPF uses the MID identification-tag and RTP Header extension Id in the packet filters included in the PDR for traffic mapping when receiving downlink IP flow for a UE and to identify specific (RTP) media flows identified by MID identification-tag and RTP Header extension Id in an IP flow. The UPF does not need to receive the full RTP / RTCP header as suggested in the current prior art. When downlink IP flows transporting different media types are received, the UPF matches the downlink traffic against the downlink packet filters (Received in the PDRs) to match for specific media packet in a flow. The UPF can parse the RTCP MID SDES item with the received identification-tag in the packet filter, and the UPF uses the identification-tag with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID. Once the RTP packets of a media in a flow (i.e., IP flow aka packet flow) matches the packet filter component, the UPF then maps the received media packet to the QoS flow so the appropriate QoS is applied when transmitting the packet towards the UE.

[0050] In addition, for each PCC rule bound to a QoS Flow, when applicable, the SMF generates an explicitly signalled QoS rule according to the following principles and provides it to the UE together with an add operation or an update operation:A unique (for the PDU Session) QoS rule identifier is assigned;The QFI in the QoS rule is set to the QFI of the QoS Flow to which the PCC rule is bound;The Packet Filter Set of the QoS rule is generated from the UL SDF filters and optionally the DL SDF filters of the PCC rule (but only from those SDF filters that have an indication for being signalled to the UE, as defined in TS 23.503);The QoS rule precedence value is set to the precedence value of the PCC rule for which the QoS rule is generated;Other information as described in TS 23.501, clause 5.7.For multi-modal service or XR services, the packet filter component type in the QoS rules are enhanced to support the (S)RTP multiplexed media packet filter component, e.g "synchronization source (SSRC) type" and "payload type type". During 3GPP stage 2 work, it was further added the Media Identification (MID) and (S)RTCP Packet Type in the packet filter component type identifier and in SA2 #166 meeting, the CR5958 (S2-2501108) was agreed to update the MID to " RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID". The following illustrates how the QoS rules are encoded as per the current art (TS 24.501):Applicant’s Ref.: P113005WQ01Each QoS rule is encoded as below:8 7 6 5 4 3 2 1QoS rule identifier octet 4 Length of QoS rule octet 5octet 6 Rule operation code DQR Number of packet filters octet 7bitoctet 8* Packet filter listoctet m* QoS rule precedence octet m+1* 0 Segre QoS flow identifier (QFI) octet m+2* Spar gationeQoS rule (u=m+2)According to embodiments herein, the maximum number of packet filters per each QoS rule is 15, the current coding of multiplexed media packet filter component requires more packet filters to fulfil several specific (S)RTP multiplexed media streams to the same IP flow. It might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule.Due to the limitation of maximum number of packet filters per each QoS rule, it might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule.Applicant’s Ref.: P113005W001In addition, the current standard (3GPP TS 24.501, V 19.1.1) further specifies the following encoding of packet filter list:8 7 6 5 4 3 2 10 0 0 0 Packet filter identifier 1 octet 8 Spare0 0 0 0 Packet filter identifier 2 octet 9 Spare0 0 0 0 Packet filter identifier N octet N+7SparePacket filter list when the rule operation is "modify existing QoS rule and delete packet filters"(m=N+7)8 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8 Spare direction 1Length of packet filter contents 1 octet 9 Packet filter contents 1 octet 10octet m0 0 Packet filter Packet filter identifier 2 octet k+1 Spare direction 2Length of packet filter contents 2 octet k+2 Packet filter contents 2 octet k+3octet n octet n+1 octet y0 0 Packet filter Packet filter identifier N octet y+1 Spare direction NLength of packet filter contents N octet y+2 Packet filter contents N octet y+3octet m Packet filter list when the rule operation is "create new QoS rule", or "modify existing QoS rule and add packet filters" or "modify existing QoS rule and replace all packet filters"Currently, the packet filter identifier field is used to identify each packet filter in a QoS rule. The least significant 4 bits are used. When the UE requests to "create new QoS rule", "modify existing QoS rule and replace all packet filters" or "modify existing QoS rule and add packet filters", the packet filter identifier values shall be set to 0.The length of the packet filter contents field contains the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order is the most significant bit.Applicant’s Ref.: P113005W001The packet filter contents field is of variable size and contains a variable number (at least one) of packet filter components. Each packet filter component shall be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier shall be transmitted first. In each packet filter, there shall not be more than one occurrence of each packet filter component type. Furthermore TS 24.501 describes packet filter components as IP packet filter components or Ethernet packet filter components. The " IP packet filter component" refers to " IPv4 remote address type", " IPv4 local address type", " IPv6 remote address / prefix length type", " IPv6 local address / prefix length type", " Protocol identifier / Next header type", " Single local port type", " Local port range type", " Single remote port type", " Remote port range type", " Security parameter index type", " Type of service / T raffic class type" and " Flow label type". A

[0051] TS 24.501 V. 19.1.1 only describes the different packet filter component type as any of the following component:Packet filter component type identifierBits8765432 1O O O O O O O 1 Match-all type (see NOTE 2)000 1 0000 IPv4 remote address type000 1 000 1 IPv4 local address type00 1 0000 1 IPv6 remote address / prefix length type00 1 000 1 1 IPv6 local address / prefix length type00 1 1 0000 Protocol identifier / Next header type0 1 000000 Single local port type0 1 00000 1 Local port range type0 1 0 1 0000 Single remote port type0 1 0 1 000 1 Remote port range type0 1 1 00000 Security parameter index type0 1 1 1 0000 Type of service / T raffic class type1 0000000 Flow label type1 000000 1 Destination MAC address type1 00000 1 0 Source MAC address type1 00000 1 1 802.1Q C-TAG VID type1 0000 1 00 802.1Q S-TAG VID type1 0000 1 0 1 802.1Q C-TAG PCP / DEI type1 0000 1 1 0 802.1Q S-TAG PCP / DEI type1 0000 1 1 1 Ethertype type1 000 1 000 Destination MAC address range type1 000 1 00 1 Source MAC address range type1 00 1 000 1 Synchronization source (SSRC) type1 00 1 00 1 0 Payload type typeThe term "(S)RTP multiplexed media packet filter component" refers to "synchronization source (SSRC) type" and "payload type type".The "(S)RTP multiplexed media packet filter component" packet filter component can not be present in the packet filter with no " IP packet filter component".Applicant’s Ref.: P113005W001For "synchronization source (SSRC) type", the standard currently describes the packet filter component value field as being encoded as 4 octet SSRC field which specify the synchronization source identifier in the RTP header as specified in IETF RFC 3550.In some examples herein, it is also proposed to enhance the encoding of the packet filter.In 3GPP CT1 #152 meeting, there was a discussion on whether it is allowed to have more than one "synchronization source (SSRC) type" and / or more than one "payload type type" in the same packet filter. There was no consensus about it and the legacy restriction applies:In each packet filter, there shall not be more than one occurrence of each packet filter component type.So, for the example above, the SMF would then encode the packet filter list to UE as follows:8 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8Spare direction 1Length of packet filter contents 1 octet 9IP packet filter component octet 10 tooctet (10+m)(S)RTP multiplexed media packet filter component: octet (11+m)SSRC1, PT1 to octet k0 0 Packet filter Packet filter identifier 2 octet k+1Spare direction 2Length of packet filter contents 2 octet k+2IP packet filter component octet (k+3) tooctet (k+3+m)(S)RTP multiplexed media packet filter component: octet (k+4+m)SSRC2, PT1 to octet I0 0 Packet filter Packet filter identifier 3 octet 1+1Spare direction 3Length of packet filter contents 3 octet I+2IP packet filter component octet (I+3) tooctet (l+3+m)(S)RTP multiplexed media packet filter component:SSRC3, PT1 octet (l+4+m)to octet v0 0 Packet filter Packet filter identifier 4 octet v+1Spare direction 4Length of packet filter contents 4 octet v+2IP packet filter component octet (v+3) tooctet (v+3+m)(S)RTP multiplexed media packet filter component: PT2 octet (v+4+m)to octet wCoding of (S)RTP multiplexed media component according to curren: artFor the RTP media streams transported via the same IP flow, for the above coding approach, the IP packet filter component is repeated in several packet filters. This is not an efficient use of air interface resources as this information is sent over the air interface to the UE.According to an embodiment, the octet for packet filter identifier and the length indicator of each packet filter contents are not needed if the (S)RTP multiplexed media packet filter component can be conveyed in the one packet filter.E.g, the above (S)RTP multiplexed media component is coded as following instead:Applicant’s Ref.: P113005W0018 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8Spare direction 1Length of packet filter contents 1 octet 9IP packet filter component octet 10 tooctet (10+m)(S)RTP multiplexed media packet filter components:[SSRC1, PT1], octet (11+m)[SSRC2, PT1], to octet k[SSRC3, PT1],[PT2]Table: optimized coding of packet filter component for (S) RTPIt's more efficient to convey the multiplexed media packet filter component with the same IP packet filter component in one packet filter.To support the coding in Table: optimized coding of packet filter component for (S) RTP, the (S)RTP multiplexed media packet filter component can be a sequence of the (S)RTP multiplexed media packet filter entries. The matching of the UL packets by the UE is OR logic, which means once the UL packet matches one of the (S)RTP multiplexed media packet filter entry, the UL packet is considered as matched the (S)RTP multiplexed media packet filter component part.3GPP SA2 changed the MID as described in TS 24.501 V. 19.1.1 (described above) to " RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID as described in RFC9143” in SA2 #166 meeting in the agreed CR5958 (S2-2501108). However, sending the " RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID as described in RFC9143” to the UE (and / or UPF) is unnecessary as it leads to inefficient use of air interface resource usage, inefficient use of storage in the UE (and UPF) as they need to store larger filters, and inefficient use of processing power when matching the traffic against the filters, as matching against more information will require extra processing. It is sufficient to just send in the filters the most important information when matching for particular media flows, and that information consists of the MID identification-tag and the RTP SDES header extension id for MID. More specifically, for the UE, when uplink traffic mapping of different medias of an IP flow is to be performed, the UE matches the uplink traffic against the uplink packet filters to match for specific media packet in a flow. The UE can parse the RTCP MID SDES item of the packet with the received identification-tag in the packet filter (in the QoS Rule), and the UE uses the identification-tag with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID of the media flow. Once the RTP packets of a media in a flow (i.e., IP flow aka packet flow) matches, the UE then maps the received media packet to the QoS flow so the appropriate QoS is applied when transmitting the packet towards the network (base station and UPF). If the UE received downlink packet filters, it performs the same.

[0052] Although, not shown in Figure 9, if reflective QoS is used, the UE will not receive the packet filters from the SMF as shown in step 4, the UE determines the packet filters to use for uplink based on the receive downlink packet. The UE extracts the Identification-tag for MID from the RTCP MID SDES item and the RTP SDES header extension id from the RTP SDES header extension for MID and stored both information in theApplicant’s Ref.: P113005W001determined packet filter. When sending UL traffic, it performs traffic matching against the determined packet filters to identify the media flow and perform the appropriate mapping to the QoS flow.

[0053] When Qos rules are signalled to the UE (as shown in step 4 of Figure 9), Embodiments herein propose to only send the MID identification-tag and the RTP SDES header extension id for MID to the UE instead of RTCP SDES MID item and RTP SDES header extension for MID.Considering that the SSRC, PT (Payload type), MID identification-tag, the RTP SDES header extension id, RTCP packet type might not present simultaneously when identifying the specific RTP media stream(s), 3 coding alternatives are proposed, the alternative 1 uses the following structure.8 7 6 5 4 3 2 1Number of (S)RTP multiplexed media identification entries octet 1octet 2(S)RTP multiplexed media identification entry 1octet moctet m+1(S)RTP multiplexed media identification entry 2octet voctet v+1octet woctet w+1(S)RTP multiplexed media identification entry noctet xAlternative 1: Value part of (S)RTP multiplexed media identification component8 7 6 5 4 3 2 1Length of value part of (S)RTP multiplexed media identification octet 11information0 0 0 RPTPI RHEID MITPI PT1 SSRCI octet 12Spare Spare Spare PISynchronization Source (SSRC) octet 13*octet 16*Payload type octet p*MID identification -tag octet q*octet r*RTP header extension id octet s*octet t*RTCP packet type octet h*(S)RTP multiplexed media identification entry of Alternative 1In alternative 1, the value part of (S)RTP multiplexed media packet filter component type is coded as a list of (S)RTP multiplexed media identification entries, each entry contains any combination of SSRC, PT, identificationtag and the RTP SDES header extension id for MID, RTCP packet type, the presence of SSRC, PT, identification-tag and the RTP SDES header extension id for MID, RTCP packet type uses the presence indicator. The details of alternative 1 are further illustrated in the 3GPP proposal included in the appendix.

[0054] Alternative 2: In each packet filter, there shall not be more than one occurrence of each packet filter component type except the "(S)RTP multiplexed media identification packet filter component".And a new sub-list of packet filter component type identifier for (S)RTP multiplexed media identification packet filter component is used, the packet filter component value field shall be encoded as a sequence of a one octetApplicant’s Ref.: P113005W001(S)RTP multiplexed media identification packet filter component type identifier and a (S)RTP multiplexed media identification packet filter component value field. The (S)RTP multiplexed media identification packet filter component type identifier is transmitted first, then follows a (S)RTP multiplexed media identification packet filter component value field.(S)RTP multiplexed media identification packet filter component type identifier Bits8 7 6 5 4 3 2 100 0 0 0 0 0 1 Synchronization source (SSRC)type00 0 0 0 0 1 0 Payload type type00 0 0 0 0 1 1 MID identification-tag type00 0 0 0 1 0 0 RTP header extension id type00 0 0 0 1 0 1 RTCP packet type typeAlternative 2 allows the "(S)RTP multiplexed media identification packet filter component to be presented more than once on each packet filter, and use a sub-list of packet filter component type identifier for (S)RTP multiplexed media identification packet filter component with the similar handling as packet filter component list. The details of alternative 2 are further illustrated in the 3GPP proposal included in the appendix.

[0055] Alternative 3 is to define a new IE about the (S)RTP multiplexed media identification information which contains a list of (S)RTP multiplexed media identification entries, and each entry contains at least one of SSRC, PT, RTCP MID SDES item, RTP SDES header extension for MID, RTCP packet type, and then define a packet filter component type identifier for the value part of the (S)RTP multiplexed media identification information IE.

[0056] Alternatives 1, 2 and 3, therefore propose different encoding schemes (S)RTP multiplexed media identification information in QoS Rules, to be sent to the UE in step 4 of Figure 9) and in addition an optimization in the information included in the (S)RTP multiplexed media identification packet filter component, i.e., only send the MID identification-tag and the RTP header extension id instead of RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID, as defined by IETF RFC 9143 as agreed by 3GPP SA2 at the time of this document.

[0057] The QoS Rules comprising the MID identification-tag and the RTP header extension id (using any of alternative 1-3) encoding at step 4 is transmitted to the UE (at step 3) as part of PDU session modification procedure (initiated by the network or UE) and could be sent to the UE as part of PDU session accept at PDU session establishment procedure. In the latter scenario, the SMF 208 obtains PCC rules that are provisioned for the UE (e.g., stored in UDR) and not triggered by a request from an AF 210 / NEF (step 1a, 1b, 1c). The UE stores the QoS rules and use them for UL packet matching.Applicant’s Ref.: P113005W001Figure 10

[0058] Figure 10 is a schematic block diagram of a network node 1100 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 1100 may be, for example, a core network node that implements a NF (e.g., one or more of the 5G network functions, or the like, as described herein). As illustrated, the network node 1100 includes a one or more processors 1104 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory 1106, and a network interface 1108. The one or more processors 1104 are also referred to herein as processing circuitry. The one or more processors 1104 operate to provide one or more functions of the network node 1100 as described herein (e.g., one or more functions of the e.g., one or more of the 5G network functions, or the like, as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1106 and executed by the one or more processors 1104.Figure 11

[0059] Figure 11 is a schematic block diagram that illustrates a virtualized embodiment of the network node 1100 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized” network node is an implementation of the network node 1100 in which at least a portion of the functionality of the network node 1100 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 1100 includes one or more processing nodes 1200 coupled to or included as part of a network(s) 1202. Each processing node 1200 includes one or more processors 1204 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1206, and a network interface 1208. In this example, functions 1210 of the network node 1100 described herein (e.g., one or more of the 5G network functions, or the like, as described herein) are implemented at the one or more processing nodes 1200 or distributed across the two or more processing nodes 1200 in any desired manner. In some particular embodiments, some or all of the functions 1210 of the network node 1100 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1200.

[0060] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 1100 or a node (e.g., a processing node 1200) implementing one or more of the functions 1210 of the network node 1100 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).Applicant’s Ref.: P113005W001Figure 12

[0061] Figure 12 is a schematic block diagram of a UE 1000 according to some embodiments of the present disclosure. As illustrated, the UE 1000 includes one or more processors 1002 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 1004, and one or more transceivers 1006 each including one or more transmitters 1008 and one or more receivers 1010 coupled to one or more antennas 1012. The transceiver(s) 1006 includes radio-front end circuitry connected to the antenna(s) 1012 that is configured to condition signals communicated between the antenna(s) 1012 and the processor(s) 1002, as will be appreciated by on of ordinary skill in the art. The processors 1002 are also referred to herein as processing circuitry. The transceivers 1006 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 1000 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1004 and executed by the processor(s) 1002. Note that the UE 1000 may include additional components not illustrated in Figure 10 such as, e.g., one or more user interface components (e.g., an input / output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and / or the like and / or any other components for allowing input of information into the UE 1000 and / or allowing output of information from the UE 1000), a power supply (e.g., a battery and associated power circuitry), etc.

[0062] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 1000 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). Figure 13

[0063] Figure 13 is a schematic block diagram of the UE 1000 according to some other embodiments of the present disclosure. The UE 1000 includes one or more modules 1100, each of which is implemented in software. The module(s) 1100 provide the functionality of the UE 1000 described herein.

[0064] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used toApplicant’s Ref.: P113005W001cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.Some EmbodimentsSome of the embodiments described above can be summarized in the following manner:1. A method performed by wireless device, the method comprising:- obtaining packet filters comprising one or more (S)RTP multiplexed media identification information to identify one or more media flows in one or more IP flows, wherein each (S)RTP multiplexed media identification information includes MID identification-tag and / or RTP SDES header extension id;- storing the packet filters.2. The method of embodiment 1 wherein the method further comprises using MID identification-tag to parse RTCP MID SDES item of a media flow when performing Uplink (UL) PACKET matching.3. The method of embodiment 1 or 2 wherein the method further comprises using MID identification-tag with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID of media flow.4. The method of embodiment 1, wherein the step of obtaining comprises receiving the packet filters as part of a PDU session establishment procedure and / or PDU session modification procedure.5. The method of any one of embodiments 1 to 4 wherein the packet filters are included in QoS Rules.6. A wireless device configured to perform the method of any of embodiments 1-5.7. A wireless device comprising one or more processors, a transmitter / receiver and memory comprising instructions which when executed by the one or more processors enable the wireless device to perform the method of any of embodiments 1-5.8. A computer readable memory comprising instructions which when executed by one or more processors of a wireless device configures the wireless device to perform any of the embodiments 1-5.9. A method performed by a User Plane function (UPF), the method comprising:Applicant’s Ref.: P113005W001- obtaining from a Session Management Function (SMF) packet filters comprising one or more (S)RTP multiplexed media identification information to identify one or more media flows in one or more IP flows, wherein each (S)RTP multiplexed media identification information includes MID identification-tag and / or RTP SDES header extension id;- storing the packet filters.10. The method of embodiment 9 wherein the method further comprises using MID identification-tag to parse RTCP MID SDES item of a media flow when performing downlink (DL) PACKET matching.11. The method of embodiment 9 or 10 wherein the method further comprises using MID identification-tag with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID of media flow.12. The method of embodiment 9, wherein the step of obtaining comprises receiving the packet filters as part of a PDU session establishment procedure and / or PDU session modification procedure.13. The method of any one of embodiments 1 to 4 wherein the packet filters are included in Packet Data Rules (PDR).14. A network node implementing a user plane function configured to perform the method of any of embodiments 9-13.15. A network node implementing a user plane function comprising one or more processors and memory comprising instructions which when executed by the one or more processors enable the wireless device to perform the method of any of embodiments 9-13.16. A computer readable memory comprising instructions which when executed by one or more processors of a network node configures the network node to perform any of the embodiments 9-13.

[0065] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0066] While processes in the figures (flow charts, procedures) may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order isApplicant’s Ref.: P113005W001exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0067] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.Applicant’s Ref.: P113005W001The following appendix describes examples of same embodiments described herein but presented as planned publications to 3GPP describing the alternative coding of (S)RTP multiplexed media information when transmitted to the UE (or to the UPF), the amendments to QoS rules and the 3 alternative coding of (s)RTP multiplexed media identification components in packet filters for TS 24.501, the impact to the different interfaces between AF and NEF (TS 29.122), between AF and PCF (TS 29.214), between PCF and SMF (TS 29.212). The publications include additional details that are considered subject matter for potential future claims:Discussion3GPP TSG-CT WG1 Meeting #153 C1-24xxxx Athens, Greece, 17-21 February 2025Source: EricssonTitle: Allowing multiple (S)RTP multiplexed media identification component in one packet filterAgenda item: 19.48Document for: DISCUSSION1. BackgroundIn the XRM-Ph2 WI, the packet filter component type identifier was enhanced to support the (S)RTP multiplexed media packet filter component, e.g "synchronization source (SSRC) type" and "payload type type". In stage 2, it was further added the Media Identification (MID) and (S)RTCP Packet Type in the packet filter component type identifier. And in SA2 #166 meeting, the CR5958 (S2-2501108) was agreed to update the MID to " RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID".2. DiscussionAs states in the S2-2412586(S4-241812) [1] Reply LS on Introduction of Extensions to IP Packet Filters for Differentiated QoS Handling for Multiplexed Media Flows:SA 4 therefore recommends using the identification triplet (SSRC, PT, MID) for Packet Filter purposes, where one or more of those triplet elements are included;SSRC, -, -): A specific RTP stream, SSRC value, regardless of PT content format and MID values (-, PT, -): All RTP streams marked with this PT content format value(-, -, MID): All RTP streams marked with this MID value• (SSRC, PT, -): A specific RTP stream, SSRC value, marked with this PT content format value• (SSRC, -, MID): A specific RTP stream, SSRC value, marked with this MID value • (-, PT, MID): All RTP streams marked with this PT content format and MID values • (SSRC, PT, MID): A specific RTP stream, SSRC value, marked with this PT content format and MID valuesApplicant’s Ref.: P113005W001So it might happen that more than one specific RTP media streams multiplexing into the same IP flow, so AF provisions the multiplexed media identification information about these RTP media streams may have the same content of the IP 5-tuple, e.g the following (S)RTP multiplexed media identification information is provided to the SMF viaPCF:[SSRC1, PT1], [SSRC2, PT1], [SSRC3, PT1], [PT2]Observation 1: Multiple RTP streams with different combination of the SSRC and / or PT might be multiplexed into the same IP flow.In CT1 #152 meeting, there was a discussion on whether it is allowed to have more than one "synchronization source (SSRC) type" and / or more than one "payload type type" in the same packet filter. There was no consensus about it and the legacy restriction applies:In each packet filter, there shall not be more than one occurrence of each packet filter component type.So for the example above, the SMF encodes the packet filter list to UE as follows:8 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8Spare direction 1Length of packet filter contents 1 octet 9IP packet filter component octet 10 tooctet (10+m)(S)RTP multiplexed media packet filter component: octet (11+m)SSRC1, PT1 to octet k0 0 Packet filter Packet filter identifier 2 octet k+1Spare direction 2Length of packet filter contents 2 octet k+2IP packet filter component octet (k+3) tooctet (k+3+m)(S)RTP multiplexed media packet filter component: octet (k+4+m)SSRC2, PT1 to octet I0 0 Packet filter Packet filter identifier 3 octet 1+1Spare direction 3Length of packet filter contents 3 octet I+2IP packet filter component octet (I+3) tooctet (l+3+m)(S)RTP multiplexed media packet filter component:SSRC3, PT1 octet (l+4+m)to octet v0 0 Packet filter Packet filter identifier 4 octet v+1Spare direction 4Length of packet filter contents 4 octet v+2IP packet filter component octet (v+3) tooctet (v+3+m)(S)RTP multiplexed media packet filter component: PT2 octet (v+4+m)to octet wFigure 1For the RTP media streams transported via the same IP flow, for this coding approach, the IP packet filter component (marked yellow in figure 1) is repeated in several packet filters.Observation 2: For the RTP media streams transported via the same IP flow, for the current coding approach, the IP packet filter component with the same content is repeated in several packet filters.According to 24.501:Applicant’s Ref.: P113005W0018 7 6 5 4 3 2 1QoS rule identifier octet 4 Length of QoS rule octet 5octet 6 Rule operation code DQR Number of packet filters octet 7bitoctet 8* Packet filter listoctet m* QoS rule precedence octet m+1* 0 Segre QoS flow identifier (QFI) octet m+2* Spar gationeFigure 9.11.4.13.2: QoS rule (u=m+2)The maximum number of packet filters per each QoS rule is 15, the current coding of multiplexed media packet filter component requires more packet filters to fulfil several specific (S)RTP multiplexed media streams to the same IP flow. It might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule.Observation 3: Due to the limitation of maximum number of packet filters per each QoS rule, it might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule.The octet for packet filter identifier and the length indicator of each packet filter contents are not needed if the (S)RTP multiplexed media packet filter component can be conveyed in the one packet filter.E.g, The above example is coded as following:8 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8Spare direction 1Length of packet filter contents 1 octet 9IP packet filter component octet 10 tooctet (10+m)(S)RTP multiplexed media packet filter components:[SSRC1, PT1], octet (11+m)[SSRC2, PT1], to octet k[SSRC3, PT1],_ [PT2] _Figure 2Observation 4: It’s more efficient to convey the multiplexed media packet filter component with the same IP packet filter component in one packet filter.In CT4#126 meeting, CT4 agreed C4-245466 [2] on the following structure for SDF Filter:BitsOctets 8 7 6 5 4 3 2 11 to 2 Type = 23 (decimal)3 to 4 Length = n5 Spare | SMMI | BID | FL | SPI | TTC | FD6 Sparem to (m+1) Length of Flow Description(m+2) to p Flow Descriptions to (s+1) ToS Traffic Classt to (t+3) Security Parameter Indexv to (v+2) Flow Labelw to (w+3) SDF Filter IDa Number of (S)RTP Multiplexed Media Informationb to (b+1) Length of (S)RTP Multiplexed Media Information 1(b+2) to c (S)RTP Multiplexed Media Information 1d to (d+1) Length of (S)RTP Multiplexed Media Information nApplicant’s Ref.: P113005W001(d+2) to e > (S)RTP Multiplexed Media Information nx to (n+4) These octet(s) is / are present only if explicitly specifiedFigure 8.2.5-1: SDF FilterThe blue part is for the SMF to transmit the (S)RTP multiplexed media identification information to UPF, it allows more than one (S)RTP multiplexed media identification information (a list of [SSRC, PT] combination, multiple SSRCs, PTs are allowed in the element of the list) to be transmitted in one SDF filter. It would be nicer to align the similar coding principle within the Stage-3 groups.Observation 5: CT4 allows multiple (S)RTP multiplexed media identification information to be transmitted in one SDF filter. It would be nicer to align the similar coding principle within the Stage-3 groups.But to reduce the UE complexity, it was agreed to not allow more than one SSRC / PT in the same packet filter in CT1 #152 meeting, so, to algin with this agreement, It’s proposed to not allow multiple SSRC, PT, etc in the (S)RTP multiplexed media identification information entry.Observation 6: To reduce the UE complexity, it’s proposed to not allow multiple SSRC, PT, etc in the (S)RTP multiplexed media identification information entry.To support the coding in figure 2, the (S)RTP multiplexed media packet filter component can be a sequence of the (S)RTP multiplexed media packet filter entries. And the matching of the UL packets is OR logic, which means once the UL packet matches one of the (S)RTP multiplexed media packet filter entry, the UL packet is considered as matched the (S)RTP multiplexed media packet filter component part.SA2 changed the MID to “RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID” in SA2 #166 meeting, agreed CR5958 (S2-2501108), The most important information is the identification-tag and the RTP SDES header extension id for MID, it can be used to parse the RTCP SDES item Media Identification (MID) combined with the SDES type field for MID which is 15, and it can be used to be combined with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID. So it is proposed to send the identification-tag and the RTP SDES header extension id for MID to the UE instead of RTCP SDES MID item and RTP SDES header extension for MID.Considering that the SSRC, PT, identification-tag, the RTP SDES header extension id, RTCP packet type might not present simultaneously when identifying the specific RTP media stream(s), there are 3 coding alternatives, the alternative 1 uses the following structure.8 7 6 5 4 3 2 1Number of (S)RTP multiplexed media identification entries octet 1octet 2(S)RTP multiplexed media identification entry 1octet moctet m+1(S)RTP multiplexed media identification entry 2octet voctet v+1octet woctet w+1(S)RTP multiplexed media identification entry noctet xFigure 3 Value part of (S)RTP multiplexed media identification componentApplicant’s Ref.: P113005W0018 7 6 5 4 3 2 1Length of value part of (S)RTP multiplexed media identification octet 11information0 0 0 RPTPI RHEID MITPI PT1 SSRCI octet 12Spare Spare Spare PISynchronization Source (SSRC) octet 13*octet 16*Payload type octet p*MID identification-tag octet q*octet r*RTP header extension id octet s*octet t*RTCP packet type octet h*Figure 4 (S)RTP multiplexed media identification entry Proposal 1: Value part of (S)RTP multiplexed media packet filter component type is coded as a list of (S)RTP multiplexed media identification entries, each entry contains any combination of SSRC, PT, identification-tag and the RTP SDES header extension id for MID, RTCP packet type, the presence of SSRC, PT, identification-tag and the RTP SDES header extension id for MID, RTCP packet type uses the presence indicator.The alternative 2 uses the following structure:No new figure is added, and the following restriction on each packet filter is extended with the underline text: In each packet filter, there shall not be more than one occurrence of each packet filter component type except the "(S)RTP multiplexed media identification packet filter component".And a new sub-list of packet filter component type identifier for (S)RTP multiplexed media identification packet filter component is used, the packet filter component value field shall be encoded as a sequence of a one octet (S)RTP multiplexed media identification packet filter component type identifier and a (S)RTP multiplexed media identification packet filter component value field. The (S)RTP multiplexed media identification packet filter component type identifier is transmitted first, then follows a (S)RTP multiplexed media identification packet filter component value field.(S)RTP multiplexed media identification packet filter component type identifierBits87654 32 10000 000 1 Synchronization source (SSRC)type0000 00 1 0 Payload type type0000 00 1 1 MID identification-tag type0000 0 1 00 RTP header extension id type0000 0 1 0 1 RTCP packet type typeProposal 2: Allow the "(S)RTP multiplexed media identification packet filter component to be presented more than once on each packet filter, and use a sub-list of packet filter component type identifier for (S)RTP multiplexed media identification packet filter component with the similar handling as packet filter component list.The alternative 3 is to define a new IE about the (S)RTP multiplexed media identification information which contains a list of (S)RTP multiplexed media identification entries, and each entry contains at least one of SSRC, PT, RTCP MID SDES item, RTP SDES header extension for MID, RTCP packet type, and then define a packet filter component type identifier for the value part of the (S)RTP multiplexed media identification information IE.Proposal 3: Define a new IE for (S)RTP multiplexed media identification information which is a list of (S)RTP multiplexed media identification entries, and each entry contains at least one of SSRC, PT, identification-tag, RTP SDES header extension id for MID, RTCP packet type. And define a packet filter component type identifier for the value part of the (S)RTP multiplexed media identification information IE.3. Conclusion and proposalIn the above clauses the following observations were made:Applicant’s Ref.: P113005W001Observation 1: Multiple RTP streams with different combination of the SSRC and / or PT might be multiplexed into the same IP flow.Observation 2: For the RTP streams transported via the same IP flow, for the current coding approach, the IP packet filter component with the same content is repeated in several packet filters.Observation 3: Due to the limitation of maximum number of packet filters per each QoS rule, it might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule.Observation 4: It’s more efficient to convey the multiplexed media packet filter component with the same IP packet filter component in one packet filter.Observation 5: CT4 allows multiple (S)RTP multiplexed media identification information to betransmitted in one SDF filter. It would be nicer to align the similar coding principle within the Stage-3 groups.Observation 6: To reduce the UE complexity, it’s proposed to not allow multiple SSRC, PT, etc in the (S)RTP multiplexed media identification information entry.Proposal 1: Value part of (S)RTP multiplexed media packet filter component type is coded as a list of (S)RTP multiplexed media identification entries, each entry contains any combination of SSRC, PT, identification-tag, RTP SDES header extension id for MID, RTCP packet type, the presence of SSRC, PT, identification-tag and the RTP SDES header extension id for MID, RTCP packet type uses the presence indicator.Proposal 2: Allow the "(S)RTP multiplexed media identification packet filter component to be presented more than once on each packet filter, and introduce a sub-list of packet filter component type identifier for (S)RTP multiplexed media identification packet filter component with the similar handling as packet filter component list.Proposal 3: Define a new IE for (S)RTP multiplexed media identification information which is a list of (S)RTP multiplexed media identification entries, and each entry contains at least one of SSRC, PT, identification-tag, RTP SDES header extension id for MID RTCP packet type. And define a packet filter component type identifier for the value part of the (S)RTP multiplexed media identification information IE.This paper discusses the issue of whether the multiple (S)RTP multiplexed media packet filter components are allowed on each packet filter, and 3 solutions are proposed as in Proposal #1, Proposal #2 and Proposal #3.Proposal #1 is captured in Cl-25xxxl, Proposal #2 is captured in Cl-25xxx2, and Proposal #3 is captured inCl-25xxx3, respectively.4. References[1] S2-2412586: Reply LS on Introduction of Extensions to IP Packet Filters for Differentiated QoS Handling for Multiplexed Media Flows.[2] C4-245466: CR0893 to 29.244: Support of differentiated QoS handling for multiplexed media flows.Alternative 1 for QoS Rules coding3GPP TSG-CT WG1 Meeting #153 C1-25xxxx Athens, Greece, 17-21 February 2025CR-Form-v12.2 CHANGE REQUEST24.501 CR xxxx rev - Current version: 19.1.1For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp. org / Change-Requests.Applicant’s Ref.: P113005W001Proposed change affects: UICC apps| | ME|~x] Radio Access Network! I Core NetworkFx] Title: Alt-1: Allow multiple multiplexed media packet filter components in one packet filter Source to WG: EricssonSource to TSG: C1Work item code: XRM_Ph2 Date: 2024-02-10 Category: B Release: Re I- 19Use one of the following categories: Use one of the following releases:F (correction) Rel-8 (Release 8)A (mirror corresponding to a change in an earlier Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11) release)B (addition of feature), Rel-16 (Release 16)C (functional modification of feature) Rel-17 (Release 17)D (editorial modification) Rel-18 (Release 18) Detailed explanations of the above categories can Rel-19 (Release 19) be found in 3GPP TR 21.900.Reason for change: As discussed in C1 -25xxxx, multiple RTP streams with different combination of the SSRC and / or PT might be multiplexed into the same IP flow. In this case, for the current coding approach, the IP packet filter component with the same content is repeated in several packet filters. And due to the limitation of maximum number of packet filters per each QoS rule, it might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule.So it is proposed to convey the multiplexed media packet filter component with the same IP packet filter component in one packet filter.This the the Alt-1 to allow the multiple multiplexed media packet filter component with the same IP packet filter component in one packet filter. In this alternative, a new figure on value part of (S)RTP multiplexed media identification component with a list of S)RTP multiplexed media identification entries is introduced, and each entry consist of one or more of SSRC, payload type, MID, and (S)RTCP packet type.In SA2 #166 meeting, the CR5958 (S2-2501108) was agreed to update the MID as followings:- (S)RTP Multiplexed Media Identification Information including a combination of at least one of the following:- Synchronization Source (SSRC). as defined by IETF RFC 3550 1185|: - Payload Type (PT), as defined by IETF RFC 3550 11851:- RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID. as defined by IETF RFC 9143 12071- RTCP packet type.The most important information is the identification-tag and the RTP SDES header extension id for MID, it can be used to parse the RTCP SDES item Media Identification (MID) combined with the SDES type field for MID which is 15, and it can be used to be combined with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID. So it is proposed to send the identification-tag and the RTP SDES header extension id for MID to the UE instead of RTCP SDES MID item and RTP SDES header extension for MID.Applicant’s Ref.: P113005W001Additionally, the underline of the title of reference

[0071] in clause 2 needs to be removed.Summary of change: 1). Introduce coding on allowing the multiple multiplexed media packet filter component with the same IP packet filter component in one packet filter; 2). Introduce MID and (S)RTCP packet type in the packet filters;3) EN on other packet filter component types is removed.Consequences if not For multiple multiplexed media packet filter components with the same IP approved: packet filter component, multiple packet filters are needed which is not efficient; Stage-2 requirement for supporting MID and (S)RTCP packet typenot fullfilled.Clauses affected: 2, 3.2, 9.11.4.13Y NOther specs X Other core specifications TS 23.501 CR 5958affected: X Test specifications TS / TR... CR...(show related CRs) X O& M Specifications TS / TR... CR...Other comments:This CR's revision history:* * First Change * * * *2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.- For a specific reference, subsequent revisions do not apply.- For a non-specific reference, the latest version applies. In the case of a reference to a 3 GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.[…]

[0070] IETF RFC 8285: " A General Mechanism for RTP Header Extensions".

[0071] IETF RFC 3550: " RTP: A Transport Protocol for Real-Time Applications".[vv]IETF I Negotiating Media Multiplexing Using the Session Description Protocol (SDP)".* * * Next Change * * * *3.2 AbbreviationsFor the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the followingapply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905 [1],[…]MID Media Identification[…]Applicant’s Ref.: P113005W001* * * Next Change * * * *9.11.4.13 QoS rulesThe purpose of the QoS rules information element is to indicate a set of QoS rules to be used by the UE, where each QoS rule is a set of parameters as described in subclause 6.2.5.1.1.2:a) for classification and marking of uplink user traffic; andb) for identification of a QoS flow which the network is to use for a particular downlink user traffic. NOTE: The UE needs to be aware of a QoS flow which the network is to use for a particular downlink user traffic e.g. to determine whether a resource is available for downlink media of a media stream of an SDP media description provided by the UE in an IMS session.The QoS rules may contain a set of packet filters consisting of zero or more packet filters for UL direction, zero or more packet filters for DL direction, zero or more packet filters for both UL and DL directions or any combinations of these. The set of packet filters determine the traffic mapping to QoS flows.The QoS rules information element is a type 6 information element with a minimum length of 7 octets. The maximum length for the information element is 65538 octets.The QoS rules information element is coded as shown in figure 9.11.4.13.1, figure 9.11.4.13.2,figure 9.11.4.13.3, figure 9.11.4.13.4 and table 9.11.4.13.1.octet 1 octet 2 octet 3 octet 4 octet u octet u+1 octet v octet v+1 octet w octet w+1octet x Figure 9.11.4.13.1: QoS rules information element8 7 6 5 4 3 2 1QoS rule identifier octet 4 Length of QoS rule octet 5octet 6 Rule operation code DQR Number of packet filters octet 7bitoctet 8* Packet filter listoctet m* QoS rule precedence octet m+1* 0 Segre QoS flow identifier (QFI) octet m+2* Spar gationeFigure 9.11.4.13.2: QoS rule (u=m+2)Applicant’s Ref.: P113005W0018 7 6 5 4 3 2 10 0 0 0 Packet filter identifier 1 octet 8 Spare0 0 0 0 Packet filter identifier 2 octet 9 Spare0 0 0 0 Packet filter identifier N octet N+7SpareFigure 9.11.4.13.3: Packet filter list when the rule operation is "modify existing QoS rule and delete packet filters" (m=N+7)8 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8 Spare direction 1Length of packet filter contents 1 octet 9 Packet filter contents 1 octet 10octet m0 0 Packet filter Packet filter identifier 2 octet k+1 Spare direction 2Length of packet filter contents 2 octet k+2 Packet filter contents 2 octet k+3octet n octet n+1 octet y0 0 Packet filter Packet filter identifier N octet y+1 Spare direction NLength of packet filter contents N octet y+2 Packet filter contents N octet y+3octet m Figure 9.11.4.13.4: Packet filter list when the rule operation is "create new QoS rule", or "modify existing QoS rule and add packet filters" or "modify existing QoS rule and replace all packet filters"8 7 6 5 4 3 2 1Number of (S)IRTIP multiplexed media identification octet 10in form at io in entriesoctet 11 (l lultiplexed media identification information entry1 octet h octet h+1 (I lultiplexed media identification information entry2 octet i octet i+1 octet j octet j+1 (I lultiplexed media identification information entryn octet IkFigun i > '< 11 t l.<v\. line part of (S)KIP multiplexed media identification information componentApplicant’s Ref.: P113005W0018 7 6 5 4 3 2 1Length of value part of (S)IRTP multiplexed media identification octet 11information0 0 0 RPTPI RHEID MITPI PT1 SSRCI octet 12 Spare Spare Spare PISynchronization Source (SSRC) octet 13*octet 16* Payload type octet p*(see NOTE)MID identification-tag octet q*(see NOTE) octet r* ader extension id octet s* (see NOTE, octet t*P packet type octet h*(seeFtNOTE: The field is placed immediately after the last present preceding fieldFigure 9.11.4.13.Y: (S)RTP multiplexed media identification information entryTable 9.11.4.13.1: QoS rules information elementQoS rule identifier (octet 4)The QoS rule identifier field is used to identify the QoS rule.Bits8765432100000000 no QoS rule identifier assigned00000001 QRI 1to1 1 1 1 1 1 1 1 QRI 255The network shall not set the QRI value to 0.[...]QoS flow identifier (QFI) (bits 6 to 1 of octet m+2) (see NOTE 1 )The QoS flow identifier (QFI) field contains the QoS flow identifier.Bits654321000000 no QoS flow identifier assigned000001 QFI 1to1 1 1 1 1 1 QFI 63The network shall not set the QFI value to 0.For the "delete existing QoS rule" operation, the QoS flow identifier value field shall not be included. For the "create new QoS rule" operation, the QoS flow identifier value field shall be included.DQR bit (bit 5 of octet 7)The DQR bit indicates whether the QoS rule is the default QoS rule and it is encoded as follows:Bit50 the QoS rule is not the default QoS rule.1 the QoS rule is the default QoS rule.Rule operation code (bits 8 to 6 of octet 7)Bits876000 Reserved001 Create new QoS rule01 0 Delete existing QoS rule01 1 Modify existing QoS rule and add packet filtersApplicant’s Ref.: P113005W0011 00 Modify existing QoS rule and replace all packet filters1 0 1 Modify existing QoS rule and delete packet filters1 1 0 Modify existing QoS rule without modifying packet filters1 1 1 ReservedNumber of packet filters (bits 4 to 1 of octet 7)The number of packet filters contains the binary coding for the number of packet filters in the packet filter list. The number of packet filters field is encoded in bits 4 through 1 of octet 7 where bit 4 is the most significant and bit 1 is the least significant bit. For the "delete existing QoS rule" operation and for the "modify existing QoS rule without modifying packet filters" operation, the number of packet filters shall be coded as 0. For the "create new QoS rule" operation and the "modify existing QoS rule and replace all packet filters" operation, the number of packet filters shall be greater than or equal to 0 and less than or equal to 15. For all other operations, the number of packet filters shall be greater than 0 and less than or equal to 15.Packet filter list (octets 8 to m)The packet filter list contains a variable number of packet filters.For the "delete existing QoS rule" operation, the length of QoS rule field is set to one.For the "delete existing QoS rule" operation and the "modify existing QoS rule without modifying packet filters" operation, the packet filter list shall be empty. For the "modify existing QoS rule and delete packet filters" operation, the packet filter list shall contain a variable number of packet filter identifiers. This number shall be derived from the coding of the number of packet filters field in octet 7.For the "create new QoS rule" operation and for the "modify existing QoS rule and replace all packet filters" operation, the packet filter list shall contain 0 or a variable number of packet filters. This number shall be derived from the coding of the number of packet filters field in octet 7.For the "modify existing QoS rule and add packet filters" operation, the packet filter list shall contain a variable number of packet filters. This number shall be derived from the coding of the number of packet filters field in octet 7.Each packet filter is of variable length and consists ofa packet filter direction (2 bits);a packet filter identifier (4 bits);the length of the packet filter contents (1 octet); andthe packet filter contents itself (variable amount of octets).The packet filter direction field is used to indicate for what traffic direction the filter applies.Bits6500 reserved0 1 downlink only (see NOTE 2)1 0 uplink only1 1 bidirectionalThe packet filter identifier field is used to identify each packet filter in a QoS rule. The least significant 4 bits are used. When the UE requests to "create new QoS rule", "modify existing QoS rule and replace all packet filters" or "modify existing QoS rule and add packet filters", the packet filter identifier values shall be set to 0. The length of the packet filter contents field contains the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order is the most significant bit.The packet filter contents field is of variable size and contains a variable number (at least one) of packet filter components. Each packet filter component shall beencoded as a sequence of a one octet packet filter component type identifier and aApplicant’s Ref.: P113005W001fixed length packet filter component value field. The packet filter component type identifier shall be transmitted first.In each packet filter, there shall not be more than one occurrence of each packet filter component type. Among the " IPv4 remote address type" and " IPv6 remote address / prefix length type" packet filter components, only one shall be present in one packet filter. Among the " IPv4 local address type" and " IPv6 local address / prefix length type" packet filter components, only one shall be present in one packet filter. Among the "single local port type" and "local port range type" packet filter components, only one shall be present in one packet filter. Among the "single remote port type" and "remote port range type" packet filter components, only one shall be present in one packet filter. Among the "destination MAC address type" and "destination MAC address range type" packet filter components, only one shall be present in one packet filter. Among the "source MAC address type" and "source MAC address range type" packet filter components, only one shall be present in one packet filter. If the "match-all type" packet filter component is present in the packet filter, no other packet filter component shall be present in the packet filter and the length of the packet filter contents field shall be set to one. If the " Ethertype type" packet filter component is present in the packet filter and the " Ethertype type" packet filter component value is neither "0800H" (for IPv4) nor "86DDH" (for IPv6), no IP packet filter component shall be present in the packet filter.The term " IP packet filter component" refers to " IPv4 remote address type", " IPv4 local address type", " IPv6 remote address / prefix length type", " IPv6 local address / prefix length type", " Protocol identifier / Next header type", " Single local port type", " Local port range type", " Single remote port type", " Remote port range type", " Security parameter index type", " Type of service / Traffic class type" and " Flow label type".The "(S)RTP multiplexed media identification information typepaeket-fiter Gempenewt" packet filter component can not be present in the packet filter with no " IP packet filter component".The term local refers to the UE and the term remote refers to an external network entity.Packet filter component type identifierBits8765432 10000000 1 Match-all type (see NOTE 2)000 1 0000 IPv4 remote address type000 1 000 1 IPv4 local address type00 1 0000 1 IPv6 remote address / prefix length type00 1 000 1 1 IPv6 local address / prefix length type00 1 1 0000 Protocol identifier / Next header type0 1 000000 Single local port type0 1 00000 1 Local port range type0 1 0 1 0000 Single remote port type0 1 0 1 000 1 Remote port range type0 1 1 00000 Security parameter index type0 1 1 1 0000 Type of service / T raffic class type1 0000000 Flow label type1 000000 1 Destination MAC address type1 00000 1 0 Source MAC address type1 00000 1 1 802.1Q C-TAG VID type1 0000 1 00 802.1Q S-TAG VID type1 0000 1 0 1 802.1Q C-TAG PCP / DEI type1 0000 1 1 0 802.1Q S-TAG PCP / DEI type1 0000 1 1 1 Ethertype type1 000 1 000 Destination MAC address range type1 000 1 00 1 Source MAC address range type1 00 1 000 1 (S)RTP multiplexed media identification information type (seeIN- ■ I II. II, h 'I I _Applicant’s Ref.: P113005W001All other values are reserved.The description and valid combinations of packet filter component type identifiers in a packet filter are defined in 3GPP TS 23.501 [8],[...]For "(S)RTP multiplexed media identification information type", the packet filter component value field shall be encoded as figure 9.11.4.13.X and figure 9.11.4.13.Y. (See NOTE 5)An (S)RTP multiplexed media identification information entry for (s)RTCP shall contain the RTCP packet type and at least one of the SSRC and MID identification- tag fieldsAn (S)RTP multiplexed media identification information entry fci ■ ill 11 hall contain::aj. _ SSRC field;b) payload type field;c) MID identification-taa and RTP header extension id field; ord) any combination of a) to c).SSRC presence indicator (SSRCI) (bit 1 of octet 12)The SSRCI field indicates whether the SSRC field is included or notBl10 SSRC not includedJ _ SSRC includedPayload type presence indicator (PTI) (bit 2 of octet 12)The PTI field indicates whether the payload type field is included or notBit20 Payload type not included1 Payload type includedMID identification-taa presence indicator (MITPI) (bit 3 of octet 12)The MITPI field indicates whether the MID identification-tag field is included or not Bit30 MID identification-taa not included1 MID identification-taa includedRTP header extension id presence indicator (RHEIDPI) (bit 4 of octet 12) (see NOTE 4)The RHEIDPI field indicates whether the RTP header extension id field is included or not.Bit40 RTP header extension id not included1 RTP header extension id includedRTCP packet type presence indicator (RPTPI) (bit 5 of octet 12)The RPTPI field indicates whether the RTCP packet type field is included or not Bit50 RTCP packet type not included1 RTCP packet type includedThe For-"synchronization source (SSRC) type", the packet filter component value field shall be encoded as 4 octet SSRC field which specify the synchronization source identifier in the RTP header as specified in IETF RFC 3550

[0071] ,Applicant’s Ref.: P113005W001The Rer-^payload type shall beencoded as octet payload type field which contains the binary representation of aninteger between 1(inclusive) and 127(inclusive) as specified in IETF RFC 3550

[0071] ,The MID identification-taa field contains the length of MID identification-taa field andthe MID identification-taa field. The length of MID identification-tag is coded as oneoctet and indicates the length of the MID identification-tag field, and theidentification-tag is encoded as UTF-8 string as specified in IETF RFC 9143 [yy].The length of MID identification-tag is transmited first and the MID identification-tagfield is transmited last.The RTP header extension id field is coded as binary representation of an integerbetween 1(inclusive) and 255(inclusive) as defined in IETF RFC 8285

[0070] . The RTP header extension id is combined with the MID identification-tag to enable the parsing of RTP SDES header extension for MID.The IRTCP packet type field shall be encoded as one octet payload type field whichcontains the binary representation of an integer between 200( inclusive) and204(inclusive) as specified in IETF RII ■ '<'<‘ 11, 11. re 11 DTE 5)NOTE 1: Octet m+2 shall not be included without octet m+1.NOTE 2: The " Match-all type" packet filter component type identifier shall not beused with packet filter direction "downlink only".NOTE 3: When the "(S)RTP multiplexed media identification information type" packet filter component type identifier presents in a UL packet filter, the UL user data packet matching any (S)RTP multiplexed media identification information entry indicates matching of the (S)RTP multiplexed media identification information component of the UL packet filter.NOTE 4: At least one of the SSRCI, PTI, MIDPI and RPTPI shall be set to 1 in the (S)RTP multiplexed media identification information entry.NOTE 5: When one or more of the SSRC, payload type, RTCP MID SDES item, RTP SDES header extension for MID and RTCP packet type fields are present in one (S)RTP multiplexed media identification information entry, one UL packet matching all the presented fields is considered as matching the (S)RTP multiplexed media identification information entry.* * * End of Changes * * * *Alternative 2 for QoS Rules coding3GPP TSG-CT WG1 Meeting #153 C1-25xxxx Athens, Greece, 17-21 February 2025CR-Form-v12.2 CHANGE REQUEST24.501 CR xxxx rev - Current version: 19.1.1For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp. org / Change-Requests.Proposed change affects: UICC apps| | ME|~X~| Radio Access Network! I Core Network|~x]Applicant’s Ref.: P113005W001Title: Alt-2: Allow multiple multiplexed media packet filter components in one packet filter Source to WG: EricssonSource to TSG: C1Work item code: XRM_Ph2 Date: 2024-02-10 Category: B Release: Re I- 19Use one of the following categories: Use one of the following releases:F (correction) Rel-8 (Release 8)A (mirror corresponding to a change in an earlier Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11) release)B (addition of feature), Rel-16 (Release 16)C (functional modification of feature) Rel-17 (Release 17)D (editorial modification) Rel-18 (Release 18) Detailed explanations of the above categories can Rel-19 (Release 19) be found in 3GPP TR 21.900.Reason for change: As discussed in C1 -25xxxx, multiple RTP streams with different combination of the SSRC and / or PT might be multiplexed into the same IP flow. In this case, for the current coding approach, the IP packet filter component with the same content is repeated in several packet filters. And due to the limitation of maximum number of packet filters per each QoS rule, it might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule.So it is proposed to convey the multiplexed media packet filter component with the same IP packet filter component in one packet filter.This the the Alt-2 to allow the multiple multiplexed media packet filter component with the same IP packet filter component in one packet filter. In this alternative, the (S)RTP multiplexed media identification type is allowed to present more than once in one packet filter, and the value of (S)RTP multiplexed media identification type is encoded as a sequence of a one octet (S)RTP multiplexed media identification packet filter component type identifier and a fixed length (S)RTP multiplexed media identification packet filter component value field, the (S)RTP multiplexed media identification packet filter component type identifier can be SSRC, payload type, MID, and (S)RTCP packet type.In SA2 #166 meeting, the CR5958 (S2-2501108) was agreed to update the MID as followings:- (S)RTP Multiplexed Media Identification Information including a combination of at least one of the following:- Synchronization Source (SSRC). as defined by IETF RFC 3550 11851: - Payload Type (PT), as defined by IETF RFC 3550 11851:- RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID. as defined by IETF RFC 9143 1207|- RTCP packet type.The most important information is the identification-tag and the RTP SDES header extension id for MID, it can be used to parse the RTCP SDES item Media Identification (MID) combined with the SDES type field for MID which is 15, and it can be used to be combined with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID.Applicant’s Ref.: P113005W001So it is proposed to send the identification-tag and the RTP SDES header extension id for MID to the UE instead of RTCP SDES MID item and RTP SDES header extension for MID.Additionally, the underline of the title of reference

[0071] in clause 2 needs to be removed.Summary of change: 1). Introduce coding on allowing the multiple multiplexed media packet filter component with the same IP packet filter component in one packet filter; 2). Introduce MID and (S)RTCP packet type in the packet filters;3) EN on other packet filter component types is removed.Consequences if not For multiple multiplexed media packet filter components with the same IP approved: packet filter component, multiple packet filters are needed which is not efficient; Stage-2 requirement for supporting MID and (S)RTCP packet typenot fullfilled.Clauses affected: 2, 3.2, 9.11.4.13Y NOther specs X Other core specifications TS 23.501 CR 5958affected: X Test specifications TS / TR... CR...(show related CRs) X O& M Specifications TS / TR... CR...Other comments:This CR's revisionApplicant’s Ref.: P113005W001* * * First Change * * * *2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.- For a specific reference, subsequent revisions do not apply.- For a non-specific reference, the latest version applies. In the case of a reference to a 3 GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.[1] 3GPP TR 21.905: " Vocabulary for 3GPP Specifications".[…]

[0070] IETF RFC 8285: " A General Mechanism for RTP Header Extensions".

[0071] IETF RFC 3550: " RTP: A Transport Protocol for Real-Time Applications".[yy] IETF RFC 9143: "Negotiating Media Multiplexing Using the Session Description Protocol(SDP)".* * * Next Change * * * *3.2 AbbreviationsFor the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905 [1],[…]MID Media Identification[…]* * * Next Change * * * *9.11.4.13 QoS rulesThe purpose of the QoS rules information element is to indicate a set of QoS rules to be used by the UE, where each QoS rule is a set of parameters as described in subclause 6.2.5.1.1.2:a) for classification and marking of uplink user traffic; andb) for identification of a QoS flow which the network is to use for a particular downlink user traffic.NOTE: The UE needs to be aware of a QoS flow which the network is to use for a particular downlink user traffic e.g. to determine whether a resource is available for downlink media of a media stream of an SDP media description provided by the UE in an IMS session.The QoS rules may contain a set of packet filters consisting of zero or more packet filters for UL direction, zero or more packet filters for DL direction, zero or more packet filters for both UL and DL directions or any combinations of these. The set of packet filters determine the traffic mapping to QoS flows.The QoS rules information element is a type 6 information element with a minimum length of 7 octets. The maximum length for the information element is 65538 octets.The QoS rules information element is coded as shown in figure 9.11.4.13.1, figure 9.11.4.13.2,figure 9.11.4.13.3, figure 9.11.4.13.4 and table 9.11.4.13.1.Applicant’s Ref.: P113005W001octet 1 octet 2 octet 3 octet 4 octet u octet u+1 octet v octet v+1 octet w octet w+1octet x Figure 9.11.4.13.1: QoS rules information element8 7 6 5 4 3 2 1QoS rule identifier octet 4 Length of QoS rule octet 5octet 6 Rule operation code DQR Number of packet filters octet 7bitoctet 8* Packet filter listoctet m* QoS rule precedence octet m+1* 0 Segre QoS flow identifier (QFI) octet m+2* Spar gationeFigure 9.11.4.13.2: QoS rule (u=m+2)8 7 6 5 4 3 2 10 0 0 0 Packet filter identifier 1 Spare 0 0 0 0 Packet filter identifier 2 Spare 0 0 0 0 Packet filter identifier NSpareFigure 9.11.4.13.3: Packet filter list when the rule operation is "modify existing QoS rule and delete packet filters" (m=N+7)8 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8 Spare direction 1Length of packet filter contents 1 octet 9 Packet filter contents 1 octet 10octet m0 0 Packet filter Packet filter identifier 2 octet k+1 Spare direction 2Length of packet filter contents 2 octet k+2 Packet filter contents 2 octet k+3octet n octet n+1octet yApplicant’s Ref.: P113005W0010 0 Packet filter Packet filter identifier N octet y+1 Spare direction NLength of packet filter contents N octet y+2 Packet filter contents N octet y+3octet m Figure 9.11.4.13.4: Packet filter list when the rule operation is "create new QoS rule", or "modify existing QoS rule and add packet filters" or "modify existing QoS rule and replace all packet filters"Table 9.11.4.13.1: QoS rules information element[... cutoff as same as table in alt. 1, not copied]The packet filter contents field is of variable size and contains a variable number (at least one) of packet filter components except the "(S)RTP multiplexed mediaidentification information packet filter component". Each packet filter componentshall be encoded as a sequence of a one octet packet filter component typeidentifier and a fixed length packet filter component value field. The packet filtercomponent type identifier shall be transmitted first.[... cutoff as same as table in alt. 1, not copied]The "(S)RTP multiplexed media identification information type^aoket-fitterGempenewt" packet filter component can not be present in the packet filter with no" IP packet filter component".The term local refers to the UE and the term remote refers to an external networkentity.Packet filter component type identifierBits8765432 10000000 1 Match-all type (see NOTE 2)000 1 0000 IPv4 remote address type000 1 000 1 IPv4 local address type00 1 0000 1 IPv6 remote address / prefix length type00 1 000 1 1 IPv6 local address / prefix length type00 1 1 0000 Protocol identifier / Next header type0 1 000000 Single local port type0 1 00000 1 Local port range type0 1 0 1 0000 Single remote port type0 1 0 1 000 1 Remote port range type0 1 1 00000 Security parameter index type0 1 1 1 0000 Type of service / T raffic class type1 0000000 Flow label type1 000000 1 Destination MAC address type1 00000 1 0 Source MAC address type1 00000 1 1 802.1Q C-TAG VID type1 0000 1 00 802.1Q S-TAG VID type1 0000 1 0 1 802.1Q C-TAG PCP / DEI type1 0000 1 1 0 802.1Q S-TAG PCP / DEI type1 0000 1 1 1 Ethertype type1 000 1 000 Destination MAC address range type1 000 1 00 1 Source MAC address range type1 0 0 1 0 0 0 1 (S)RTP multiplexed media identification information type (see NOTE 3)Synchronization source (SSRC) typeAll other values are reserved.The description and valid combinations of packet filter component type identifiers ina packet filter are defined in 3GPP TS 23.501 [81.Applicant’s Ref.: P113005W001For "match-all type", the packet filter component shall not include the packet filter component value field.[...]For "(S)RTP multiplexed media identification information type", the packet filter component value field shall be encoded as variable number (at least one) of (S)RTP multiplexed media identification information packet filter components, each (S)RTP multiplexed media identification information packet filter component shall be coded as a one octet (S)RTP multiplexed media identification information packet filter component type identifier and a (S)RTP multiplexed media identification packet filter component value field. The (S)RTP multiplexed media identification packet filter component type identifier shall be transmitted first.(S)RTP multiplexed media identification information packet filter component type identifier (SeeBits8.0 0 0 0 0 0 0 1 Synchronization source (SSRC) type0 0 0 0 0 0 1 0 Payload type type0 0 0 0 0 0 1 1 MID identification-tag type0 0 0 0 0 1 0 0 RTP header extension id type0 0 0 0 0 1 0 1 RTCP packet type typeAll other values are spare.An (S)RTP multiplexed media identification information packet filter component for (s)RTCP shall contain the RTCP packet type and at least one of the SSRC type and MID identification-tag type.An (S)RTP multiplexed media identification information packet filter component for (s)RTP shall contain:a) SSRC type;b) payload type type;c) MID identification-tag type and IRTP header extension id type; or d) any combination of a) to c).For "synchronization source (SSRC) type", the (S)RTP multiplexed media identification information packet filter component value field shall be encoded as 4 octet SSRC field which specify the synchronization source identifier in the RTP header as specified in IETF RFC 3550

[0071] ,For "payload type type", the (S)RTP multiplexed media identification information packet filter component value field shall be encoded as octet payload type field which contains the binary representation of an integer between 1(inclusive) and 127(inclusive) as specified in IETF RFC 3550

[0071] ,For " MID identification-tag type", the (S)IRTP multiplexed media identification information packet filter component value field shall contain the length of MID identification-tag field, and the MID identification-tag field. The length of MID identification-tag is coded as one octet and indicates the length of the MID identification-tag field, and the identification-tag is encoded as UTF-8 string as specified in IETF RFC 9143 Ivy]. The length of MID identification-tag field is transmitted first and the MID identification-tag field is transmitted last.For " RTP header extension id type", the (S)RTP multiplexed media identification information packet filter component value field shall contain the RTP header extension id field. The RTP header extension id is coded as binary representation of an integer between 1( inclusive) and 255(inclusive) as defined inIETF RFC 8285

[0070] . The RTP header extension id is used to enable the parsing of RTP SDES header extension for MID.For" RTCP packet type type", the (S)RTP multiplexed media identification information packet filter component value field shall be encoded as one octet RTCP packet type field which contains the binary representation of an integer between200(inclusive) and 204(inclusive) as specified in IETF RFC 3550

[0071] .Applicant’s Ref.: P113005W001NOTE 1: Octet m+2 shall not be included without octet m+1.NOTE 2: The " Match-all type" packet filter component type identifier shall not beused with packet filter direction "downlink only".NOTE 3: When one or more of the "(S)RTP multiplexed media identification information type" packet filter component type identifiers present in a UL packet filter, the UL user data packet matching one of the (S)RTP multiplexed media identification information component indicates matching of the (S)RTP multiplexed media identification information component part of the UL packet filterNre of the SSIRC, payload type, IRTCP MID SIDES item,IRTIP SIDES header extension for MID and IRTCP packet type fields are present in one (S)RTP irrujltiiplexed media identification infoirmation entry,one UIL packet matching all the presented fields is considered asmatching the (S)IRTPjrryl^ identification information entry^* * * End of Changes * * * *Alternative 3 for QoS Rules coding3GPP TSG-CT WG1 Meeting #153 C1-25xxxx Athens, Greece, 17-21 February 2025CR-Form-v12.2 CHANGE REQUEST24.501 CR xxxx rev - Current version: 19.1.1For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp. org / Change-Requests.Proposed change affects: UICC apps| | ME|~x] Radio Access Network! I Core NetworkFx] Title: Alt-3: Allow multiple multiplexed media packet filter components in one packet filter Source to WG: EricssonSource to TSG: C1Work item code: XRM_Ph2 Date: 2024-02-10 Category: B Release: Re I- 19Use one of the following categories: Use one of the following releases:F (correction) Rel-8 (Release 8)A (mirror corresponding to a change in an earlier Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11) release)B (addition of feature), Rel-16 (Release 16)C (functional modification of feature) Rel-17 (Release 17)D (editorial modification) Rel-18 (Release 18) Detailed explanations of the above categories can Rel-19 (Release 19) be found in 3GPP TR 21.900.Reason for change: As discussed in C1 -25xxxx, multiple RTP streams with different combination of the SSRC and / or PT might be multiplexed into the same IP flow. In this case, for the current coding approach, the IP packet filter component withApplicant’s Ref.: P113005W001the same content is repeated in several packet filters. And due to the limitation of maximum number of packet filters per each QoS rule, it might happen that 15 packet filters are not enough for (S)RTP multiplexed media streams to the same IP flow on one QoS rule. So it is proposed to convey the multiplexed media packet filter component with the same IP packet filter component in one packet filter. This the the Alt-3 to define a new IE for (S)RTP multiplexed media identification information which is a list of (S)RTP multiplexed media identification entries, and each entry contains at least one of SSRC, PT, MID, RTCP packet type. And define a packet filter component type identifier for the value part of the (S)RTP multiplexed media identification information IE. X X In SA2 #166 meeting, the CR5958 (S2-2501108) was agreed to update the MID as followings: - (S)RTP Multiplexed Media Identification Information including a combination of at least one of the following: - Synchronization Source (SSRC). as defined by IETF RFC 3550 11851: - Payload Type (PT), as defined by IETF RFC 3550 11851: - RTCP SDES item Media Identification (MID) and RTP SDES header extension for MID. as defined by IETF RFC 9143 12071 - RTCP packet type. The most important information is the identification-tag and the RTP SDES header extension id for MID, it can be used to parse the RTCP SDES item Media Identification (MID) combined with the SDES type field for MID which is 15, and it can be used to be combined with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID. So it is proposed to send the identification-tag and the RTP SDES header extension id for MID to the UE instead of RTCP SDES MID item and RTP SDES header extension for MID. Additionally, the underline of the title of reference

[0071] in clause 2 needs to be removed.Summary of change: 1). Introduce coding on allowing the multiple multiplexed media packet filter component with the same IP packet filter component in one packet filter; 2). Introduce MID and (S)RTCP packet type in the packet filters; 3) EN on other packet filter component types is removed.Consequences if not For multiple multiplexed media packet filter components with the same IP approved: packet filter component, multiple packet filters are needed which is not efficient: Stage-2 requirement for supporting MID and (S)RTCP packet type not fullfilled.Clauses affected: 2, 3.2, 9.11.4.13, 9.11.4. XX (new)Y NOther specs X Other core specifications TS 23.501 CR 5958 affected: Test specifications TS / TR... CR...(show related CRs) O& M Specifications TS / TR... CR...Other comments: |This CR's revision history:Applicant’s Ref.: P113005W001* * * First Change * * * *2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.- For a specific reference, subsequent revisions do not apply.- For a non-specific reference, the latest version applies. In the case of a reference to a 3 GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.[1] 3GPP TR 21.905: " Vocabulary for 3GPP Specifications".[…]

[0070] IETF RFC 8285: " A General Mechanism for RTP Header Extensions".

[0071] IETF RFC 3550: " RTP: A Transport Protocol for Real-Time Applications".[yy] IETF RFC 9143: "Negotiating Media Multiplexing Using the Session Description Protocol(SDP)".* * * Next Change * * * *3.2 AbbreviationsFor the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905 [1],[…]MID Media Identification[…]* * * Next Change * * * *9.11.4.13 QoS rulesThe purpose of the QoS rules information element is to indicate a set of QoS rules to be used by the UE, where each QoS rule is a set of parameters as described in subclause 6.2.5.1.1.2:a) for classification and marking of uplink user traffic; andb) for identification of a QoS flow which the network is to use for a particular downlink user traffic.NOTE: The UE needs to be aware of a QoS flow which the network is to use for a particular downlink user traffic e.g. to determine whether a resource is available for downlink media of a media stream of an SDP media description provided by the UE in an IMS session.The QoS rules may contain a set of packet filters consisting of zero or more packet filters for UL direction, zero or more packet filters for DL direction, zero or more packet filters for both UL and DL directions or any combinations of these. The set of packet filters determine the traffic mapping to QoS flows.The QoS rules information element is a type 6 information element with a minimum length of 7 octets. The maximum length for the information element is 65538 octets.The QoS rules information element is coded as shown in figure 9.11.4.13.1, figure 9.11.4.13.2,figure 9.11.4.13.3, figure 9.11.4.13.4 and table 9.11.4.13.1.Applicant’s Ref.: P113005W001octet 1 octet 2 octet 3 octet 4 octet u octet u+1 octet v octet v+1 octet w octet w+1octet x Figure 9.11.4.13.1: QoS rules information element8 7 6 5 4 3 2 1QoS rule identifier octet 4 Length of QoS rule octet 5octet 6 Rule operation code DQR Number of packet filters octet 7bitoctet 8* Packet filter listoctet m* QoS rule precedence octet m+1* 0 Segre QoS flow identifier (QFI) octet m+2* Spar gationeFigure 9.11.4.13.2: QoS rule (u=m+2)8 7 6 5 4 3 2 10 0 0 0 Packet filter identifier 1 Spare 0 0 0 0 Packet filter identifier 2 Spare 0 0 0 0 Packet filter identifier NSpareFigure 9.11.4.13.3: Packet filter list when the rule operation is "modify existing QoS rule and delete packet filters" (m=N+7)Applicant’s Ref.: P113005W0018 7 6 5 4 3 2 10 0 Packet filter Packet filter identifier 1 octet 8 Spare direction 1Length of packet filter contents 1 octet 9 Packet filter contents 1 octet 10octet m0 0 Packet filter Packet filter identifier 2 octet k+1 Spare direction 2Length of packet filter contents 2 octet k+2 Packet filter contents 2 octet k+3octet n octet n+1 octet y0 0 Packet filter Packet filter identifier N octet y+1 Spare direction NLength of packet filter contents N octet y+2 Packet filter contents N octet y+3octet m Figure 9.11.4.13.4: Packet filter list when the rule operation is "create new QoS rule", or "modify existing QoS rule and add packet filters" or "modify existing QoS rule and replace all packet filters"Table 9.11.4.13.1: QoS rules information element[... cutoff as same as table in alt. 1, not copied]The "(S)RTP multiplexed media identification information typepaeket-fttefGempenewt" packet filter component can not be present in the packet filter with no" IP packet filter component".The term local refers to the UE and the term remote refers to an external networkentity.Packet filter component type identifierBits8765432 10000000 1 Match-all type (see NOTE 2)000 1 0000 IPv4 remote address type000 1 000 1 IPv4 local address type00 1 0000 1 IPv6 remote address / prefix length type00 1 000 1 1 IPv6 local address / prefix length type00 1 1 0000 Protocol identifier / Next header type0 1 000000 Single local port type0 1 00000 1 Local port range type0 1 0 1 0000 Single remote port type0 1 0 1 000 1 Remote port range type0 1 1 00000 Security parameter index type0 1 1 1 0000 Type of service / T raffic class type1 0000000 Flow label type1 000000 1 Destination MAC address type1 00000 1 0 Source MAC address type1 00000 1 1 802.1Q C-TAG VID type1 0000 1 00 802.1Q S-TAG VID type1 0000 1 0 1 802.1Q C-TAG PCP / DEI type1 0000 1 1 0 802.1Q S-TAG PCP / DEI type1 0000 1 1 1 Ethertype type1 000 1 000 Destination MAC address range type1 000 1 00 1 Source MAC address range typeApplicant’s Ref.: P113005W0011 0 0 1 0 0 0 1 (S)RTP multiplexed media identification information type (see NOTE 3)1 0 0 1 0 0 1 0 Payload type typeAll other values are reserved.The description and valid combinations of packet filter component type identifiers in a packet filter are defined in 3GPP TS 23.501 [8],For "match-all type", the packet filter component shall not include the packet filter component value field.[...]For "(S)RTP multiplexed media identification information type", the packet filter component value field shall be encoded as length and value part of (S)RTP multiplexed media identification information IE.cha#-be-eHeedeel-ae-4-eetet-SSRG-feld-wt^^identiftewia-tte-RTR+ieadei^^fmr-"paylead4ype4ype^'7-ttie-paGkeflfiltef-GampeFieFft-vatue-fie#-&hatl-be-ewGeded-a& Getet-paytoad-type-fekhA+HGRaortam^^betweera-4tiifidusive|mRd-44gflwfa^^ _ NOTE 1: Octet m+2 shall not be included without octet m+1.NOTE 2: The " Match-all type" packet filter component type identifier shall not be used with packet filter direction "downlink only".Nj ' l ll > When the "(S ill 11 ' multiplexed media identification infoirmation type" packet filter component type identifier presents in a U IL packet filter, theUL user data packet matching any (S)RTP multiplexed mediaidentification information entry indicates matching of the (S)RTP multiplexed media identification information component of the UL packetfilter.EditeiR-nrte^^iw-paeket-ffltw-eo^^* * * Next Change * * * *wtiMMedniediaJ^The purpose of the (S)RTP multiplexed media identification information information element is to provide (S)RTP multiplexed media information for traffic identification and differentiated QoS flow mapping for multiplexed media flows in the same transport connection to the UE.'The (S)R'TP miiltiplexed media infonnation infonnation element is coded as shown in figi LI. liyiib -' H i " Irani. - H i ": U m " I I I ' ' i ml rail I n- 1 1 I ' ' IThe (S)RTP multiplexed media information information element is a type 4 information element with a minimum length of 5 octets.Applicant’s Ref.: P113005W0018 7 6 5 4 3 2 1(S)RTP multiplexed media identification information IEI octet 1octet 2Length of (S)RTP multiplexed media identification information contentsNumber of (S)RTP multiplexed media identification information entries octet 3octet 4(S)RTP multiplexed media identification information entry 1octet uoctet (u+D*(S)RTP multiplexed media identification information entry 2octet w*octet (w+1)*(S)RTP multiplexed media identification information entry noctet t*Figure 9.11.4.XX.1: (S)RTP multiplexed media identification information information element8 7 6 5 4 3 2 10 0 0 RPTPI RHEID MITPI PT1 SSRCI octet 4Spare Spare Spare PISynchronization Source (SSRC) octet 5*octet 8*Payload type octet p* (see NOTE)MID identification-tag octet g* (see NOTE)octet r*RTP header extension id octet s* (see NOTE)octet t*IP packet type octet h* (seehfN field is placed immediately after the last present preceding fieldFigure 9.11.4.XX.2: (S)RTP multiplexed media identification information entry8 7 6 5 4 3 2 1Length of MID identification-tag octet gMID identification-tag octet (g+1)octet r Figure 9.11.4.XX.3: MID identification-tag1 JL h' '« j j t \ \ j > S)IRTP inulltiiplexecl media identification information information elementLength of (S)IRTIP multiplexed media identification information contents (octet 2 andoctet 3)The length of (S)RTP multiplexed media identification information contents field contains the length of the content of (S)RTP multiplexed media identification informationinformation element.(S)RTP multiplexed media identification information entryAn (S)RTP multiplexed media identification information entry for (s)RTCP shall containthe RTCP packet type and at least one of the SSRC and MID identification-tag fieldsAn (S)RTP multiplexed media identification information entry for (s)RTP shall contain:a) SSRC field;b) payload type field;Applicant’s Ref.: P113005W001c) MID identification-tag and RTP header extension id field; ord) any combination of a) to c)SSIRC presence indicator (SSRCI) (bit 1 of octet i > ■ * ee 11; < I II hThe SSRCI field indicates whether the SSRC field is included or notBit10 SSIRC not included1 SSRC includedPayload type presence indicatoir (IPTI) (bit 2 of octet > i. ee NOTE;l iThe PTI field indicates whether the payload type field is included or notBit20 Payload type not included1 Payload type includedMID identification-tag presence indicator (MITPI) (bit 3 of octet 4) (see NOTE 1)The MITPI field indicates whether the MID identification-tag field is included or not Bit30 MID identification-tag not included1 MID identification-tag includedRTP header extension id presence indicator (RHEIDPI) (bit 4 of octet 4) (see NOTE 1) The RHEIDPI field indicates whether the RTP SDES header extension for MID field is included or notBl40 RTP header extension id not included1 RTP header extension id includedRTCP packet type presence indicator (RPTPI) (bit 5 of octet 4) (see NOTE 1) The RPTPI field indicates whether the RTCP packet type field is included or not Bit50 RTCP packet type not included1 RTCP packet type includedThe other bits in octet 4 are spareSynchronization source (SSI1> ■ ’ tef 5 to octet 8) (see N‘ ' l l,The synchronization source (SSRC) field contains the synchronization source identifier in the RTP header as specified in IETF RFC 3550

[0071] .Payload type (octet p) (see NOTE 2)The payload type type field contains the binary representation of an integer between 1 (inclusive) and 127 (inclusive) as specified in IETF RFC 3550

[0071] MID identification-tag (octet q to octet r)The MID identification-tag field contains an identification-tag as specified inIETF RFC 9143 [yy] and encoded as UTF-8 string.The MID identification-tag can be combined with the SDES type field for MID which is 15 to enable the parsing of RTCP MID SDES item as specified in IETF RFC 9143 [yy]. The MID identification-tag can be combined with the RTP header extension id to enable the parsing of RTP SDES header extension for MID.IRTIP header extension id (octet s)This field contains the the RTP header extension id which is coded as binary representation of an integer between 1(inclusive) and 255(inclusive) as defined in IETF RFC 8285

[0070] . The RTP header extension id can not present without MID identification-tag.IRTCP packet type (octet h) (see NOTE 2)Applicant’s Ref.: P113005W001The RTCP packet type field contains the binary representation of an integer between200 (inclusive) and 204 (inclusive) as specified in IETF RFC 3550

[0071] .NOTE 1: At least one of the SSRCI, PTI, MITPI, RHEIDPI and RPTPI shall be set to 1in the (S)RTP multiplexed media identification information entryNOTE 2: When one or more of the SSRC, payload type, RTCP MID SDES item RTPSDES header extension for MID and RTCP packet type fields are present in one (S)RTP multiplexed media identification information entry, one UL packetmatching all the presented fields is considered as matching the (S)RTPmultiplexed media identification information entry* * * End of Changes * * * *Proposed changes to TS 29.1223GPP TSG-CT WG3 Meeting #139 C3-245XXXAthens, Greece, 17 – 23 February, 2025CR-Form-v12.3 CHANGE REQUEST29.122 CR xxxx rev - Current version: 19.1.0For HELP on using this form: comprehensive instructions can be found at http: / / www.3 pp. org / Change-Requests.Proposed change affects: UICC apps| | ME| | Radio Access Network! I Core Network!)^] Title: Introduce (S)RTP Multiplexed Media InformationSource to WG: EricssonSource to TSG: CT3Work item code: XRM_Ph2 Date: 2025-02-02 Category: B Release: Re I- 19Use one of the following categories: Use one of the following releases:F (correction) Rel-8 (Release 8)A (mirror corresponding to a change in an earlier Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11) release)B (addition of feature), Rel-17 (Release 17)C (functional modification of feature) Rel-18 (Release 18)D (editorial modification) Rel-19 (Release 19) Detailed explanations of the above categories can Rel-20 (Release 20) be found in 3GPP TR 21.900.Reason for change: There is still an Editor’s Note that the mpxMediainfos need to be clarified. As stated in the discussion paper, we would to propose the Multiplexed Media information to be defined as uplink and downlink separately.dSummary of change: Add the data type for provisioning of (S)RTP Multiplexed Media Information for the AsSessionWithQoS creation and update.Remove Editor’s Note.Consequences if not (S)RTP Multiplexed Media Information can not provided by AF to furtherapproved: identify the multiplexed media flows. Feature in stage 2 is not supported.Applicant’s Ref.: P113005W001Clauses affected: 5.2.1.2.8, A.2Y NOther specs X Other core specifications TS / TR... CR...affected: X Test specifications TS / TR... CR...(show related CRs) X O& M Specifications TS / TR... CR...Other comments: This CR introduces backward compatible feature on the Open API:TS29122_CommonData.yaml.| This CR's revision history:Applicant’s Ref.: P113005W001Additional discussion(if needed):Proposed changes:*** First Change ***5.2.1.2.8 Type: FlowinfoThis type represents flow information. It shall comply with the provisions defined in table 5.2.1.2.8-1.Table 5.2.1.2.8-1: Definition of the Flowinfo datatypeAttribute name Data type Cardinality Description Applicability flowld integer 1 Indicates the IP flow.flowDescriptions array(string) 0..2 Indicates the packet filters ofthe IP flow.Refer to clause 5.3.8 of3GPP TS 29.214

[0010] forencoding. It shall contain ULand / or DL IP flowdescription.tosTC TosTrafficClass 0..1 Type of service or T rafficClass.mpxMediaUI Infos array(MpxMedialnfo)TBP 0.. N Contains the Multiplexed MpxMediaMedia information for theUplink or Downlink IP flowsbased on the flowdescription.mpxMediaDIInfos array(MpxMedialnfo) 0.. N Contains the Multiplexed MpxMediaMedia Information for theDownlink IP flows based onthe flow description.NOTE: The "tosTC" attribute can be included when another packet filter attribute is needed to differentiate between packet flows. For example, packet flows encapsulated and encrypted by a tunnelling protocol can be differentiated by the ToS / TC value of the outer header if appropriately set by the application. To use ToS / TC for service dataflow detection, network configuration by the operator (and additionally by the 3rd party Service Provider when the transport network is not fully within the operator control) needs to ensure there is no ToS / TC re-marking applied along the path from the application to the PSA UPF and the specific ToS / TC values are managed properly to avoid potential collision with other usage (e.g., paging policy differentiation).Proposed changes to TS 29.5143GPP TSG-CT WG3 Meeting #139 C3-245xxx Athens, Greece, 17-23 February, 2025CR-Form-v12.3 CHANGE REQUEST29.514 CR xxxx rev - Current version: 19.1.0Applicant’s Ref.: P113005W001For HELP on using this form: comprehensive instructions can be found athttp: / / www.3 pp. org / Change-Requests.Proposed change affects: UICC apps| | ME | | Radio Access Network! I Core Network[) | Title: Support of Connect-UDP protocol to deliver Media related informationSource to WG: EricssonSource to TSG: CT3Work item code: XRM_Ph2 Date: 2024-02-01 Category: B Release: Re I- 19Use one of the following categories: Use one of the following releases:F (correction) Rel-8 (Release 8)A (mirror corresponding to a change in an earlier Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11) release)B (addition of feature), Rel-17 (Release 17)C (functional modification of feature) Rel-18 (Release 18)D (editorial modification) Rel-19 (Release 19) Detailed explanations of the above categories can Rel-20 (Release 20)be found in 3GPP TR 21.900.Reason for change: There is still an Editor’s Note that the mpxMediainfos need to be clarified. As stated in the discussion paper, in this CR we propose the Multiplexed Media information to be defined as uplink and downlink separately.Futhermore, the definition of multiplexed Media identification information has been further updated in the SA-166-e ad hoc meeting, the corresponding stage 3 also need an update.Summary of change: Update the MpxMedialnfoRemove editor’s noteConsequences if not Multiplexed Media information is not provided for futher identify theapproved: multiplexed media flows. Feature in stage 2 is not supportedClauses affected: 4.2.2.47, 4.2.3.46, 5.6.2.8, 5.6.2.27, 5.6.2.61, 5.6.2.62, 5.6.2.63, 5.6.2.64, A.2Y NOther specs X Other core specifications TS / TR 23.501 CR#5958 affected: X Test specifications TS / TR... CR...(show related CRs) X O& M Specifications TS / TR... CR...Other comments: This CR introduces backward compatible feature on the Open API:TS29514_Npcf_PolicyAuthorization.yaml.This CR's revision history:Applicant’s Ref.: P113005W001Additional discussion(if needed):Proposed changes:*** First Change ***2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.- For a specific reference, subsequent revisions do not apply.- For a non-specific reference, the latest version applies. In the case of a reference to a 3 GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.[...]

[0058] IETF RFC 3550: " RTP: A Transport Protocol for Real-Time Applications".

[0059] IETF RFC 9143: "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)".

[0060] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications".

[0061] _ IETF RFC 8285: " A General Mechanism for RTP Header Extensions".*** Next Change ***4.2.2.47 Provisioning of the Multiplexed Media InformationWhen the " MpxMedia" feature is supported, the NF service consumer may specify the Multiplexed Media Information for the Uplink or Downlink IP flows within the "mpxMediaUlInfos" or "inpxMediaDlInfos" attribute to uniquely identify each media flow of multiplexed media.NOTE: Data traffic of different media components with different QoS requirements could be multiplexed on the same end-to-end transport layer connection. Multiplexed Media Information can be useful when another packet filter attribute is needed to differentiate between the multiplexed media flows.The PCF shall reply to the NF service consumer as described in clause 4.2.2.2.As result of this action, the PCF shall determine the PCC rules and provide to the SMF as described in 3GPP TS 29.512 [8],*** Next Change ***4.2.3.46 Modification of the Multiplexed Media InformationWhen the " MpxMedia" feature is supported, the NF service consumer may include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, in the corresponding "medSubComponent" entries of the "medComponents" attribute, the "mpxMediaUlInfos" and / or "inpxMediaDlInfos" attributes with the Multiplexed Media Information.As a result of this action, the PCF shall update the policies for the multiplexed media flows to the SMF as described in 3GPP TS 29,512 [8], _*** Next Change ***Applicant’s Ref.: P113005W0015.6.2.8Type MediaSubComponentTable 5.6.2.8-1: Definition of type MediaSubComponentAttribute name Data type P Cardinality Description Applicability afSigProtocol AfSigProtocol O 0..1 Indicates the protocol used for ProvAFsignalF signalling between the UE and the NF low service consumer. It may be includedonly if the "flowUsage" attribute is set tothe value " AF SIGNALLING".ethfDescs array(EthFlowDescri O 1..2 Contains the flow description for theption) Uplink and / or Downlink Ethernet flows.fNum integer M 1 Identifies the ordinal number of theservice data flow.fDescs array(FlowDescriptio O 1..2 Contains the flow description for then) Uplink and / or Downlink IP flows.addlnfoFlowDesc array(AddFlowDescr O 1..2 Represents additional flow description AddFlowDescri s iptionlnfo) information (flow label and IPsec SPI) ptionlnformatio per Uplink and / or Downlink IP flows n represented in the "fDescs" attribute.fStatus FlowStatus O 0..1 Indicates whether the status of theservice data flows is enabled ordisabled.flowUsage FlowUsage O 0..1 Flow usage of the flows (e.g. RTCP, AF signalling).marBwUI BitRate O 0..1 Maximum requested bandwidth for theUplink.marBwDI BitRate O 0..1 Maximum requested bandwidth for theDownlink.tosTrCI TosTrafficClass O 0..1 Type of Service or Traffic Class.evSubsc EventsSubscReqDat O 0..1 Identifies the events the application EnQoSMon, a subscribes to at creation of a media L4S component. (NOTE 1, NOTE 2)mpxMediaUlInfos TBDarray(MpxMediaInfo) O 1..N Contains the Multiplexed Media MpxMedia Information for the Uplink or DownlinkIP flows based on the flow description. mpxMediaDIInfos array! MpxMedialnfo) O 1.. N Contains the Multiplexed Media MpxMedia Information for the Downlink IP flowsbased on the flow description.NOTE 1: If attribute "evSubsc" is present, one or more of the following lEs within EventsSubscReqData data type may be included: "events", "notifUri", "reqQosMonParams", "qosMon", "qosMonDatRate", "pdvReqMonParams", "pdvMon", "congestMon", "notifCorreld", "rttMon", "directNotiflnd", "avrgWndw". In addition, when the attribute "events" is present, only the following Enumeration " AfEvent" may be included: " QOSJMONITORING", " PACK_DEL_VAR", " RT_DELAY_TWO_QOS_FLOWS", " L4S_SUPP".NOTE 2: Within the MediaSubComponent entry, the NF service consumer may include the subscription for congestion measurements within the "evSubsc" attribute only if the " I4slnd" attribute is not included withinthe corresponding MediaComponent entry.The bit rate information and flow status information provided within the " MediaSubComponent" data type takes precedence over information provided within " MediaComponent" data type.All service data flows within a " MediaSubComponent" data type are permanently disabled by supplying " FlowStatus" data type with a deletion indication.If the " EnQoSMon" feature is supported, and the NF service consumer includes the attribute "evSubsc" in the " MediaSubComponent" data type with a subscription to a specific event, then the "evSubsc" attribute within the " AppSessionContextReqData" data type shall not include a subscription to notifications for that specific event. In this case, the PCF shall use the value of the "notifUri" attribute included within the "evSubsc" attribute in the " MediaSubComponent" data type as target URI of the HTTP POST request for that specific event notification. NOTE: The NF service consumer can provide different values per media subcomponent for the "notifUri" attribute and / or "notifCorreld" attribute, e.g. to identify to the media subcomponent of a received report.Applicant’s Ref.: P113005W001Editor's note: Further (S)RTP Multiplexed Media Information for identification of multiplexed RTCP packets is FFS depending on input from SA4.How the data type "MpxMediaInfo" is used for the attribute "mpxMediaInfos" and the corresponding impact to the OpenAPI are FFS.*** Next Change ***5.6.2.27 Type MediaSubComponentRmThis data type is defined in the same way as the " MediaSubComponent" data type, but:- with the OpenAPI "nullable: true" property;- the removable attributes "marBwDl", "marBwUl", defined with the removable data type " BitRateRm"; the removable attribute "tosTrO", defined with the removable data type " TosTrafficClassRm"; the removable attribute "evSubsc" defined with the removable data type " EventsSubscReqDataRm"; and - the removable attributes "ethfDescs" and "fDescs" and "addlnfoFlowDescs" are defined as nullable in the OpenAPI.Applicant’s Ref.: P113005W001Table 5.6.2.27-1: Definition of type MediaSubComponentRm Attribute name Data type P Cardinality Description Applicability afSigProtocol AfSigProtocol o 0..1 Indicates the protocol used for ProvAFsignalF signalling between the UE and the NF low service consumer. It may be includedonly if the "flowUsage" attribute is set tothe value " AF SIGNALLING".ethfDescs array(EthFlowDescri o 1..2 Contains the flow description for theption) Uplink and / or Downlink Ethernet flows.fNum integer M 1 Identifies the ordinal number of the IPflow.fDescs array(FlowDescriptio O 1..2 Contains the flow description for then) Uplink and / or Downlink IP flows.addlnfoFlowDesc array(AddFlowDescr O 1..2 Represents additional flow description AddFlowDescri s iptionlnfo) information (flow label and IPsec SPI) ptionlnformatio per Uplink and / or Downlink IP flows n represented in the "fDescs" attribute.fStatus FlowStatus O 0..1 Indicates whether the status of theservice data flows is enabled ordisabled.flowUsage FlowUsage O 0..1 Flow usage of the flows (e.g. RTCP, AF signalling).marBwUI BitRateRm O 0..1 Maximum requested bandwidth for theUplink.marBwDI BitRateRm O 0..1 Maximum requested bandwidth for theDownlink.tosTrCI T osT rafficClassRm O 0..1 Type of Service or Traffic Class.evSubsc EventsSubscReqDat O 0..1 Identifies the events the application EnQoSMon, aRm subscribes to at update of a media L4S component. (NOTE 1, NOTE 2)mpxMediaUlInfos array(MpxMediaInfo) O 1..N Contains the Multiplexed Media MpxMedia TBD Information for the Uplink or DownlinkIP flows based on the flow description. mpxMediaDlInfos array(MpxMediaInfo) O 1..N Contains the Multiplexed Media MpxMedia Information for the Downlink IP flowsbased on the flow description.NOTE 1: If attribute "evSubsc" is present, one or more of the following lEs within EventsSubscReqDataRm data type may be included: "events", "notifUri", "reqQosMonParams", "qosMon", "qosMonDatRate", "pdvReqMonParams", "pdvMon", "congestMon", "notifCorreld", "rttMon", "directNotiflnd", "avrgWndw". In addition, when the attribute "events" is present, only the following Enumeration " AfEvent" may be included: " QOSJMONITORING", " PACK_DEL_VAR", " RT_DELAY_TWO_QOS_FLOWS", " L4S_SUPP".NOTE 2: Within a MediaSubComponentRm entry, the NF service consumer may include the subscription for congestion measurements within the "evSubsc" attribute only if the " I4slnd" attribute is not included withinthe corresponding MediaComponent entry.Editor's note: Further (S)RTP Multiplexed Media Information for identification of multiplexed RTCP packets is FFS depending on input from SA4.*** Next Change ***Applicant’s Ref.: P113005W0015.6.2.61 Type MpxMediaInfossrcld Uinteqer C 0..1 Contains the synchronization source asdefined in IETF RFC 3550

[0058] (NOTE 1) (NOTE 2)payloadType integer c 0..1 Integer between and including 1 and127.When present, this IE shall contain thePayload Type (PT) values in theheader of RTP packets, as defined inIETF RFC 3550

[0058] (NOTE 2)midldTaq string c 1 Contains the MID identification-tag asdefined in IETF RFC 9143

[0059] .(NOTE 1) (NOTE 2)rtpHeaderExtld integer C 1 Integer between and including 1 and255.Contains the RTP Header extension Idas defined in IETF RFC 8285

[0061] .(NOTE 2)rtcpPt integer C 0..1 Integer between and including 200 and204.When present, this IE shall contain thePacket Type (PT) values of RTCPpackets, as defined inIETF RFC 3550

[0058] (NOTE 1)NOTE 1: The multiplexed media information for the (s)RTCP streams shall contain the attribute "rtcpPt", and at least one of the attributes "ssrcId" and "midIdTag", and the other attributes shall not be present.NOTE 2: The multiplexed media information for the (s)RTP steams shall contain at least one one of the combinations: a) "ssrcld", b) "payloadType", and c) "rtpHeaderExtld" and "midldTaq", and the other attributes shall not be present.Proposed changes to TS 29.5123GPP TSG-CT WG3 Meeting #139 C3-245xxxAthens, Greece, 17 – 23 February, 2025CR-Form-v12.3 CHANGE REQUEST29.512 CR xxxx rev - Current version: 19.1.0For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp. org / Change-Requests.Applicant’s Ref.: P113005W001Proposed change affects: UICC apps| | ME | | Radio Access Network! I Core Network[) | Title: Introduce (S)RTP Multiplexed Media InformationSource to WG: EricssonSource to TSG: CT3Work item code: XRM_Ph2 Date: 2025-02-02 Category: B Release: Re I- 19Use one of the following categories: Use one of the following releases:F (correction) Rel-8 (Release 8)A (mirror corresponding to a change in an earlier Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11) release)B (addition of feature), Rel-17 (Release 17)C (functional modification of feature) Rel-18 (Release 18)D (editorial modification) Rel-19 (Release 19) Detailed explanations of the above categories can Rel-20 (Release 20)be found in 3GPP TR 21.900.Reason for change: There is still an Editor’s Note that the mpxMediainfos need to be clarified. As stated in the discussion paper, we would to propose the Multiplexed Media information to be defined as uplink and downlink separately.Summary of change: Add the data type for provisioning of (S)RTP Multiplexed Media Information for the creation and update.Remove Editor’s Note.Consequences if not (S)RTP Multiplexed Media Information is not provided for PCC rules. Featureapproved: in stage 2 is not supported.Clauses affected: 5.6.2.14, A.2Y NOther specs X Other core specifications TS / TR... CR...affected: X Test specifications TS / TR... CR...(show related CRs) X O& M Specifications TS / TR... CR...Other comments: This CR introduces backward compatible feature on the Open API:TS29122_CommonData.yaml.This CR's revision history:Proposed changes:*** First Change ***5.6.2.14 Type FlowinformationTable 5.6.2.14-1: Definition of type Flowinformation Attribute name Data type P Cardinality Description Applicability flowDescription FlowDescription O 0..1 Contains the packet filters of the IPflow(s).ethFlowDescription EthFlowDescription O 0..1 Defines a packet filter for an Ethernetflow. If the "fDir" attribute is included, itshall be set to " DOWNLINK". If the"fDir" attribute is never provided, theaddress information within the "ethFlowDescription" attribute shall beencoded in downlink direction.packFiltld string o 0..1 An identifier of packet filter. (NOTE) packetFilterUsage boolean o 0..1 Indicates whether the packet filter shallbe sent to the UE.- "true" indicates that the packet filtershall be sent to the UE.- "false" indicates that the packetfilter shall not be sent to the UE.- The default value is "false", if theattribute is not present and has notbeen supplied previously.tosTrafficClass string o 0..1 2-octet string. The first octet containsthe Ipv4 Type-of-Service or the Ipv6Traffic-Class field and the second octetcontains the ToS / Traffic mask field in hexadecimal representation. Eachcharacter in the string shall take avalue of "0" to "9" or " A" to " F" andshall represent 4 bits. One example isthat of a TFT packet filter as defined in3GPP TS 24.008

[0041] ,spi string o 0..1 4 octet string, representing the security parameter index of the IPSec packet in hexadecimal representation. Eachcharacter in the string shall take avalue of "0" to "9" or " A" to " F" andshall represent 4 bits. One example isthat of a TFT packet filter as defined in3GPP TS 24.008

[0041] ,flowLabel string o 0..1 3-octet string, representing the Ipv6flow label header field in hexadecimal representation. Each character in thestring shall take a value of "0" to "9" or" A" to " F" and shall represent 4 bits.One example is that of a TFT packetfilter as defined in3GPP TS 24.008

[0041] ,flowDirection FlowDirectionRm o 0..1 Indicates the direction / directions that afilter is applicable, downlink only,uplink only or both down- and uplink (bidirectional).mpxMediaUlInfos array(MpxMediaInf o) 1..N Contains the Multiplexed Media MpxMedia Information for the Uplink or DownlinkIP flows based on the flow description.mpxMediaDIInfos array(MpxMediaInf o) O 1..N Contains the Multiplexed Media MpxMedia Information for the Downlink IP flowsbased on the flow description.NOTE: The PCF shall only assign the "packFiltld" atribute for PCC rules created as a result of UE-initiated resourceallocation.Editor's note: Further (S)RTP Multiplexed Media Information for identification of multiplexed RTCP packets is FFS depending on input from SA4.^

Claims

ClaimsWhat is claimed is:

1. A method performed by wireless device, the method comprising:obtaining packet filters comprising one or more (S)RTP multiplexed media identification information to identify one or more media flows in one or more IP flows, wherein each (S)RTP multiplexed media identification information includes MID identification-tag and / or RTP SDES header extension id; storing the packet filters.

2. The method of claim 1 wherein the method further comprises using MID identification-tag to parse RTCP MID SDES item of a media flow when performing Uplink (UL) PACKET matching.

3. The method of claim 1 or 2 wherein the method further comprises using MID identification-tag with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID of media flow.

4. The method of claim 1, wherein the step of obtaining comprises receiving the packet filters as part of a PDU session establishment procedure and / or PDU session modification procedure.

5. The method of any one of claim 1 to 4 wherein the packet filters are included in QoS Rules.

6. A wireless device configured to perform the method of any one of claim 1-5.

7. A wireless device comprising one or more processors, a transmitter / receiver and memory comprising instructions which when executed by the one or more processors enable the wireless device to perform the method of any one of claim 1-5.

8. A computer readable memory comprising instructions which when executed by one or more processors of a wireless device configures the wireless device to perform any one of claim 1-5.

9. A method performed by a User Plane function (UPF), the method comprising:obtaining from a Session Management Function (SMF) packet filters comprising one or more (S)RTP multiplexed media identification information to identify one or more media flows in one or more IP flows, wherein each (S)RTP multiplexed media identification information includes MID identificationtag and / or RTP SDES header extension id;storing the packet filters.6910. The method of claim 9 wherein the method further comprises using MID identification-tag to parse RTCP MID SDES item of a media flow when performing downlink (DL) PACKET matching.

11. The method of claim 9 or 10 wherein the method further comprises using MID identification-tag with the RTP SDES header extension id for MID to parse the RTP SDES header extension for MID of media flow.

12. The method of claim 9, wherein the step of obtaining comprises receiving the packet filters as part of a PDU session establishment procedure and / or PDU session modification procedure.

13. The method of any one of claim 1 to 4 wherein the packet filters are included in Packet Data Rules (PDR).

14. A network node implementing a user plane function configured to perform the method of any of claim 9-13.

15. A network node implementing a user plane function comprising one or more processors and memory comprising instructions which when executed by the one or more processors enable the wireless device to perform the method of any one of claim 9-13.

16. A computer readable memory comprising instructions which when executed by one or more processors of a network node configures the network node to perform any one of the claim 9-13.70

Images