WO2025087703A1

WO2025087703A1 - Update of access traffic steering, switching, splitting rules with user equipment provided information

Info

Publication number: WO2025087703A1
Application number: PCT/EP2024/078619
Authority: WO
Inventors: Ville Petteri PÖYHÖNEN; Janne Einari TUONONEN; Rainer Liebhart
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2023-10-26
Filing date: 2024-10-11
Publication date: 2025-05-01
Anticipated expiration: 2026-04-26
Also published as: GB202316377D0; GB2634935A

Abstract

Updating access traffic steering, switching, splitting rules with user equipment provided information is provided. A method for updating access traffic steering, switching, splitting rules may include requesting a user equipment to provide information related to access traffic steering, switching, splitting (ATSSS). The method may include generating or updating ATSSS rules for multi-access packet data unit sessions for the user equipment based on the information provided by the user equipment and, alternatively or additionally, based on policy rules received from a policy control function (PCF), and generating or updating N4 rules for multi-access packet data unit sessions for a user plane function based on the information provided by the user equipment and, alternatively or additionally, based on the policy rules received from the PCC. The method may further include transmitting, to the user equipment, the generated ATSSS rules and transmitting, to the user plane function, the generated N4 rules.

Description

TITLE:

UPDATE OF ACCESS TRAFFIC STEERING, SWITCHING, SPLITTING RULES WITH USER EQUIPMENT PROVIDED INFORMATION

TECHNICAL FIELD:

[0001] Some example embodiments may generally relate to mobile or wireless telecommunication systems and technology, such as Long Term Evolution (LTE) or fifth generation (5G) new radio (NR) access technology, or 5G beyond, or sixth generation (6G) access technology or other communications systems. For example, certain example embodiments may relate to updating access traffic steering, switching, splitting rules with user equipment provided information.

BACKGROUND:

[0002] Examples of mobile or wireless telecommunication systems and technology may include the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE- Advanced (LTE-A), MulteFire, LTE -A Pro, fifth generation (5G) radio access technology or new radio (NR) access technology and/or sixth generation (6G) radio access technology. Fifth generation (5G) and sixth generation (6G) wireless systems refer to the next generation (NG) of radio systems and network architecture. 5G and 6G network technology is mostly based on new radio (NR) technology, but the 5G/6G (or NG) network can also build on E-UTRAN radio. It is estimated that NR may provide bitrates on the order of 10-20 Gbit/s or higher, and may support at least enhanced mobile broadband (eMBB) and ultra-reliable low- latency communication (URLLC) as well as massive machine-type communication (mMTC). NR is expected to deliver extreme broadband and ultra-robust, low-latency connectivity and massive networking to support the Internet of Things (IoT). SUMMARY:

[0003] Various example embodiments may provide an apparatus comprising means for requesting a user equipment to provide information related to access traffic steering, switching, splitting (ATSSS). The apparatus may also comprise means for generating or updating ATSSS rules for multi-access packet data unit sessions for the user equipment based on the information provided by the user equipment and, alternatively or additionally, based on policy rules received from a policy control function (PCF), and means for generating or updating N4 rules for multi-access packet data unit sessions for a user plane function based on the information provided by the user equipment and, alternatively or additionally, based on the policy rules received from the policy control function (PCF). The apparatus may further comprise means for transmitting, to the user equipment, the generated ATSSS rules and transmit, to the user plane function, the generated N4 rules.

[0004] Certain example embodiments may provide an apparatus comprising means for providing, to a session management function, information related to access traffic steering, switching, splitting (ATSSS). The apparatus may also comprise means for receiving, from the session management function, updated N4 rules related to ATSSS, and/or means for updating one or more N4 rules containing multi-access rules related to ATSSS.

[0005] Some example embodiments may provide an apparatus comprising means for determining one or more traffic descriptors and one or more access traffic steering, switching, splitting (ATSSS) rule identifiers related to ATSSS data, and means for providing the one or more traffic descriptors and the one or more ATSSS rule identifiers to a session management function via control plane messaging (e.g., one or more control plane messages) or to a user plane function via user plane messaging (e.g., one or more user plane messages).

[0006] Various example embodiments may provide an apparatus comprising means for receiving, from a session management function, information related to access traffic steering, switching, splitting (ATSSS), which was received from the session management function from a user equipment. The apparatus may also comprise means for updating one or more policy and charging control (PCC) rules based on the information related to ATSSS, and means for providing the updated one or more PCC rules to the session management function.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0007] For proper understanding of example embodiments, reference should be made to the accompanying drawings, as follows:

[0008] FIG. 1 illustrates a signal diagram for one or more procedures, according to various example embodiments;

[0009] FIG. 2 illustrates another signal diagram for one or more procedures, according to some example embodiments;

[0010] FIG. 3 illustrates a further signal diagram for one or more procedures, according to certain example embodiments;

[0011] FIG. 4 illustrates an additional signal diagram for one or more procedures, according to various example embodiments;

[0012] FIG. 5 illustrates an even further signal diagram for one or more procedures, according to some example embodiments;

[0013] FIG. 6 illustrates an example flow diagram of a method, according to certain example embodiments;

[0014] FIG. 7 illustrates an additional example flow diagram of a method, according to certain example embodiments;

[0015] FIG. 8 illustrates a further example flow diagram of a method, according to certain example embodiments;

[0016] FIG. 9 illustrates an even further example flow diagram of a method, according to certain example embodiments; and [0017] FIG. 10 illustrates a set of apparatuses, according to various example embodiments.

DETAILED DESCRIPTION:

[0018] It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. The following is a detailed description of some example embodiments of systems, methods, apparatuses, and non-transitory computer program products for updating access traffic steering, switching, splitting (ATSSS)/N4 rules with user equipment (UE) provided information. Although the devices discussed below and shown in the figures refer to 5G/6G or Next Generation NodeB (gNB) devices and user equipment (UE) devices, this disclosure is not limited to only gNBs and UEs.

[0019] It may be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Different reference designations from multiple figures may be used out of sequence in the description, to refer to a same element to illustrate their features or functions. If desired, the different functions or procedures discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions or procedures may be optional or may be combined. As such, the following description should be considered as illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof.

[0020] In 5G/6G technology, access traffic steering, switching, splitting (ATSSS) may be defined by 3^rd Generation Partnership Project (3GPP) specifications. ATSSS provides the capability to steer, switch, split, duplicate traffic between different accesses. For that purpose, one or more steering modes (SMs) for given service data flows (SDF) are associated with a multiaccess packet data unit (MA-PDU) sessions that is established between a UE and a user plane function (UPF). A control plane function, such as a session management function (SMF), may be used to distribute ATSSS rules to the UE and its corresponding N4 rules to the UPF. The SMF may consider policy and charging control (PCC) rules provided by the PCF when creating ATSSS and N4 rules. ATSSS rules are applied by the UE to uplink (UL) traffic and N4 rules by the UPF to downlink (DL) traffic. Multi-access rules (MAR) are part of the N4 rules. An N4 rule may include a MAR ID and the MAR may refer to the N4 rule via an N4 session ID. N4 rules may be a set of rules provided to the UPF, which include MARs and forwarding action rules (FAR) determining how to forward a certain packet. N4 refers to an interface between the SMF and the UPF using packet forwarding control protocol (PFCP) protocol.

[0021] The UE may manage the ATSSS rules, which contain traffic steering information for access traffic (e.g., 5-tuple internet protocol (IP) flow) and may process uplink traffic steering. The SMF in the control plane may distribute the ATSSS rules to the UE based on the policy rules delivered by the PCF and may send the N4 rule including the downlink traffic steering information to the UPF. In the network user plane, the UPF may enforce the N4 rule to perform traffic steering.

[0022] Each MA-PDU may have a 3GPP access and a non-3GPP access. For example, ATSSS may support five (5) SMs, such as active- standby, loadbalancing, priority-based, smallest delay, and redundant. Each SM may handle the multiple access differently. The SDF traffic may be distributed according to rules and/or policies defined for UL and downlink (DL). The used access can be switched dynamically based on the access conditions and the current rules and policies.

[0023] One issue with existing 3 GPP technologies may be that during creation or modification of ATSSS and/or N4 rules, there may not be a procedure for the UE to provide UE- specific preferences, such as, for example, which application traffic or UE-generated traffic should use a given MA PDU session or requires a certain treatment. Existing 3GPP technologies may assume that traffic characteristics or traffic descriptor-related information are configured by the operator in policy and charging control (PCC) rules, which may be used by the SMF to generate ATSSS and N4 rules for UE and UPF, respectively. The procedures of existing 3 GPP technologies were intended to improve and boost the user plane for SDFs of the UE, it may be advantageous to improve the flexibility and usability to meet requirements and/or preferences of the UE. [0024] For example, during procedures for creating an ATSSS/N4 rule, operator or UE originated information may be used to identify end-to-end services, which may be mapped to SDFs, that need special handling from ATSSS. It has become more common for services used by UEs to not be managed or provided by the mobile network operators, which may make it impractical for the mobile network operators to be aware of service identities and traffic characteristics in every instance. Even if a mobile network operator has an agreement with service providers for the service providers to provide information about their service (e.g., server addresses, port numbers), this my potentially be inefficient, inflexible and may not scale for use in a wide variety of applications.

[0025] Various example embodiments may provide technological advantages to provide increased flexibility and useability of ATSSS/N4 capabilities in MA-PDU sessions. Certain example embodiments may provide for the UE and the network to work together in providing or negotiating the information that the UE may provide for creating or updating ATSSS/N4 rules.

[0026] During a procedure for establishing an MA-PDU session, some example embodiments may provide that a UE, which is already known by the network, may inform the network about its ATSSS capabilities as part of a PDU session establishment request. The ATSSS capabilities may indicate the steering functionalities (SFs) and the steering modes (SMs) supported by the UE. The network may use the ATSSS capabilities information to create ATSSS/N4 rules for the UE and UPF. The network may include an SMF and/or PCF.

[0027] Certain example embodiments may provide a configuration in which the UE provides ATSSS-related information via the control plane. The UE may, for example, provide to the network information about the traffic that is using the MA-PDU session. This traffic information may comprise 5-tuples, such as a source IP address, a source port, a destination IP address, a destination port, and a transport protocol. However, in certain scenarios, session flows may not be able to be uniquely identified by the 5-tuples when using quick user datagram (UDP) internet connections (QUIC) as a transport protocol. In these scenarios, the UE may provide to the network information similar to 5-tuples, such as QUIC connection ID(s), App ID(s), IP, transmission control protocol (TCP)/UDP or Ethernet header information allowing the UE and UPF to identify certain traffic via a traffic descriptor, which is part of the ATSSS/N4 rules. This information may then be used by the network (e.g., SMF) to generate new or updated ATSSS/N4 rules. Alternatively or additionally, other control plane signaling between UE and network may be used to provide the traffic information to the network, such as, for example, in a new non-access stratum (NAS) message. Certain example embodiments may allow the UE and the network to negotiate whether to provide, and which information the UE is allowed to provide, via the control plane.

[0028] Various example embodiments may provide a configuration in which the UE provides ATSSS-related information via the user plane, instead of the control plane. The UE and network may use performance measurement function (PMF) protocol messaging or any other similar message between the UE and the network on the user plane. These messages may enable (or otherwise facilitate) the UE to update ATSSS related information, such as traffic descriptor parameters (e.g., 5-tuples, App ID, IP/Ethemet header information, and the like). Various rules or specific parts, such as traffic descriptors, may be dynamically adjusted by the UE using PMF protocol messaging (e.g., one or more PMF messages) or the like. Adjusting or updating the rules or parts thereof may need to be aligned between UE and UPF. The UE may provide ATSSS rule ID(s) allowing the SMF of the network to update one or multiple ATSSS rules identified by the rule ID(s). The ATSSS rule ID may be a unique identifier to identify the rule that is configured on the UE that is requested to be deleted or updated/adjusted. If the UE updates or adjusts traffic descriptors via the user plane (e.g., using PMF protocol messaging), the UPF may inform the SMF about the request to update or adjust the traffic descriptors. This may allow the SMF with the help of the PCF to update or adjust ATSSS/N4 rules accordingly. Alternatively, the UE and UPF may also update the rules autonomously without informing the SMF.

[0029] In some example embodiments, the UPF may update the N4 rules and/or multi-access (MA) rules, for a given MA PDU session without informing the SMF if, for example, only one rule is configured for the MA- PDU session. Certain example embodiments may provide that the SMF updates the traffic descriptors in all existing rules with the information provided by the UE. Various example embodiments may provide that the network permits the UE to update only certain specific ATSSS and/or N4 rules that are determined via a special indicator. These rules may have lower precedence than other rules provided by the mobile network operator.

[0030] The network (e.g., SMF) may either accept or reject the request to update or adjust the ATSSS/N4 rules, which may be indicated to the UE in the PMF protocol response messaging (e.g., one or more PMF protocol response messages). The update request may include additional correlation information based on which the UPF can determine the ATSSS/N4 rules that need to be updated/adjusted. Certain example embodiments may allow the UE and the network to negotiate whether to provide, and which information the UE is allowed to provide, via the control plane.

[0031] In certain example embodiments, the traffic descriptor may provide sufficient information to identify a data packet. For example, the data packet may match the traffic descriptor and therefore may require specified handling of the packet. For example, the UDP-based transport protocol QUIC may include different data flows per connection using the same 5 -tuple where each connection is identified by a connection ID (CID).

[0032] Various example embodiment may provide that the traffic descriptors include, for example, a UL traffic descriptor and/or a DL traffic descriptor. The UL traffic descriptor may allow the UE to identify certain UL traffic it is sending to the network to apply specific rules for the UL traffic. The UL traffic descriptor may be an IP 5-tuple comprised of, for example, a source IP address, a source port number, a destination IP address, a destination port number, and a transport protocol (e.g., TCP or UDP). Alternatively, the UL traffic descriptor may be a fully qualified domain name (FQDN) used by an application of the UE or an application ID identifying the specific application used by the UE. The DL traffic descriptor may allow the network (e.g., UPF) to identify certain DL traffic it is sending to the UE to apply specific rules for the DL traffic. The DL traffic descriptor may be an IP 5-tuple comprised of, for example, a source IP address, a source port number, a destination IP address, a destination port number, and a transport protocol (e.g., TCP or UDP). Alternatively, the DL traffic descriptor may contain information related to a fully qualified domain name (FQDN) used by an application of the UE or an application ID identifying the specific application used by the UE.

[0033] The UE may be triggered to provide its ATSSS capabilities during establishment of the MA-PDU session by, for example, a launching/ executing new application that has characteristics requiring certain reliability, delay, and/or throughput. These characteristics of the application together with the information how to identify the application (5-tuples, App ID, IP/Ethemet header information, and the like) can be provided via an application programming interface (API) from the application to the UE. Alternatively, the UE may be configured with the characteristics of the application, which uses the App ID in order for the UE to determine that certain characteristics of the application are necessary. The triggers for the UE may be based on the application the UE is executing, such that the network may be able to determine in ATSSS rules that traffic based on certain FQDN or AppID may be sent via an MA-PDU session. The UE may know the nature of this traffic and may provide this information together with the 5-tuple(s) or connection ID(s) used to the SMF or UPF once the application has started.

[0034] Some example embodiments provide that the UE may use artificial intelligence (AI)/machine learning (ML), heuristics, and/or feedback from the user, such as a quality of experience indication, to determine which kind of ATSSS rules to apply. Enhanced throughput may be achieved by splitting traffic over both available accesses (3GPP and non-3GPP). A lowered delay may be provided by using the available access providing the lowest delay and an increased reliability may be provided by duplicating packets on each of the available accesses (3 GPP and non-3GPP). Certain example embodiments provide that the UE may identify the application and its characteristics, send the App ID and the application’s characteristics to the network, which accordingly updates or creates one or more ATSSS rules and sends the ATSSS rules to the UE.

[0035] FIG. 1 illustrates a signal diagram for one or more procedures, according to various example embodiments. The one or more procedures may be performed by a configuration of, for example, a UE 101, an SMF 102, and a UPF 103 during establishment of an MA-PDU session or during an update of an existing MA-PDU session. At 110, the UE 101, SMF 102, and UPF 103 may establish or update of the MA-PDU session during which the SMF 102 (or alternatively a UPF) requests the UE 101 to provide ATSSS related information for a set of service flows based on local policies or a local configuration.

[0036] The ATSSS related information may include ATSSS capabilities and traffic descriptors. The ATSSS related information may comprise 5-tuples, App ID(s), IP/Ethemet header information, connection (IDs) or other related information the UE is allowed to send. The other related information may comprise certain parameters in IP, TCP/UDP or Ethernet frame headers, or an identifier provided by the application to the UE or by an application server to the network (e.g., PCF, SMF 102, UPF 103). The request for ATSSS related information may be provided to the UE 101 that has indicated support for a feature desired by the application, such as at registration or PDU session establishment.

[0037] At 120, the SMF 102 may evaluate the ATSSS capabilities in the ATSS related information. At 130, the SMF 102 may generate new and/or updated ATSSS and/or N4 rules. At 140, the SMF 102 may provide the new and/or updated ATSSS and/or N4 rules to the UE 101 and the UPF 103.

[0038] FIG. 2 illustrates a signal diagram for one or more procedures using a control plane message between a UE 201 and an SMF 202, according to various example embodiments. The one or more procedures may be performed by a configuration of, for example, the UE 201, the SMF 202, a UPF 203, and a PCF 204. At 210, the UE 201 may determine a new UL traffic descriptor and/or a new DL traffic descriptor, in addition to ATSSS rule ID(s) associated with ATSSS rule(s) to which the UL traffic descriptor and the DL traffic descriptor may be respectively added (where applicable). At 220, the UE 201 may provide the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to the SMF 202. At 230, the SMF 202 may forward the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to the PCF 204.

[0039] At 240, the PCF 204 may be triggered by the UL traffic descriptor and/or the DL traffic descriptor in addition to the ATSSS rule ID(s) to generate new or updated PCC rule(s) and provide the new or updated PCC rule(s) to the SMF 202. The PCC rule(s) may indicate that the rules, or parts of the rules, may be dynamically modified. Alternatively, all ATSSS/N4 rules, or parts of ATSSS/N4 rules, may be dynamically modified if the UE 201 and the UPF 203 perform the modification in a synchronous manner, such that the modifications may be agreed upon. At 250, the SMF 202 may generate new and/or updated ATSSS and/or N4 rule(s) based on the PCC rule(s) and provide the new and/or updated ATSSS and/or N4 rule(s) to the UE 201 and the UPF 203.

[0040] FIG. 3 illustrates a signal diagram for one or more procedures using a control plane message between a UE 301 and a UPF 302, according to various example embodiments. The one or more procedures may be performed by a configuration of, for example, the UE 301 , the UPF 302, and an SMF 303. At 310, the UE 301 may determine a new UL traffic descriptor and/or a new DL traffic descriptor, in addition to ATSSS rule ID(s) associated with ATSSS rule(s) for which the UL traffic descriptor and the DL traffic descriptor may be respectively applied (where applicable). At 320, the UE 301 may use PMF protocol messaging (e.g., one or more PMF protocol messages) to provide the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to the UPF 302. At 330, the UPF 302 may forward the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to the SMF 303.

[0041] At 340, the SMF 303 may evaluate the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) and update ATSSS and/or N4 rule(s) and/or multi-access rules (MAR). At 350, the SMF 303 may provide the updated N4 rule(s) to the UPF 302. At 360, the SMF 303 may send updated ATSSS rule(s) to the UE 301.

[0042] FIG. 4 illustrates a signal diagram for one or more procedures using a configuration of a UE 401 and a UPF 402, according to various example embodiments. At 410, the UE 401 may determine a new UL traffic descriptor and/or a new DL traffic descriptor, in addition to ATSSS rule ID(s) associated with ATSSS rule(s) for which the UL traffic descriptor and the DL traffic descriptor may be respectively applied (where applicable). At 420, the UE 401 may use PMF protocol messaging (e.g., one or more PMF protocol messages) to provide the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to the UPF 402. At 430, the UPF 402 may evaluate the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to determine updated ATSSS/N4 rule(s) and/or MAR. [0043] At 440, the UPF 402 may respond to the UE 401 by providing an acknowledgement (ACK) or non-acknowledgment (NACK). At 450, the UE 401 may update ATSSS rule(s) accordingly if the UPF 402 responded with ACK, which may indicate that a request to update in the PMF protocol messaging was accepted and processed by the UPF 402.

[0044] FIG. 5 illustrates a signal diagram for one or more procedures using a control plane message between a UE 501, a UPF 502, and an SMF 503, according to various example embodiments. The one or more procedures may be performed by a configuration of, for example, the UE 501, the UPF 502, the SMF 503, and a PCF 504. At 510, the UE 501 may determine a new UL traffic descriptor and/or a DL traffic descriptor, in addition to ATSSS rule ID(s) associated with ATSSS rule(s) to which the UL traffic descriptor and the DL traffic descriptor may be respectively added (where applicable). At 520, the UE 501 may provide the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) within PMF protocol messaging (e.g., one or more PMF protocol messages) to the UPF 502. At 530, the UPF 502 may forward the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to the SMF 503. At 540, the SMF 503 may forward the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to the PCF 504.

[0045] At 550, the PCF 504 may be triggered by the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to generate new or updated PCC rule(s) and provide the new or updated PCC rule(s) to the SMF 503. As an alternative implementation, the SMF 503 may be triggered by the UL traffic descriptor and/or the DL traffic descriptor, in addition to the ATSSS rule ID(s) to generate new or updated ATSSS/N4 rule(s) and provide the new or updated N4 rule(s) to the UPF 502 and the new or updated ATSSS rule(s) to the UE 501. Alternatively, all ATSSS/N4 rules, or parts of ATSSS/N4 rules, may be dynamically modified if the UE 501 and the UPF 503 perform the modification in a synchronous manner, such that the modifications may be agreed upon.

[0046] At 560, the SMF 502 may generate new and/or updated ATSSS and/or N4 rule(s) including MAR based on the PCC rule(s) and provide the new and/or updated ATSSS and/or N4 rule(s) to the UE 501 and the UPF 502. In the alternative implementation, the UPF 502 may generate new and/or updated ATSSS and/or N4 rule(s) including MAR based on the PCC rule(s).

[0047] Various example embodiments may provide technological advantages to provide increased flexibility and useability of ATSSS/N4 capabilities in MA-PDU sessions. Certain example embodiments may provide for the UE and the network to work together in providing or negotiating the information that the UE may provide for creating or updating ATSSS/N4 rules.

[0048] FIG. 6 illustrates an example flow diagram of a method, according to certain example embodiments. In an example embodiment, the method of FIG. 6 may be performed by a network element, or a group of multiple network elements in a 3GPP system, such as LTE or 5G-NR. For instance, in an example embodiment, the method of FIG. 6 may be performed by network entity or function, such as an SMF, similar to apparatus 1010 illustrated in FIG 10.

[0049] According to various example embodiments, the method of FIG. 6 may include, at 610, requesting a UE to provide information related to ATSSS, and at 620, generating or updating ATSSS rules for MA-PDU sessions for the UE based on the information provided by the UE and, alternatively or additionally, based on policy rules received from a PCF. At 630, the method may also include generating or updating N4 rules for MA-PDU sessions for a UPF based on the information provided by the UE and, alternatively or additionally, based on the policy rules received from the PCF. At 640, the method may further include transmitting, to the UE, the generated ATSSS rules, and at 650, transmitting, to the UPF, the generated N4 rules.

[0050] Certain example embodiments may provide that the information related to ATSSS is provided for a set of service data flows associated with multiaccess packet data unit sessions. The information related to ATSSS may comprise one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier. Various example embodiments may provide that the method includes forwarding the information related to ATSSS, which was received from the UE, to a PCF. The method may also include receiving the information related to ATSSS from a UPF, to which the information related to ATSSS is forwarded from the UE.

[0051] Some example embodiments may also provide that the method may include generating ATSSS and N4 rules based on the information related to ATSSS received from the UPF and, alternatively or additionally, based on policy rules received from the PCC, and transmitting the generated N4 rules to the UPF and the generated ATSSS rules to the UE. The N4 rules may comprise multi-access rules that may contain an indication that the N4 rules are subject to changes triggered by the UE provided information.

[0052] FIG. 7 illustrates an example flow diagram of a method, according to certain example embodiments. In an example embodiment, the method of FIG.

7 may be performed by a network element, or a group of multiple network elements in a 3GPP system, such as LTE or 5G-NR. For instance, in an example embodiment, the method of FIG. 7 may be performed by network entity or function, such as a UPF, similar to apparatus 1020 illustrated in FIG. 10.

[0053] According to various example embodiments, the method of FIG. 7 may include, at 710, providing, to an SMF, information related to ATSSS, and at 720, receiving, from the SMF, updated N4 rules related to ATSSS. At 730, the method may further include updating one or more N4 rules containing multi-access rules related to ATSSS.

[0054] Some example embodiments may provide that the information related to ATSSS is provided for a set of service data flows associated with a MA- PDU sessions. Certain example embodiments may also provide that the information related to ATSSS may comprise one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier. Various example embodiments may provide that the method further includes receiving, from a UE, a PMF message including the information related to ATSSS.

[0055] FIG. 8 illustrates an example flow diagram of a method, according to certain example embodiments. In an example embodiment, the method of FIG.

8 may be performed by a network element, or a group of multiple network elements in a 3GPP system, such as LTE or 5G-NR. For instance, in an example embodiment, the method of FIG. 8 may be performed by a user device, mobile device, etc., such as a UE, similar to apparatus 1030 illustrated in FIG. 10.

[0056] According to various example embodiments, the method of FIG. 8 may include, at 810, determining one or more traffic descriptors and one or more ATSSS rule identifiers related to ATSSS data. At 820, the method may also include providing the one or more traffic descriptors and the one or more ATSSS rule identifiers to an SMF via control plane messaging (e.g., one or more control plane messages) or to a UPF via user plane messaging (e.g., one or more user plane messages).

[0057] Certain example embodiments may provide that the control plane messaging (e.g., one or more control plane messages) may be non-access stratum (NAS) messaging (e.g., one or more NAS messages) and the user plane messaging (e.g., one or more user plane messages) may be performance management function (PMF) protocol messaging (e.g., one or more PMF protocol messages). The one or more traffic descriptors and the one or more ATSSS rule identifiers may be provided to allow identification of a set of service data flows associated with the MA-PDU session. Some example embodiments may provide that the one or more traffic descriptors may comprise one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier. Various example embodiments may provide that the method includes receiving one or more updated ATSSS rules and updating the one or more ATSSS rules. The method may further include receiving an acknowledgement or a non-acknowledgement from the UPF and updating the one or more rules for ATSSS when the acknowledgement is received.

[0058] FIG. 9 illustrates an example flow diagram of a method, according to certain example embodiments. In an example embodiment, the method of FIG. 9 may be performed by a network element, or a group of multiple network elements in a 3GPP system, such as LTE or 5G-NR. For instance, in an example embodiment, the method of FIG. 9 may be performed by network entity or function, such as a PCF, similar to apparatus 1040 illustrated in FIG. 10.

[0059] According to various example embodiments, the method of FIG. 9 may include, at 910, receiving, from an SMF, information related to ATSSS, which was received by the SMF from a UE, and at 920, updating one or more PCC rules based on the information related to ATSSS. At 930, the method may also include providing the updated one or more PCC rules to the SMF.

[0060] Some example embodiments may provide that the information related to ATSSS is provided for a set of service data flows for an MA-PDU session. The information related to ATSSS may comprise one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier.

[0061] FIG. 10 illustrates apparatuses 1010, 1020, 1030, and 1040 according to various example embodiments. In the various example embodiments, apparatus 1010 may be configured to operate as a network element or a group of multiple network elements, such as an SMF. Apparatus 1010 may, for example, be configured to perform one or more functions of an SMF, such as SMFs 102/202/303/503 according to various example embodiments as discussed above. It should be noted that one of ordinary skill in the art would understand that apparatus 1010 may include components or features not shown in FIG. 10. Further, the apparatus 1020 may be configured to operate as a network element or a group of multiple network elements, such as a UPF. Apparatus 1020 may, for example, be configured to perform one or more functions of a UPF, such as UPFs 103/203/302/402/502 according to various example embodiments as discussed above. It should be noted that one of ordinary skill in the art would understand that apparatus 1020 may include components or features not shown in FIG. 10. In addition, an apparatus 1030 may be implemented as a user device, mobile device, etc., such as a UE. For example, UEs 101/201/301/401/501 may be examples of apparatus 1030 according to various example embodiments as discussed above. It should be noted that one of ordinary skill in the art would understand that apparatus 1030 may include components or features not shown in FIG. 10. Further, the apparatus 1040 may be configured to operate as a network element or a group of multiple network elements, such as a PCF. Apparatus 1040, for instance, may be configured to perform one or more functions of a PCF, such as PCFs 204/504 according to various example embodiments as discussed above. It should be noted that one of ordinary skill in the art would understand that apparatus 1040 may include components or features not shown in FIG. 10.

[0062] According to various example embodiments, the apparatuses 1010, 1020, 1030, and/or 1040 may include one or more processors, one or more computer-readable storage medium (for example, memory, storage, or the like), one or more radio access components (for example, a modem, a transceiver, or the like), and/or a user interface. In some example embodiments, apparatuses 1010, 1020, 1030, and/or 1040 may be configured to operate using one or more radio access technologies, such as GSM, LTE, LTE-A, NR, 5G, WLAN, WiFi, NB-IoT, Bluetooth, NFC, MulteFire, and/or any other radio access technologies.

[0063] As illustrated in the example of FIG. 10, apparatuses 1010, 1020, 1030, and/or 1040 may include or be coupled to processors 1012, 1022, 1032, and 1042, respectively, for processing information and executing instructions or operations. Processors 1012, 1022, 1032, and 1042 may be any type of general or specific purpose processor. In fact, processors 1012, 1022, 1032, and 1042 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field- programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and processors based on a multi-core processor architecture, as examples. While a single processor 1012 (1022, 1032, and 1042) for each of apparatuses 1010, 1020, 1030, and/or 1040 is shown in FIG. 10, multiple processors may be utilized according to other example embodiments. For example, it should be understood that, in certain example embodiments, apparatuses 1010, 1020, 1030, and/or 1040 may include two or more processors that may form a multiprocessor system (for example, in this case processors 1012, 1022, 1032, and 1042 may represent a multiprocessor) that may support multiprocessing. According to certain example embodiments, the multiprocessor system may be tightly coupled or loosely coupled to, for example, form a computer cluster.

[0064] Processors 1012, 1022, 1032, and 1042 may perform functions associated with the operation of apparatuses 1010, 1020, 1030, and/or 1040, respectively, including, as some examples, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatuses 1010, 1020, 1030, and/or 1040, including processes illustrated in FIGs. 1-9.

[0065] Apparatuses 1010, 1020, 1030, and/or 1040 may further include or be coupled to memory 1014, 1024, 1034 and/or 1044 (internal or external), respectively, which may be coupled to processors 1012, 1022, 1032, and 1042, respectively, for storing information and instructions that may be executed by processors 1012, 1022, 1032, and 1042. Memory 1014 (memory 1024, 1034, and 1042) may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor-based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and/or removable memory. For example, memory 1014 (memory 1024, 1034, and 1042) can be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, hard disk drive (HDD), or any other type of non-transitory machine or computer readable media. The instructions stored in memory 1014 (memory 1024, 1034, and 1042) may include program instructions or computer program code that, when executed by processors 1012, 1022, 1032, and 1042, enable (or otherwise facilitate) the apparatuses 1010, 1020, 1030, and/or 1040 to perform tasks as described herein.

[0066] In certain example embodiments, apparatuses 1010, 1020, 1030, and/or 1040 may further include or be coupled to (internal or external) a drive or port that is configured to accept and read an external computer readable storage medium, such as an optical disc, USB drive, flash drive, or any other storage medium. For example, the external computer readable storage medium may store a computer program or software for execution by processors 1012, 1022, 1032, and 1042 and/or apparatuses 1010, 1020, 1030, and/or 1040 to perform any of the methods illustrated in FIGs. 1-9.

[0067] In some example embodiments, apparatuses 1010, 1020, 1030, and/or 1040 may also include or be coupled to one or more antennas 1015, 1025, 1035, and 1045, respectively, for receiving a downlink signal and for transmitting via an uplink from apparatuses 1010, 1020, 1030, and/or 1040. Apparatuses 1010, 1020, 1030, and/or 1040 may further include transceivers 1016, 1026, 1036, and 1046, respectively, configured to transmit and receive information. The transceivers 1016, 1026, 1036, and 1046 may also include a radio interface (for example, a modem) respectively coupled to the antennas 1015, 1025, 1035, and 1045. The radio interface may correspond to a plurality of radio access technologies including one or more of GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, Bluetooth, BT-LE, NFC, RFID, UWB, or the like. The radio interface may include other components, such as filters, converters (for example, digital-to-analog converters or the like), symbol demappers, signal shaping components, an Inverse Fast Fourier Transform (IFFT) module, or the like, to process symbols, such as OFDMA symbols, carried by a downlink or an uplink.

[0068] For instance, transceivers 1016, 1026, 1036, and 1046 may be respectively configured to modulate information on to a carrier waveform for transmission by the antenna(s) 1015, 1025, 1035, and 1045, and demodulate information received via the antenna(s) 1015, 1025, 1035, and 1045 for further processing by other elements of apparatuses 1010, 1020, 1030, and/or 1040. In other example embodiments, transceivers 1016, 1026, 1036, and 1046 may be capable of transmitting and receiving signals or data directly. Alternatively or additionally, in some example embodiments, apparatuses 1010, 1020, 1030, and/or 1040 may include an input and/or output device (I/O device). In certain example embodiments, apparatuses 1010, 1020, 1030, and/or 1040 may further include a user interface, such as a graphical user interface or touchscreen.

[0069] In certain example embodiments, memory 1014, memory 1024, memory 1034, and memory 1044 store software modules that provide functionality when executed by processors 1012, 1022, 1032, and 1042, respectively. The modules may include, for example, an operating system that provides operating system functionality for apparatuses 1010, 1020, 1030, and/or 1040. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatuses 1010, 1020, 1030, and/or 1040. The components of apparatuses 1010, 1020, 1030, and/or 1040 may be implemented in hardware, or as any suitable combination of hardware and software. According to certain example embodiments, apparatus 1010 may optionally be configured to communicate with apparatus 1020, 1030, and/or 1040 via a wireless or wired communications links 1050, 1060, 1070 and/or 1080 according to any radio access technology, such as NR.

[0070] According to certain example embodiments, processors 1012, 1022, 1032, and 1042, and memory 1014, 1024, 1034, and 1044 may be included in or may form a part of processing circuitry or control circuitry. In addition, in some example embodiments, transceivers 1016, 1026, 1036, and 1046 may be included in or may form a part of transceiving circuitry.

[0071] For instance, in certain example embodiments, the apparatus 1010 may be controlled by the memory 1014 and the processor 1012 to request a UE to provide information related to ATSSS and generate or update ATSSS rules for MA-PDU sessions for the UE based on the information provided by the UE and, alternatively or additionally, based on policy rules received from a PCF. The apparatus 1010 may also be controlled to generate or update N4 rules for MA-PDU sessions for a UPF based on the information provided by the UE and, alternatively or additionally, based on the policy rules received from the PCF, transmit, to the UE, the generated ATSSS rules, and transmit, to the UPF, the generated N4 rules.

[0072] In various example embodiments, the apparatus 1020 may be controlled by the memory 1024 and the processor 1022 to provide, to an SMF, information related to ATSSS, receive, from the SMF, updated N4 rules related to ATSSS, and/or update one or more N4 rules containing multi-access rules related to ATSSS.

[0073] In various example embodiments, the apparatus 1030 may be controlled by the memory 1034 and the processor 1032 to determine one or more traffic descriptors and one or more ATSSS rule identifiers related to ATSSS data and provide the one or more traffic descriptors and the one or more ATSSS rule identifiers to an SMF via control plane messaging (e.g., one or more control plane messages) or to a UPF via user plane messaging (e.g., one or more user plane messages).

[0074] In various example embodiments, the apparatus 1040 may be controlled by the memory 1044 and the processor 1042 to receive, from an SMF, information related to ATSSS, which was received from the SMF from a UE, update one or more PCC rules based on the information related to ATSSS, and provide the updated one or more PCC rules to the SMF.

[0075] In some example embodiments, an apparatus (e.g., apparatus 1010, 1020, 1030, and/or 1040) may include means for performing a method, a process, or any of the variants discussed herein. Examples of the means may include one or more processors, memory, controllers, transmitters, receivers, and/or computer program code for causing the performance of the operations. [0076] Various example embodiments may be directed to an apparatus, such as apparatus 1010, that includes means for requesting a UE to provide information related to ATSSS and generating or updating ATSSS rules for MA-PDU sessions for the UE based on the information provided by the UE and, alternatively or additionally, based on policy rules received from a PCF. The apparatus 1010 may also include means for generating or updating N4 rules for MA-PDU sessions for a UPF based on the information provided by the UE and, alternatively or additionally, based on the policy rules received from the PCF, transmitting, to the UE, the generated ATSSS rules, and transmitting, to the UPF, the generated N4 rules.

[0077] Various example embodiments may be directed to an apparatus, such as apparatus 1020, that includes means for providing, to an SMF, information related to ATSSS, receiving, from the SMF, updated N4 rules related to ATSSS, and/or updating one or more N4 rules containing multi-access rules related to ATSSS.

[0078] Various example embodiments may be directed to an apparatus, such as apparatus 1030, that includes means for determining one or more traffic descriptors and one or more ATSSS rule identifiers related to ATSSS data, and providing the one or more traffic descriptors and the one or more ATSSS rule identifiers to an SMF via control plane messaging (e.g., one or more control plane messages) or to a UPF via user plane messaging (e.g., one or more user plane messages). [0079] Various example embodiments may be directed to an apparatus, such as apparatus 1040, that includes means for receiving, from an SMF, information related to ATSSS, which was received from the SMF from a UE, updating one or more PCC rules based on the information related to ATSSS, and providing the updated one or more PCC rules to the SMF.

[0080] As used herein, the term “circuitry” may refer to hardware-only circuitry implementations (for example, analog and/or digital circuitry), combinations of hardware circuits and software, combinations of analog and/or digital hardware circuits with software/firmware, any portions of hardware processor(s) with software, including digital signal processors, that work together to cause an apparatus (for example, apparatus 1010, 1020, 1030, and/or 1040) to perform various functions, and/or hardware circuit(s) and/or processor(s), or portions thereof, that use software for operation but where the software may not be present when it is not needed for operation. As a further example, as used herein, the term “circuitry” may also cover an implementation of merely a hardware circuit or processor or multiple processors, or portion of a hardware circuit or processor, and the accompanying software and/or firmware. The term circuitry may also cover, for example, a baseband integrated circuit in a server, cellular network node or device, or other computing or network device.

[0081] A computer program product may include one or more computerexecutable components which, when the program is run, are configured to carry out some example embodiments. The one or more computer-executable components may be at least one software code or portions of it. Modifications and configurations required for implementing functionality of certain example embodiments may be performed as routine(s), which may be implemented as added or updated software routine(s). Software routine(s) may be downloaded into the apparatus.

[0082] As an example, software or a computer program code or portions of it may be in a source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers may include a record medium, computer memory, read-only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers. The computer readable medium or computer readable storage medium may be a non-transitory medium.

[0083] In other example embodiments, the functionality may be performed by hardware or circuitry included in an apparatus (for example, apparatuses 1010, 1020, 1030, and/or 1040), for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another example embodiment, the functionality may be implemented as a signal, a non-tangible means that can be carried by an electromagnetic signal downloaded from the Internet or other network.

[0084] According to certain example embodiments, an apparatus, such as a node, device, or a corresponding component, may be configured as circuitry, a computer or a microprocessor, such as single-chip computer element, or as a chipset, including at least a memory for providing storage capacity used for arithmetic operation and an operation processor for executing the arithmetic operation.

[0085] The features, structures, or characteristics of example embodiments described throughout this specification may be combined in any suitable manner in one or more example embodiments. For example, the usage of the phrases “certain embodiments,” “an example embodiment,” “some embodiments,” or other similar language, throughout this specification refers 1 to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Thus, appearances of the phrases “in certain embodiments,” “an example embodiment,” “in some embodiments,” “in other embodiments,” or other similar language, throughout this specification do not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments.

[0086] Further, the terms “cell”, “node”, “gNB”, or other similar language throughout this specification may be used interchangeably.

[0087] As used herein, the expression “at least one of the following: <a list of two or more elements>” and the expression “at least one of <a list of two or more elements>” and expressions with similar wording, where the list of two or more elements are joined by “and” or “or,” mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements. As used herein, the expression “<a list of two or more elements>”, where the list of two or more elements are joined by “and/or”, means at least any one of the elements, or at least any two or more of the elements, or at least all the elements. Accordingly, these expressions are intended to mean any individual element of the list, or any combination of two or more elements of the list, or a combination of all of the elements of the list.

[0088] One having ordinary skill in the art will readily understand that the disclosure as discussed above may be practiced with procedures in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the disclosure has been described based upon these example embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of example embodiments. Although the above embodiments refer to 5G NR and LTE technology, the above embodiments may also apply to any other present or future 3 GPP technology, such as LTE-advanced, and/or fourth generation (4G) and/or sixth (6G) technology.

[0089] Partial Glossary:

[0090] 3 GPP 3rd Generation Partnership Project

[0091] 5G 5th Generation

[0092] 6G 6^th Generation

[0093] ATSSS Access Traffic Steering, Switching, Splitting

[0094] CP Control Plane

[0095] DL Downlink

[0096] EMBB Enhanced Mobile Broadband

[0097] gNB 5G or Next Generation NodeB

[0098] ID Identifier

[0099] LTE Long Term Evolution

[0100] MA Multi-Access

[0101] MA-PDU Multi- Access Packet Data Unit

[0102] MAR Multi- Access Rule

[0103] NAS Non-Access Stratum

[0104] NR New Radio

[0105] NW Network

[0106] PCC Policy and Charging Control

[0107] PCF Policy Control Function

[0108] PDU Packet Data Unit

[0109] PMF Performance Measurement Function

[0110] SDF Service Data Flow

[0111] SF Steering Function

[0112] SM Steering Mode

[0113] SMF Session Management Function [0114] UE User Equipment

[0115] UL Uplink

[0116] UP User Plane

[0117] UPF User Plane Function

Claims

WE CLAIM:

1. An apparatus comprising: means for requesting a user equipment to provide information related to access traffic steering, switching, splitting (ATSSS); means for generating or updating ATSSS rules for multi-access packet data unit sessions for the user equipment based on the information provided by the user equipment and, alternatively or additionally, based on policy rules received from a policy control function (PCF); means for generating or updating N4 rules for multi-access packet data unit sessions for a user plane function based on the information provided by the user equipment and, alternatively or additionally, based on the policy rules received from the policy control function (PCF); means for transmitting, to the user equipment, the generated ATSSS rules; and means for transmitting, to the user plane function, the generated N4 rules.

2. The apparatus according to claim 1, wherein the information related to ATSSS is provided for a set of service data flows associated with multi-access packet data unit sessions.

3. The apparatus according to claim 1 or claim 2, wherein the information related to ATSSS comprises one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier.

4. The apparatus according to any one of claims 1-3, further comprising: means for forwarding the information related to ATSSS, which was received from the user equipment, to a policy control function (PCF).

5. The apparatus according to any one of claims 1-4, further comprising: means for receiving the information related to ATSSS from the user plane function, to which the information related to ATSSS is forwarded from the user equipment.

6. The apparatus according to any one of claims 1-5, further comprising: means for generating ATSSS and N4 rules based on the information related to ATSSS received from a user plane function and, alternatively or additionally, based on policy rules received from the policy control function (PCF); and means for transmitting the generated N4 rules to the user plane function and the generated ATSSS rules to the user equipment.

7. The apparatus according to any one of claims 1-6, wherein the N4 rules comprise multi-access rules that may contain an indication that the N4 rules are subject to changes triggered by the user equipment provided information.

8. An apparatus comprising: means for providing, to a session management function, information related to access traffic steering, switching, splitting (ATSSS); means for receiving, from the session management function, updated N4 rules related to ATSSS; and/or means for updating one or more N4 rules containing multi-access rules related to ATSSS.

9. The apparatus according to claim 8, wherein the information related to ATSSS is provided for a set of service data flows associated with a multiaccess packet data unit session.

10. The apparatus according to claim 8 or claim 9, wherein the information related to ATSSS comprises one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier.

11. The apparatus according to any one of claims 8- 10, further comprising: means for receiving, from a user equipment, a performance measurement function message including the information related to ATSSS.

12. An apparatus comprising: means for determining one or more traffic descriptors and one or more access traffic steering, switching, splitting (ATSSS) rule identifiers related to ATSSS data; and means for providing the one or more traffic descriptors and the one or more ATSSS rule identifiers to a session management function via control plane messaging or to a user plane function via user plane messaging.

13. The apparatus according to claim 12, wherein the control plane messaging is non-access stratum (NAS) messaging and the user plane messaging is performance management function (PMF) protocol messaging.

14. The apparatus according to claim 12 or claim 13, wherein the one or more traffic descriptors and the one or more ATSSS rule identifiers are provided to allow identification of a set of service data flows associated with the multi-access packet data unit session.

15. The apparatus according to any one of claims 12-14, wherein the one or more traffic descriptors comprise one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier.

16. The apparatus according to any one of claims 12-15, further comprising: means for receiving one or more updated ATSSS rules; and means for updating the one or more ATSSS rules.

17. The apparatus according to any one of claims 12-16, further comprising: means for receiving an acknowledgement or a non-acknowledgement from the user plane function; and means for updating the one or more rules for ATSSS when the acknowledgement is received.

18. An apparatus comprising: means for receiving, from a session management function, information related to access traffic steering, switching, splitting (ATSSS), which was received from the session management function from a user equipment; means for updating one or more policy and charging control (PCC) rules based on the information related to ATSSS; and means for providing the updated one or more PCC rules to the session management function.

19. The apparatus according to claim 18, wherein the information related to ATSSS is provided for a set of service data flows for a multi-access packet data unit session.

20. The apparatus according to claim 18 or claim 19, wherein the information related to ATSSS comprises one or more of a source internet protocol address, a source port, a destination internet protocol address, a destination port, a transport protocol, a fully qualified domain name, an application identifier and/or a connection identifier.