Apparatus and method for supporting l4s in no-3GPP access environments

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate, and to a method performed by a non-3GPP interworking function (N3IWF) entity of a wireless communication system, the method comprising the steps of: receiving session management information from a session management function (SMF) entity via an access and mobility management function (AMF) entity, the session management information includes an explicit congestion notification (ECN) flag indication for supporting low latency, low loss, and scalable throughput (L4S) in non-3GPP access; determining a connection of an Internet Protocol Security (IPsec) sub-security association (SA) supporting a Quality of Service (QoS) flow of the L4S; and sending a message for requesting the IPsec sub-SA connection to the terminal.

Description

TECHNICAL FIELD

[0001] The disclosure relates to an apparatus and method for supporting L4S in a communication system considering non-3GPP access. BACKGROUND

[0002] 5G mobile communication technologies define wide frequency bands so that high transmission rates and new services are possible, and are implemented not only in "Sub 6 GHz" frequency bands, but also in "6 GHz and above" frequency bands (including 28 GHz, 39 GHz, and 60 GHz bands). In addition, 6G mobile communication technologies (referred to as Beyond 5G systems) have been discussed considering terahertz bands (for example, 95 GHz to 3 THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies, and ultra-low latencies of approximately 100 times lower than 5G mobile communication technologies.

[0003] At the early stage of 5G mobile communication technologies development, in order to support services and meet the performance requirements related to enhanced mobile broadband (eMBB) that is to be provided by 5G mobile communication technologies, ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC), standardization efforts have been conducted for techniques such as, beamforming, massive MIMO, utilization of the full-duplex, utilization of the millimeter wave (mmWave) band, and new numerologies in addition to techniques developed for 5G mobile communication technologies.

[0004] Currently, with respect to services to be supported by 5G mobile communication technologies, discussions are ongoing for improvement and enhancement of initial 5G mobile communication technologies, and physical layer standardization has been completed for techniques such as vehicle-to-everything (V2X) for supporting driving decisions and improving user convenience based on information about positions and states of vehicles transmitted by the vehicles, NR-U (New Radio Unlicensed) for operating system in compliance with various regulatory requirements in unlicensed bands, NR UE power saving, non-terrestrial network (NTN) that is direct communication of a UE with a satellite for ensuring coverage in an area where communication with a terrestrial network is not possible, and positioning

[0005] Further, standardization for air interface architecture / protocol of the following technologies has been ongoing: Industrial Internet of Things (IIoT) for support of new services through interworking and convergence with other industries; IAB (Integrated Access and Backhaul) for providing nodes for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner; mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover; and two-step random access (2-step RACH for NR) for simplifying random access procedures. Meanwhile, standardization for system architecture / service of the following technologies has been ongoing: 5G baseline architecture for combination of network functions virtualization (NFV) and software-defined networking (SDN) technologies (e.g., service-based architecture or service-based interface); and mobile edge computing (MEC) for receiving services based on UE location.

[0006] As the commercialization of 5G mobile communication systems, connected devices, which have increased exponentially, will be connected to communication networks, and thus it is expected that there will be a need for enhanced functionality and performance of 5G mobile communication systems and integrated operation of connected devices. For this reason, new research on the following technologies has been scheduled: XR (Extended Reality) for efficient support of AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality), etc.; 5G performance improvement and complexity reduction by utilizing AI (Artificial Intelligence) and ML (Machine Learning); AI service support; metaverse service support; and drone communication.

[0007] Further, such development of 5G mobile communication systems will lay the groundwork not only for developing new waveforms for providing coverage in the terahertz bands for 6G mobile communication technologies, but also for developing multi-antenna transmission technologies such as FD-MIMO (Full-Dimensional MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas for improving coverage of terahertz band signals; high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum); and RIS (Reconfigurable Intelligent Surface), but also for developing full-duplex technologies for increasing frequency efficiency of 6G mobile communication technologies and improving system networks; AI-based communication technologies for implementing system optimization from the design stage by utilizing satellites and AI (Artificial Intelligence) and internalizing end-to-end AI support functions; and next-generation distributed computing technologies for implementing services by utilizing super-high-performance communication and computing resources at a complexity level exceeding the limit of UE operation capabilities.

[0008] As described above, with the development of mobile communication systems, it is now possible to provide various services, and methods for effectively providing such services are needed.

[0009] Low latency, low loss, and scalable throughput (L4S) services are supported by many devices and servers due to the following advantages: signals indicating L4S (Explicit Congestion Notification (ECN)) support and congestion can be delivered by in-band markings on existing protocols without separate control plane call processing signals between intermediate nodes.

[0010] In a metaverse and XR application, a relatively large amount of uplink data should be transmitted, and when network congestion occurs, a method of adjusting the uplink transmission rate considering network congestion can be applied. In order to provide an L4S supported service in a non-3GPP access environment, technical improvements are needed in terms of delivery and operation methods of L4S service related information. SUMMARY

[0011] TECHNICAL PROBLEM

[0012] One aspect of the disclosure is to provide a device and method capable of providing congestion information in a communication system including non-3GPP access.

[0013] One aspect of the disclosure is to provide a device and method for providing congestion information based on whether L4S (ECN) is supported in a communication system based on non-3GPP access.

[0014] Problem Solution

[0015] According to one aspect of the disclosure, a method performed by a non-3GPP interworking function (N3IWF) entity in a communication system based on non-3GPP access includes including L4S support indicator information in an NGAP initial context setup response message to transmit the information to an AMF, receiving an N2 PDU session request message including L4S support indicator information from the AMF, determining the number of IPsec sub-SAs based on the N2 PDU session request message, and establishing IPsec sub-SAs.

[0016] According to an aspect of the disclosure, there is provided an operation method of a non-3GPP interworking function (N3IWF) entity in a communication system based on non-3GPP access, the operation method including: receiving a message containing information related to whether an S-RAN in an IPsec tunnel between a UE, a non-3GPP access point (AP), and the N3IWF supports a low latency, low loss, and scalable throughput (L4S) service; transmitting, to a session management function (SMF) through an AMF during a UE registration request on a 5G system, information (an ECN marking support indication in a non-3GPP AP or an ECN marking support indication in an IPsec SA) related to an ECN marking support indicator in a corresponding IPsec security association (SA) part after an IPsec SA; sending, to the SMF entity, a protocol data unit (PDU) session management (SM) update request message containing information related to whether the N3IWF supports the L4S service based on the L4S service support indicator message; and receiving, from the SMF entity, a PDU SM update response message in response to the PDU SM update request message.

[0017] According to an aspect of the disclosure, there is provided an access and mobility management function (AFM) entity including a transceiver and at least one processor, wherein the at least one processor is configured to: receive, from an N3IWF connected to a UE, a message containing information related to whether the N3IWF supports a low latency, low loss, and scalable throughput (L4S) service through the transceiver; send, to a session management function (SMF) entity, a protocol data unit (PDU) session management (SM) update request message containing information about whether an S-RAN supports the L4S service; and receive, from the SMF entity, a PDU SM update response message in response to the PDU SM update request message through the transceiver.

[0018] Advantageous Effects

[0019] According to embodiments of the disclosure, in order for the UE to use a base station based on non-3GPP access, when the UE searches for N3IWF and performs an IPsec SA procedure between the UE, the non-3GPP AP, and the N3IWF, the UE can determine whether ECN marking and L4S are supported between the UE, the non-3GPP AP, and the N3IWF, and can transmit corresponding ECN / L4S capability information to the AMF through a UE registration procedure, or to a session management function (SMF) entity during a PDU session connection request. In the case where an L4S support indicator is transmitted from the AF or the like to the N3IWF, when the N3IWF can perform ECN marking for L4S service support, for uplink packets, ECN marking can be performed based on information of an outer header of an IPsec packet and information of a congestion situation of a non-3GPP AP. In addition, for downlink, the UE can also report congestion situation information to the AS based on CE information in the outer header to identify the congestion situation of the non-3GPP AP.

[0020] In general, in order to access a 5G system through non-3GPP access, an IPsec tunnel technology can be performed between the UE and the N3IWF, whereby the UE can perform an authorization and security procedure to use the corresponding N3IWF. In non-3GPP access, ECN marking can be distinguished as ECN information in an inner IP header (including ECN information of the UE for uplink and ECN information of the N3IWF for downlink) and ECN information of an outer header indicating a congestion situation of a non-3GPP AP for each data transmission. In general, in an IPsec tunnel mode, an ECN-enabled connection can be transmitted in two methods, including a function-limited method in which only information of an inner header is used for security reasons, and a function-complete method in which information of an outer header is also considered.

[0021] As an example of the disclosure, in the case of non-3GPP access using N3IWF, an IKEv2-based key exchange protocol is generally used when performing an IPsec SA operation; and in the case where an ECN-enabled IPsec SA is connected through an IKEv2-based protocol, an ECN function operation scheme in an IPsec tunnel can generally be supported as a complete function.

[0022] The information on the congestion occurrence of the N3IWF can be delivered to a User Plane Function (UPF) entity through QoS monitoring, and the UPF entity can perform L4S (ECN) marking and then notify the application server (AS) of the congestion occurrence via in-band signaling. In this case, the N3IWF can generate congestion information of the non-3GPP AP based on the ECN bit information in the outer header of the IPsec packet and deliver it to the UPF through the GTP-U extension header. In addition, the congestion information can occur not only in the non-3GPP AP but also in the N3IWF. In this case, in the process of generating the congestion information, when the information is the ECN marking for the downlink packet, the ECN bit information of the inner header of the IPsec packet can be delivered to the UPF, and when the information is the ECN marking information for the uplink packet, the ECN bit information of the outer header can be delivered to the UPF. When the congestion occurrence occurs in both network entities (N3IWF and non-3GPP AP), the congestion information can contain the congestion information from the N3IWF and the congestion information from the non-3GPP AP, and the congestion information of each network entity can be delivered separately.

[0023] In addition, after establishing the IPsec SA, the N3IWF can receive a PDU session establishment request message from the UE and then transmit it to the SMF through the AMF, thereby receiving a QoS profile and related QFI, a PDU session ID, and / or a PDU session establishment accept message through the AMF. Based on this information, the N3IWF can determine the number of IPsec sub-SAs per QoS. In this case, if there is a QoS flow with an L4S support request among the QoS flows received from the AMF, the N3IWF can determine to generate an IPsec sub-SA accordingly. If the N3IWF receives information indicating that there are 9 general QoS flows and one QoS flow needs L4S service from the AMF, the N3IWF can provide service for the general QoS flow by using one IPsec SA as IPSEC sub-SA #1 in order to provide an IPsec tunnel between the UE and the N3IWF, and in addition to the general IPsec sub-SA tunnel, service utilization can be determined by generating a separate tunnel as IPsec sub-SA #2 for the QoS flow that needs L4S service. As shown in the above example, due to security reasons, the N3IWF can not provide a service using ECN in a service using a non-3GPP access according to the selection of the UE or the selection of the service provider. In this case, the N3IWF can determine the connection of two or more IPsec sub-SAs with respect to the IPsec sub-SAs connected to the same UE, including an IPsec sub-SA for transmitting a general QoS flow and an IPsec sub-SA for transmitting a QoS flow supporting L4S service through ECN marking.

[0024] According to embodiments of the disclosure, in a non-3GPP access-based communication system, congestion information is provided based on whether L4S (ECN) is supported, so that an L4S service can be provided in a non-3GPP access-based communication system. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 A network structure and interfaces of a 5G system according to embodiments of the disclosure are illustrated.

[0026] Figure 2 A 5GC registration procedure through untrusted non-3GPP access of a UE according to embodiments of the disclosure is illustrated.

[0027] Figure 3 Operations of an N3IWF according to a request for L4S service support for a QoS flow providing a service via untrusted non-3GPP access in an AF according to embodiments of the disclosure are illustrated.

[0028] FIGS. 4A and 4B are flowcharts illustrating operations of transmitting ECN capability information of an IPsec SA to an SMF during a 5GC registration and PDU session connection procedure via untrusted non-3GPP access according to embodiments of the disclosure.

[0029] FIG. 5A is a flowchart illustrating operations and methods of updating a QoS flow for L4S support according to embodiments of the disclosure.

[0030] FIG. 5B is a flowchart illustrating operations and methods of updating a QoS flow for L4S support according to embodiments of the disclosure.

[0031] Figure 6 An example of a functional structure of a UE according to embodiments of the disclosure is illustrated.

[0032] Figure 7 An example of a functional structure of a network entity according to embodiments of the disclosure is illustrated. DETAILED DESCRIPTION

[0033] Hereinafter, embodiments of the disclosure will be described in detail with reference to the accompanying drawings.

[0034] In describing the processes of the disclosure, descriptions related to technical contents well known in the art and having no direct relation to the disclosure will be omitted. Such omission of unnecessary descriptions is to prevent the main idea of the disclosure from being obscured, and to more clearly convey the main idea. Terms to be described hereinafter are terms defined in consideration of functions in the disclosure, and can vary according to users, user's intension, or habits. Therefore, the definition of the terms should be determined based on the contents throughout the entire specification.

[0035] For the same reason, in the drawings, some elements can be exaggerated, omitted, or schematically shown. Also, the size of each element does not completely reflect its actual size. In the corresponding drawings, the same or corresponding elements are assigned the same reference numerals.

[0036] In the following description, a base station is an entity that allocates resources to a terminal, and can be at least one of a gNode B, an eNode B, a Node B (or an xNode B (where x is a letter including g or e)), a radio access unit, a base station controller, a satellite, an airborne device, and a node on a network. A user equipment (UE) can include a mobile station (MS), a vehicle, a satellite, an airborne device, a cellular phone, a smart phone, a computer, or a multimedia system capable of performing a communication function. In the present disclosure, "downlink (DL)" refers to a radio link via which a base station transmits a signal to a terminal, and "uplink (UL)" refers to a radio link via which a terminal transmits a signal to a base station. Further, there can be a "sidelink (SL)", which refers to a radio link via which a UE transmits a signal to another UE.

[0037] Further, in the following description, LTE, LTE-A, or a 5G system can be described by way of example, but embodiments of the present disclosure can also be applied to other communication systems having a similar technical background or channel type. For example, a sixth generation (6G) mobile communication technology (or new radio (NR)) in which advanced 5G, advanced NR, or beyond 5G mobile communication technology can be included, and in the following description, "5G" can be a concept covering existing LTE, LTE-A, or other similar services. In addition, based on the judgment of those skilled in the art, the present disclosure can also be applied to other communication systems with some modifications without significantly departing from the scope of the present disclosure.

[0038] In this document, each block denoting a flowchart diagram and combinations of blocks in the flowchart diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions can also be stored in a computer usable or computer readable memory such that the instructions could, when executed by the computer or other programmable data processing apparatus, create a means for implementing the functions specified in the flowchart block or blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0039] Also, each block in the flowchart diagrams can represent a module, a segment, or a portion of code, which includes one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved.

[0040] As used in the embodiments of the present disclosure, the term "unit" refers to a software or hardware component, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), which is configured to perform a specific function. However, the "unit" is not limited to a software or hardware component, and can be configured to perform some functions. The "unit" can be configured as software or hardware components, or a combination thereof. For example, the "unit" can be implemented in one of software, hardware, and firmware, or a combination thereof. The "unit" can be configured to perform some functions, and can be implemented as a component such as a software module, a processor or a memory, or a combination thereof. The "unit" can be configured to operate together with another component to perform some functions, and can be implemented as a component such as a software module, a processor or a memory, or a combination thereof. The "unit" can be configured to operate independently of another component, and can be implemented as a component such as a software module, a processor or a memory, or a combination thereof.

[0041] The 3GPP, which is in charge of standardization of cellular mobile communication, has introduced a new core network structure called 5G core (5GC), and is advancing standardization thereof in order to promote evolution from a 4G LTE system to a 5G system. In comparison with an evolved packet core (EPC) that is a core of a 4G network, the 5GC supports the following significantly different functions.

[0042] In the 5GC, a network slicing function is introduced. According to requirements of 5G, the 5GC needs to support various terminal types and services (e.g., enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine type communication (mMTC)). These terminals / services have different requirements for a core network, respectively. For example, an eMBB service can require a high data rate, and an URLLC service can require high stability and low latency. A network slicing technology has been proposed to meet these different service requirements.

[0043] A network slice can refer to a method of virtualizing one physical network to form a plurality of logical networks (e.g., network slices). An activated network slice can be referred to as a network slice instance, and each network slice instance (NSI) can have different characteristics. A mobile communication service provider can configure a network function (NF) suitable for characteristics of each NSI, thereby meeting various service requirements according to terminals / services. For example, a mobile communication service provider can allocate an NSI suitable for characteristics required by a service thereof, thereby being able to efficiently support a plurality of 5G services (e.g., eMBB, URLLC, or mMTC).

[0044] The 5GC can easily support a network virtualization mode by separating a mobility management function and a session management function. In 4G LTE, all terminals are provided with services from a network by performing signaling exchange with a single core device (referred to as a mobility management entity (MME) for registration, authentication, and mobility management and session management functions). In 5G, with explosive growth in the number of terminals including, for example, MTC terminals, and mobility and traffic / session characteristics that need to be supported have been subdivided according to terminal types, scalability in terms of adding entities according to required functions is inevitably reduced if a single entity (e.g., MME) supports all functions. Therefore, in order to improve scalability in terms of signaling load and function / implementation complexity of a core entity in charge of a control plane, various functions are being developed based on a separated structure of a mobility management function and a session management function.

[0045] Embodiments according to the disclosure can indicate a method for supporting a PDU set establishment request procedure of a UE in a non-trusted or trusted non-3GPP access in order to connect to a 5GC through a non-3GPP access point in the UE, and a procedure for performing related operations. Specifically, embodiments according to the disclosure can indicate a method for supporting L4S-based services by transmitting congestion situation information to an AS or a UE when a congestion situation occurs in a network to thereby implement appropriate congestion situation control, and related operations. In a non-3GPP access environment, a UE can perform an IPsec SA connection operation between the UE and an N3IWF to perform a UE registration procedure in order to use a service through a 5GC. During an IPsec SA connection establishment procedure between the UE and the N3IWF, it can be simultaneously determined whether the IPsec SA supports ECN / L4S, and this information can be transmitted to an AMF during a UE 5GC registration procedure. For example, if ECN marking is supported in a non-3GPP access point during establishment of an IPsec SA connection between a corresponding UE and an N3IWF, a UE connected through a non-3GPP access point can transmit information indicating support for L4S-based services to the network. Information indicating that an IPsec SA between the UE and the N3IWF through a specific non-3gpp access point supports ECN can be first stored in the AMF through a registration procedure in the 5GC. Furthermore, if a PDU session establishment request is then received from the UE, the information can be transmitted from the AMF to the SMF during a corresponding PDU session establishment procedure. Alternatively, when the N3IWF does not transmit information about whether an IPsec SA supports ECN to the AMF during a separate registration procedure, the UE can include information about whether an IPsec SA supports ECN / L4S in a PDU session establishment request message through a separate indicator (e.g., an L4S support indication of the IPsec SA), and transmit the information. Through the above-described procedure, the SMF can recognize that an IPsec SA between the UE connected through a specific non-3GPP access point and the N3IWF is capable of supporting an L4S service. When L4S support request information for a specific QoS flow is transmitted to the PCF via an AF during use of a service through a non-3GPP access, the PCF can transmit the L4S service support request information for the specific QoS flow to the SMF through a PCC rule update procedure. The SMF can determine whether to accept the L4S service support request information for the specific QoS flow of the UE based on a preconfigured policy or information transmitted during a PDU session establishment procedure. The SMF can receive information about whether an IPsec SA supports ECN from the AMF or the UE in a PDU session establishment procedure, and can determine whether to accept the L4S service support request information for the specific QoS flow of the UE transmitted from the AF based on the information.Further, whether the SMF supports the L4S service for a specific QoS flow can be determined based on a case in which the N3IWF that connects to the UE using a service through a non-3GPP access is capable of directly marking information on a congestion situation in the ECN bit in the ToS field in the IP header, or in which the N3IWF is capable of supporting marking of congestion information in a GTP-U extension header, so that the congestion information can be transferred to the UPF through the GTP-U extension header. If the N3IWF supports one or more of the two marking methods for transferring congestion information, the SMF can determine that the N3IWF can support the L4S service. Since information on the marking method being supportable is received from the N3IWF during the PDU session establishment procedure, the SMF can acquire information on whether the N3IWF supports the ECN marking operation for transferring congestion information. The SMF can pre-identify the congestion information marking support operation information of the N3IWF, as well as support for ECN / L4S marking by the IPsec SA between the N3IWF and the UE using the corresponding QoS flow, and the SMF can determine whether to accept the L4S service support request for a specific QoS flow sent from the AF based on this.

[0046] If the N3IWF is unable to perform ECN marking on the presence of congestion information within the IP header, the SMF can include the congestion information in the GTP-U extension header and transfer it to the UPF. In this case, the SMF can determine whether the UPF is capable of performing ECN marking, and if the UPF does not support the corresponding function, the SMF can determine to replace the UPF that supports the ECN marking operation.

[0047] The SMF can determine whether the L4S is supported for a specific QoS flow requested by the AF based on the ECN marking support of the IPsec SA and the operation of the UPF according to the method in which the N3IWF transmits congestion information. If it is determined that the L4S is not supported, the SMF can notify the AF that the L4S-based service is not available for the corresponding QoS flow.

[0048] Figure 1 A network structure and interfaces of a 5G system according to an embodiment of the disclosure are illustrated.

[0049] According to the system implementation, Figure 1 The network entities included in the network structure of the 5G system in FIG. 1 can include network functions (NFs).

[0050] Reference Figure 1The network structure of the 5G system 100 can include various network entities. For example, the 5G system 100 can include an authentication server function (AUSF) entity 108, a (core) access and mobility management function (AMF) entity 103, a session management function (SMF) entity 105, a policy control function (PCF) entity 106, an application function (AF) entity 107, a unified data management (UDM) entity 109, a data network (DN) 110, a network exposure function (NEF) entity 111, a network slice selection function (NSSF) entity 114, an edge application service domain repository (EDR), an edge application server (EAS), an EAS discovery function (EASDF), a user plane function (UPF) entity 104, a (radio) access network (R)AN 102, and a terminal, such as a user equipment (UE) 101.

[0051] The respective NFs in the 5G system 100 can support the following functions.

[0052] The AUSF 108 processes and stores data for authentication of the UE 101.

[0053] The AMF 103 can provide functions for access and mobility management on a per-UE basis, and basically one UE can be connected to one AMF. Specifically, the AMF 103 supports the following functions: inter-CN node signaling, such as for mobility between 3GPP access networks, termination of a radio access network (RAN) CP interface (i.e., N2 interface), termination of non-access stratum (NAS) signaling (N1), NAS signaling security (NAS ciphering and integrity protection), AS security control, registration management (registration area management), connection management, idle mode UE reachability (including control and execution of paging retransmission), mobility management control (subscription and policy), intra- and inter-system mobility support, support of network slicing, SMF selection, lawful intercept (interfaces to the AMF event and LI system), provisioning of transport for session management (SM) messages between the UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization including check of roaming rights, provisioning of transport for SMS messages between UE and SMSF, security anchor function (SEA), and / or security context management (SCM). Part or all of the functions of the AMF entity 103 can be supported within a single instance of an AMF entity.

[0054] For example, the DN 110 refers to, for example, operator services, Internet access, or third party services. The DN 110 transmits a downlink protocol data unit (PDU) to the UPF 104 or receives a PDU transmitted by the UE 101 from the UPF 104.

[0055] The PCF entity 106 provides functions to receive information about packet flows from application servers to determine policies such as mobility management and session management. Specifically, the PCF entity 106 supports functions such as: support for a unified policy framework to control network operation; provision of policy rules so that control plane functions (e.g., AMF entity, SMF entity, etc.) can implement these policy rules; and implementation of a front end to access relevant subscription information in a user data repository (UDR) for policy decisions.

[0056] The SMF entity 105 provides session management functions, and if the UE 101 has multiple sessions, each session can be managed by a different SMF entity. Specifically, the SMF entity 105 supports functions such as: session management (e.g., establishment, modification, and release of sessions, including maintenance of tunnels between UPF entity 104 and (R)AN 102 nodes); allocation and management of UE IP address (optionally including authentication); selection and control of UP function; configuration of traffic control for routing traffic from the UPF entity 104 to the appropriate destination; and termination of interfaces towards policy control functions; enforcement of control part of policy and quality of service (QoS); lawful intercept (LI) (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; delivery of access network (AN)-specific SM information to RAN 103 over N2 via initiator (AMF entity 102); determination of session and service continuity (SSC) mode; and roaming functions. Some or all of the functions of the SMF entity 105 can be supported within a single instance of the SMF entity.

[0057] The UDM entity 109 stores subscription data, policy data, and the like of users. The UDM entity 109 includes two parts, an application front end (FE) (not shown) and a user data repository (UDR) (not shown).

[0058] The FE includes a UDM FE responsible for location management, subscription management, credential handling, and the like, and a PCF entity responsible for policy control. The UDR stores data required for the functions provided by the UDM-FE, as well as policy profiles required for the PCF entity. The data stored in the UDR includes policy data and user subscription data, including subscription identifiers, security credentials, subscription data related to access and mobility, and session-related subscription data. The UDM-FE supports functions such as: access to subscription information stored in the UDR, authentication credential handling, user identification handling, access authentication, registration / mobility management, subscription management, and SMS management.

[0059] The UPF entity 104 transmits downlink PDUs received from the DN 110 to the UE 101 via the (R)AN 102, and transmits uplink PDUs received from the UE 101 to the DN 110 via the (R)AN 102. Specifically, the UPF entity 104 supports functions such as: anchor point for intra- / inter-RAT mobility, external PDU session point of interconnect with data networks, packet routing and forwarding, user plane part of packet inspection and policy rule enforcement, lawful intercept, traffic usage reporting, uplink classifier to support routing traffic flows to data networks, branching point to support multi-homed PDU session, QoS handling for user plane (e.g., packet filtering, gating, and uplink / downlink rate enforcement), uplink traffic verification (SDF mapping between service data flow, SDF, and QoS flow), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering functions. Some or all of the functions of the UPF entity 104 can be supported within a single instance of a UPF.

[0060] The AF entity 107 interacts with the 3GPP core network to provide services (e.g., support certain functions such as application influence on traffic routing, access to network capability exposure, and interaction with policy framework for policy control).

[0061] The (R)AN 102 refers to a new radio access network that supports both Evolved E-UTRA (E-UTRA, which is an evolved version of the 4G radio access technology) and new radio (NR) access technology (e.g., gNB) in its entirety.

[0062] The gNB supports functions such as functions for: radio resource management (i.e., radio bearer control, radio admission control, connection mobility control, and dynamic allocation (i.e., scheduling) of resources to UEs in uplink / downlink); Internet Protocol (IP) header compression; ciphering and integrity protection of user data flow; selection of AMF after attach of the UE when the routing to AMF is not determined based on the information provided to the UE; routing of user plane data to UPF; routing of control plane information to AMF; connection establishment and release; paging message scheduling and transmission (generated from AMF); system broadcast information scheduling and transmission (generated from AMF or from operation and maintenance (O&M)); measurement and measurement reporting configuration for mobility and scheduling; transport level packet marking in uplink; session management; support of network slicing; QoS flow management and mapping to data radio bearers; support of UEs in inactive mode; distribution function of NAS messages; NAS node selection function; radio access network sharing; dual connectivity; and tight interworking between NR and E-UTRA.

[0063] The UE 101 refers to a user equipment. The user equipment can be referred to as the term "terminal," "mobile equipment (ME)," "mobile station (MS)," or the like. Further, the user equipment can be a portable device such as a notebook, a mobile phone, a personal digital assistant (PDA), a smart phone, or a multimedia device, or can be a non-portable device such as a personal computer (PC) or a vehicle-mounted device.

[0064] The NEF 111 provides a means for securely exposing services and capabilities provided by 3GPP network functions, for example, for third party, internal exposure / re-exposure, application functions, and edge computing. The NEF 111 receives information from other NFs (based on exposed capabilities of other NFs). As a data storage network function, the NEF 111 can store the received information as data structured by using a standardized interface. The stored information can be re-exposed to other NF entities and AF entities by the NEF entity 111, and used for other purposes (such as analytics).

[0065] The EASDF is an NF that can add an address of a DNS server for forwarding a DNS request of a UE, and an ECS option expressible by an IP subnet address, in order to add the option when forwarding the DNS request of the UE, for each FQDN. The EASDF receives EAS domain configuration information from the EDR, and processes a DNS request message received from the UE according to the received information. Further, the EASDF is an NF that performs the following functions: receiving a UE IP address, location information of the UE in 3GPP, a DNS message processing rule, and a DNS message reporting rule from the SMF 105; processing a DNS query message received from the UE and a DNS response message received from a DNS server; and transmitting information in the DNS message and statistical information obtained by processing the message to the SMF 105 according to the DNS message reporting rule.

[0066] The NRF supports a service discovery function. The NRF receives an NF discovery request from an NF instance, and provides discovered NF instance information to the NF instance. Further, the NRF maintains available NF instances and services supported by the available NF instances.

[0067] Although, for ease of description, Figure 1 A reference model in which the UE 101 accesses one DN 110 by using one PDU session is illustrated, but the disclosure is not limited thereto.

[0068] The UE 101 can simultaneously access two (i.e., local and central) data networks by using multiple PDU sessions. In this case, two SMFs can be selected for different PDU sessions. However, each SMF can have the capability of controlling both the local UPF and the central UPF within the PDU session.

[0069] In addition, the UE 101 can simultaneously access two (i.e. local and central) data networks set within a single PDU session.

[0070] In the 3GPP system, the concept link connecting NFs in the 5G system is defined as a "reference point". As an example, Figure 1 The reference points contained in the 5G system 100 are as follows.

[0071] - N1: Reference point between the UE 101 and the AMF 103

[0072] - N2: Reference point between the (R)AN 102 and the AMF 103

[0073] - N3: Reference point between the (R)AN 102 and the UPF 104

[0074] - N4: Reference point between the SMF 105 and the UPF 104

[0075] - N5: Reference point between the PCF 106 and the AF 107

[0076] - N6: Reference point between the UPF 104 and the DN 110

[0077] - N7: Reference point between the SMF 105 and the PCF 106

[0078] - N8: Reference point between the UDM 109 and the AMF 103

[0079] - N10: Reference point between the UDM 109 and the SMF 105

[0080] - N11: Reference point between the AMF 103 and the SMF 105

[0081] - N12: Reference point between the AMF 103 and the AUSF 108

[0082] - N13: Reference point between the UDM 109 and the AUSF 108

[0083] - N14: Reference point between two AMFs 103

[0084] - N15: Reference point between the PCF and the AMF for a non-roaming scenario, and between the PCF in a visited network and the AMF for a roaming scenario

[0085] - Nx: Reference point between the SMF 105 and the EASDF

[0086] - Ny: Reference point between NEF (EDF) 111 and EASDF

[0087] Figure 2 A 5GC registration procedure over a non-trusted non-3GPP access by a UE is shown in accordance with embodiments of the disclosure. More specifically, Figure 2 Operations are shown in which whether ECN / L4S delivery to the network is supported in the IPsec SA between the UE and the N3IWF during the 5GC registration procedure.

[0088] Reference Figure 2 , the N3IWF can connect the UE connected to the 5G core network through the non-3GPP access by the IKEv2 / IPsec protocol and the N2 interface interworking. The IPsec SA connection between the UE and the N3IWF can be established through a separate security and authentication procedure. In this case, the message protocol for the security and authentication procedure is the Internet Key Exchange (IKE) v2 protocol. Unlike the existing structure between the UE and the NG-RAN, under the non-3GPP access, a non-3GPP access point (e.g., Wi-Fi) can be added between the UE and the N3IWF. The UE can exchange data with the N3IWF through the non-3GPP access point, and in this case, according to the structure of the IPsec, the IP header and the payload transmitted to the existing N3IWF can be defined as an inner IP packet. In the IPsec tunnel mode, an additional outer IP packet can be defined, which has a corresponding inner IP packet as a payload. That is, in the IPsec SA part, an outer IP packet can be generated, and it can be delivered to the UE through the non-3GPP access point. For example, in the case of uplink, the IP packet transmitted from the UE can be included in the payload of the outer IP packet as an inner IP packet and transmitted. Accordingly, the non-3GPP AP can deliver the congestion situation information of the corresponding non-3GPP access part to the UE or the N3IWF through the header of the outer IP packet. During the procedure of establishing the IPsec SA, the UE and the non-3GPP AP and the N3IWF can exchange ECN Capable Transport (ECT) information through the IP header, and the SMF can determine whether to support the ECN marking and the L4S service of the IPsec SA based on the information. The non-3GPP access IPsec SA can exchange authentication and security messages by using the IKEv2. In this case, when the ECN or the L4S is supported in the IPsec SA, this can support the full function of adding the congestion information of the non-3GPP access part to the outer IP header.

[0089] The information that the IPsec SA between the UE and the N3IWF supports ECN can be first stored in the AMF through the 5GC registration procedure, and then, when a PDU session establishment request from the UE is received, the information can be transferred from the AMF to the SMF during the corresponding PDU session establishment procedure. Alternatively, in the case where the N3IWF does not transmit information about whether the IPsec SA supports ECN or L4S to the AMF in a separate registration procedure, the UE can include information about whether the IPsec SA supports ECN / L4S in a PDU session establishment request message through a separate indicator (L4S support indication of IPsec SA) and transmit it to the SMF.

[0090] The SMF can identify that the L4S service is supported through the IPsec SA between the UE and the N3IWF connected through a specific non-3GPP AP.

[0091] During the use of a service via a non-3GPP access, when L4S support request information for a specific QoS flow is transferred to the PCF through the AF, the PCF can transfer the L4S service support request information for the specific QoS flow to the SMF through a PCC rule update procedure. The SMF can determine whether to accept the request for L4S service support for the specific QoS flow based on a preconfigured policy or information delivered during a PDU session establishment procedure. In the PDU session establishment procedure, the SMF can receive information about whether ECN is supported in the IPsec SA from the AMF or the UE, and can determine whether to accept the request for L4S service support for the specific UE from the AF based on the information. In addition, the SMF can determine whether to accept the request for L4S service support for the specific QoS flow based on whether the N3IWF satisfies the following conditions. If the N3IWF is capable of marking information about congestion conditions in the ECN bit in the ToS field in the IP header, or if the N3IWF is capable of marking congestion information in the GTP-U extension header and transferring it to the UPF, the N3IWF can determine to support the L4S service. In addition, in the case of a service through a non-3GPP access, when the N3IWF supports one or more marking methods for the transmission of congestion information, and the ECN / L4S service (supports ECN) can be supported in the IPsec SA part between the corresponding N3IWF and the UE, the SMF can determine whether to accept the request for L4S service support for the corresponding QoS flow using the non-3GPP access.

[0092] During the PDU session establishment procedure, the SMF can receive information on the marking operation (IP header marking or GTP-U header marking) by the N3IWF for delivering congestion information from the N3IWF. Based on the information on the N3IWF's congestion information marking support operation, and information on whether the UPF supports the operation for marking the ECN bits in the IP header according to the congestion information marking support operation, and information on whether the IPsec SA supports the ECN / L4S for the corresponding QoS flow, the SMF can determine whether to accept the request for the L4S service for the specific QoS flow.

[0093] Figure 3 It is shown that in the AF according to an embodiment of the disclosure, the N3IWF performs an operation according to a request for L4S service support for a QoS flow that provides a service via a non-trusted non-3GPP access.

[0094] As Figure 2 indicated, during the establishment of the IPsec SA connection between the UE and the N3IWF, information indicating that the ECN / L4S can be supported in the IPsec SA can be stored in the AMF during the 5GC registration procedure by the UE via the N3IWF. In addition, during the subsequent PDU session establishment request procedure, the information on whether the IPsec SA supports the ECN / L4S stored in the AMF can be transferred to the SMF. Alternatively, the information on whether the IPsec SA supports the ECN / L4S can not be transferred through the 5GC registration procedure, and the UE can include a separate indicator on whether the IPsec SA supports the ECN / L4S (L4S support indication of the IPsec SA) in the PDU session establishment request message and send it to the SMF. Therefore, the SMF can recognize that the L4S service can be supported by the IPsec SA between the UE and the N3IWF via a specific non-3GPP AP.

[0095] During the use of a service via non-3GPP access, when L4S support request information for a specific QoS flow is transferred to the PCF by the AF, the PCF can transfer the L4S service support request information for the specific QoS flow to the SMF through a PCC rule update procedure. The SMF can determine whether to accept the L4S service support request for the specific QoS flow based on a preconfigured policy or information transferred in a PDU session establishment procedure. The SMF can receive information on whether an IPsec SA supports ECN from the AMF or the UE in the PDU session establishment procedure, and can determine whether to accept the L4S service support request for the specific QoS flow of the UE transferred from the AF based on the information. In addition, the SMF can determine whether to accept the L4S service support request for the specific QoS flow based on whether the N3IWF satisfies the following conditions. In the case where the N3IWF is capable of directly marking information on congestion conditions in a ToS field in an IP header, or in the case where the N3IWF is capable of marking congestion information in a GTP-U extension header and transmitting it to the UPF, it can be determined that the N3IWF can support the L4S service. In addition, in the case of using a service via non-3GPP access, when the N3IWF supports one or more marking methods for transferring congestion information, and the IPsec SA part between the N3IWF and the UE can support the ECN / L4S service (supports ECN), the SMF can determine whether to accept the L4S service request for the corresponding QoS flow using the non-3GPP access.

[0096] During the PDU session establishment procedure, the SMF can receive information on marking operations (IP header marking or GTP-U header marking) for transferring congestion information by the N3IWF from the N3IWF. Based on the N3IWF congestion information marking support operation information, and information on whether the UPF supports an operation for marking an ECN bit in an IP header according to the congestion information marking support operation, and information on whether the IPsec SA supports the ECN / L4S of the corresponding QoS flow, the SMF can determine whether to accept the L4S service support request for the specific QoS flow.

[0097] The N3IWF that has received the L4S service support indicator (L4S support indication) or the congestion information marking request information of the L4S service support can identify the IPsec sub-SAs including the QoS flow for which the L4S service support has been requested, and then, when the corresponding IPsec sub-SAs are configured to support ECN / L4S, the N3IWF can perform L4S service support by performing ECN / L4S marking on the current IPsec sub-SAs. However, in the case where the specific QoS flow for which the L4S service support has been requested is included in the IPsec sub-SAs that do not support ECN, when there is a separate IPsec sub-SA that supports ECN, the N3IWF can move to the IPsec sub-SA for the corresponding QoS flow, and when there is no separate IPsec sub-SA, the N3IWF can transmit a connection request of the IPsec sub-SA to the UE to newly connect the IPsec sub-SA that supports ECN. With respect to the operation in which the N3IWF connects a separate IPsec sub-SA for a QoS flow to support the L4S service, the PCF can perform a corresponding operation based on preconfigured parameters related to a specific QoS flow when requesting establishment of a PDU session from the UE, or can determine whether to perform the operation according to a separate PDU session change request during service usage by the AMF, which contains L4S service support indicator information of a specific QoS flow, etc.

[0098] Thereafter, after establishing a new IPsec SA connection for ECN support, the N3IWF can migrate resources of the QoS flow for which the L4S service support has been requested to the corresponding IPsec SA, and can separately transmit L4S support indication information to the UE or transmit policy information to the UE when establishing a new IPsec SA connection, in order to inform the UE that it also needs to perform L4S / ECN operation.

[0099] FIGS. 4A and 4B illustrate an operation of transmitting ECN capability information of an IPsec SA to an SMF during a 5GC registration and PDU session connection procedure via a non-trusted non-3GPP access according to an embodiment of the disclosure.

[0100] In operation 401, the UE can send a request message for establishing N3WIF and IPsec SA connection and 5GC registration. The UE can receive information containing information about N3WIF and related IP address, etc. based on information received from the untrusted non-3GPP access network. Thereafter, the UE can select N3IWF based on information received from the untrusted non-3GPP access network, and can acquire IP address information of the selected N3IWF. The UE can initiate IKE initial exchange to configure IPsec security association (SA) with the selected N3IWF. All subsequent IKE messages can be encrypted and integrity protected using the IKE SA configured in this operation. The UE can send an IKE_AUTH request message to initiate IKE_AUTH exchange. The N3IWF can respond with an IKE_AUTH response message containing an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet can inform the UE to start an EAP-5G session. The UE can send an IKE_AUTH request containing an EAP-Response / 5G-NAS packet containing Access Network Parameters (AN Parameters) and a Registration Request message. The AN Parameters can contain information used by the N3IWF to select an AMF in the 5G core network. The information can include a GUAMI, a selected PLMN ID, a requested NSSAI, an establishment cause, etc. The establishment cause can provide a reason for requesting a signaling connection with the 5GC. Whether the UE includes the requested NSSAI as part of the AN Parameters and the method of including the requested NSSAI can differ according to the value of the Access Stratum Connection Establishment NSSAI Include Mode parameter. The Registration Request can contain an indication that the UE supports N3IWF selection based on slices that the UE intends to use via the untrusted non-3GPP access. The N3IWF can select an AMF based on the received AN Parameters and local policy. Thereafter, the N3IWF can transfer the Registration Request received from the UE to the selected AMF via N2 messages. The selected AMF can determine to send a NAS Identity Request message to the UE to request a SUCI. This NAS message and all subsequent NAS messages can be protected in an EAP / 5G-NAS packet and sent to the UE. The AMF can determine to authenticate the UE by using an AUSF. The AMF can send a NAS Security Mode Command to the UE to activate NAS security. The N3IWF, having received the NAS Security Mode Command message, can include it in an EAP / 5G-NAS packet and send it to the UE. The UE can complete the EAP-AKA' authentication, generate a NAS security context and N3IWF keys, and send an EAP / 5G-NAS packet containing a NAS Security Mode Complete message. The N3IWF can transfer the NAS Security Mode Complete message to the AMF.When receiving the NAS security mode complete, the AMF can send the NGAP initial context setup request message containing the N3IWF key to the N3IWF. This can trigger the N3IWF to send the EAP-Success to the UE to complete the EAP-5G session and prevent further exchange of EAP-5G packets. The IPsec SA between the UE and the N3IWF can be established using the common N3IWF key generated by the UE and received by the N3IWF. After the signaling IPsec SA is established, the N3IWF can send the NGAP initial context setup response to the AMF (operation 402) to inform that the UE context containing AN security has been generated. The signaling IPsec SA needs to be configured to operate in tunnel mode and the N3IWF can assign an “internal” IP address to the UE. All subsequent NAS messages exchanged between the UE and the N3IWF can be sent through the signaling IPsec SA and transported through TCP / IP. The UE can send the NAS messages in TCP / IP packets with source address as the UE’s “internal” IP address and destination address as the NAS IP ADDRESS. Similarly, the N3IWF can also send the NAS messages in TCP / IP packets with source address as the NAS IP ADDRESS and destination address as the UE’s “internal” IP address. The TCP connection for reliable NAS transport between the UE and the N3IWF can be started immediately by the UE after the signaling IPsec SA is configured. The AMF can determine the requested NSSAI allowed by the subscribed S-NSSAI. The AMF can send the NAS registration accept message through the N2 message to be sent to the N3IWF. The N2 message can contain the allowed NSSAI for the access type of the UE. The allowed NSSAI can be part of the selected slice supported by the N3IWF. The N3IWF can transport the NAS registration accept message to the UE through the signaling IPsec SA.

[0101] In operation 402, when the N3IWF is able to learn whether the IPsec SA supports ECN / L4S in the IPsec SA establishment procedure, the N3IWF can include the ECN / L4S support indicator information in the NGAP initial context setup response message and transport it to the AMF.

[0102] In operation 403, the UE can transmit an N1 SM container and similar information including S-NSSAI, UE requested DNN, PDU session ID, request type, old PDU session ID, and / or PDU session establishment request to the AMF by using a NAS message. The PDU session establishment request can contain a PDU session ID, requested PDU session type, requested SSC mode, 5GSM capability, PCO, SM PDU DN request container, and / or L4S support indication or IPsec SA indication information supporting ECN. If the N3IWF has transmitted the ECN or L4S support indication information to the AMF during the 5GC registration procedure in operation 402, the N3IWF can not contain separate ECN or L4S support indication information in operation 403.

[0103] In operations 404 and 405, the AMF can select an SMF and transmit a PDU session related session management context generation request message (Nsmf_PDUSession_CreateSMContext Request) containing L4S support indication, IPsec SA indication information supporting ECN, etc. to the SMF.

[0104] In operation 406, based on the PDU session related session management context generation request message containing L4S support indication or IPsec SA indication information supporting ECN received from the AMF in operation 405, the SMF can generate an SM context, and can transmit an SM context ID to the AMF through a PDU session related session management context generation request response (Nsmf_PDUSession_CreateSMContext Request Response) message.

[0105] In operation 407, the SMF can select a PCF through a PCF selection procedure based on information such as SUPI, etc.

[0106] In operations 408 to 410, the SMF can receive PDU session related policy information (Npcf_SMPolicyControl_Create Response) from the PCF. According to network operator configuration, etc., the policy information transmitted from the PCF to the SMF can contain QoS information containing L4S support indication information within the corresponding PDU session.

[0107] In operation 411, the SMF can perform a UPF selection operation based on the policy information received from the PCF. If there is information on QoS supporting the L4S service in the policy information received from the PCF, the SMF can select a UPF operation for L4S service support, include the operation information as an N4 rule in an N4 session establishment request message, and transmit the message. For example, when the N3IWF is unable to directly mark congestion information in the IP header but is able to transmit the information through a GTP-U extension header, the SMF can include a QoS monitoring operation-related requirement for receiving congestion information in the N4 rule and transfer it to the UPF. Also, when the N3IWF is unable to mark congestion information in the IP header, the SMF can select a UPF that supports this function.

[0108] In operations 412 and 413, based on the determination result of the SMF in operation 411, the N4 rule including the packet detection rule of the UPF, the operation of the UPF to mark congestion information in the IP header, the operation of receiving congestion information through a GTP-U extension header through QoS monitoring, etc. can be included in the N4 session establishment request message and then transmitted to the UPF. Thereafter, the UPF can transmit an N4 session establishment request response message including CN tunnel information, etc. to the SMF.

[0109] In operation 414, the SMF can transfer N2 SM information including L4S service support QoS information and L4S support indication information to the AMF. If the SMF identifies that the N3IWF does not support the operation of directly marking congestion information in the IP header when generating information for selecting the UPF in operation 411, the SMF can include L4S support indication and congestion control information transmission request information through a GTP-U extension header in the N2 SM information and transfer it to the AMF through a Namf_Communication_N1N2MessageTransfer message.

[0110] In operation 415, the AMF can transfer information such as a PDU session establishment-related QoS profile and related QFI, a PDU session ID, a PDU session establishment acceptance, and / or an L4S support indicator to the N3IWF through an N2 PDU session request message.

[0111] In operation 416, the N3IWF can determine the number of IPsec sub-SAs between the UE and the N3IWF based on the information received from the AMF. If there is a QoS flow requiring L4S service support among the PDU session establishment-related information received from the AMF, the N3IWF can determine to generate an IPsec sub-SA by considering the QoS flow requiring L4S service support. Due to security reasons, the N3IWF can not provide a service using ECN in a service using non-3GPP access according to the selection of the UE or the service provider.

[0112] For example, the N3IWF can receive information from the AMF indicating that there are four general QoS flows and one QoS flow requiring the provision of L4S service. Based on this information, the N3IWF can determine that the four general QoS flows use one IPsec SA as IPsec sub-SA #1 and the one QoS flow requiring the provision of L4S service uses a separate IPsec SA tunnel as IPsec sub-SA #2. In this case, the N3IWF can determine the connection of at least two IPsec sub-SAs including an IPsec sub-SA for transmitting a general QoS flow connected to the same UE, an IPsec sub-SA for transmitting a QoS flow supporting L4S service via ECN marking, etc.

[0113] In operations 417a and 417b, if the N3IWF has determined to generate two IPsec sub-SAs, the N3IWF can transmit one or more QFIs, DSCP values, additional QoS information, etc. of the IPsec sub-SA #1 to the UE to perform the first IPsec SA establishment operation.

[0114] Thereafter, in operations 417c and 417d, the N3IWF can transmit one or more QFIs, DSCP values, additional QoS information, etc. to the UE for additional IPsec sub-connection and can establish an additional IPsec SA with the UE. If the additional QoS flow associated with the IPsec SA is a QoS flow supporting L4S service, the N3IWF can include information such as an L4S support indication in the additional QoS information and transmit the same to the UE to deliver operation request information for supporting L4S service.

[0115] In operation 418, after all IPsec sub-SAs are configured, the N3IWF can deliver the PDU session establishment approval message received in operation 415 to the UE through the signaling IPsec SA.

[0116] In operation 419, the N3IWF can transmit a PDU session response message including N2 SM information including AN tunnel information to the AMF.

[0117] In operations 420 to 423, the AMF can transfer information containing the SM context ID and N2 SM information received from the N3IWF to the SMF through a PDU session related SM context update (Nsmf_PDUSession_UpdateSMContext Request) message. The SMF can transfer AN tunnel information to the UPF through an N4 session modification procedure. Thereafter, the UPF can transfer an N4 session change response message to the SMF, and the SMF can send a response message to the SM context update request to the AMF.

[0118] FIG. 5A is a flowchart illustrating an operation and method for updating a QoS flow for L4S support by using a PDU session modification procedure when L4S service support request information is received from an AF in a non-3GPP access environment according to an embodiment of the disclosure.

[0119] In operation 500, the UE can send a request message for establishing N3WIF and IPsec SA connection and 5GC registration. The UE can receive information containing information about N3WIF and related IP address, etc. based on information received from the untrusted non-3GPP access network. Thereafter, the UE can select N3IWF based on information received from the untrusted non-3GPP access network, and can obtain IP address information of the selected N3IWF. The UE can initiate IKE initial exchange to configure IPsec security association (SA) with the selected N3IWF. All subsequent IKE messages can be encrypted and integrity protected using the IKE SA configured in this operation. The UE can send an IKE_AUTH request message to initiate IKE_AUTH exchange. The N3IWF can respond with an IKE_AUTH response message containing an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet can inform the UE to start an EAP-5G session. The UE can send an IKE_AUTH request containing an EAP-Response / 5G-NAS packet containing Access Network Parameters (AN Parameters) and a Registration Request message. The AN Parameters can contain information used by the N3IWF to select an AMF in the 5G Core Network. The information can include a GUAMI, a selected PLMN ID, a requested NSSAI, an establishment cause, etc. The establishment cause can provide a reason for requesting a signaling connection with the 5GC. Whether the UE includes the requested NSSAI as part of the AN Parameters and the method of including the requested NSSAI can differ depending on the value of the Access Stratum Connection Establishment NSSAI Include Mode parameter. The Registration Request can contain an indication to support N3IWF selection by the UE based on slices that the UE intends to use via the untrusted non-3GPP access. The N3IWF can select an AMF based on the received AN Parameters and local policy. Thereafter, the N3IWF can transfer the Registration Request received from the UE to the selected AMF via N2 messages. The selected AMF can determine to send a NAS Identity Request message to the UE to request a SUCI. This NAS message and all subsequent NAS messages can be protected in an EAP / 5G-NAS packet and sent to the UE. The AMF can determine to authenticate the UE by using an AUSF. The AMF can send a NAS Security Mode Command to the UE to activate NAS security. The N3IWF, having received the NAS Security Mode Command message, can include it in an EAP / 5G-NAS packet and send it to the UE. The UE can complete the EAP-AKA' authentication, generate a NAS security context and N3IWF keys, and send an EAP / 5G-NAS packet containing a NAS Security Mode Complete message. The N3IWF can transfer the NAS Security Mode Complete message to the AMF.When receiving the NAS security mode complete, the AMF can send the NGAP initial context setup request message containing the N3IWF key to the N3IWF. This can trigger the N3IWF to send the EAP-Success to the UE to complete the EAP-5G session and block further exchange of EAP-5G packets. The IPsec SA between the UE and the N3IWF can be established using the common N3IWF key generated by the UE and received by the N3IWF. After the signaling IPsec SA is established, the N3IWF can send the NGAP initial context setup response to the AMF to inform that the UE context containing the AN security has been generated. The signaling IPsec SA needs to be configured to operate in tunnel mode, and the N3IWF can assign an “internal” IP address to the UE. All subsequent NAS messages exchanged between the UE and the N3IWF can be sent through the signaling IPsec SA and transported through TCP / IP. The UE can send the NAS messages in TCP / IP packets with the source address as the UE’s “internal” IP address and the destination address as the NAS IP ADDRESS. Similarly, the N3IWF can also send the NAS messages in TCP / IP packets with the source address as the NAS IP ADDRESS and the destination address as the UE’s “internal” IP address. The TCP connection for reliable NAS transport between the UE and the N3IWF can be started immediately by the UE after the signaling IPsec SA is configured. The AMF can determine the requested NSSAI allowed by the subscribed S-NSSAI. The AMF can send the NAS registration accept message through the N2 message to be sent to the N3IWF. The N2 message can contain the allowed NSSAI for the access type of the UE. The allowed NSSAI can be part of the selected slice supported by the N3IWF. The N3IWF can transport the NAS registration accept message to the UE through the signaling IPsec SA. Operation 500 can correspond to operation 401 of FIG. 4A.

[0120] In operation 501, the AF can determine a L4S service support request in a non-3GPP access based service.

[0121] In operation 502, the AF can transmit L4S service support request information (such as L4S support indication for non-3GPP access) to the NEF based on the L4S support indication information through an AFsessionWithQoS update request message.

[0122] In operation 503, after receiving the request information including the L4S support request, the congestion report request, etc. from the AF in operation 502 through the policy approval request procedure of the PCF, the NEF can perform the following operations.

[0123] The NEF can identify the subscriber information related to the AF request to the UDM. When the subscriber information included in the AF request is a generic public subscriber identifier (GPSI), the NEF can request to replace it with a subscriber permanent identifier (SUPI) for referring to the subscriber within the 5GC network. When the subscriber information included in the AF request is the subscriber group information, the NEF can request to replace the subscriber group information within the 5GC network with a group identifier within the 5G network. When the subscriber information included in the AF request is the subscriber group information and can be replaced with a list of multiple subscriber information, the NEF can request such replacement by the UDM entity.

[0124] The NEF can perform an approval request of the AF request to the UDM entity in order to identify from the UDM entity whether the AF identifier, information about the service requested by the AF, and the subscriber information are in line with the subscription policy of the service provider.

[0125] In operation 504, the PCF can determine to update the PCC rule containing the L4S / ECN congestion control information based on the request received from the AF. When the PCF determines to provide the L4S / ECN service according to the service provider policy, the PCF can perform an SM policy control update notification procedure. The PCF can include the L4S / ECN related policy and charging control (PCC) rule in an SM policy control update notification request message and transmit it to the SMF. The L4S / ECN related PCC rule can contain the following information. Service data flow (SDF) information is information that can identify a service flow to which the L4S / ECN is to be applied. The SDF information can be expressed as a service data flow template. The SDF information can be expressed by an IP source / destination address or range and a source / destination port number or range. Alternatively, the SDF information can be expressed as a value of a fully qualified domain name (FQDN) or an FQDN range, for example, an FQDN range expressed in a regular expression format. L4S / ECN marking related information can include an L4S / ECN marking policy and an L4S / ECN congestion experience bit marking policy. The L4S / ECN marking policy can contain the following policies: L4S / ECN marking support including whether to support the L4S / ECN marking, an L4S / ECN marking version, and information for using a control plane.

[0126] In operation 505, upon receiving the updated PCC rule containing the L4S support indication information, the SMF can perform a determination regarding operations of L4S support and select an NF providing the support. To perform the determination of L4S support, it can be assumed that the SMF has received whether an IPsec SA supports ECN / L4S and a type of a congestion information marking scheme supported by N3IWF during a PDU session establishment procedure, or that the SMF is aware of the information according to a network operator's configuration. When there is information regarding QoS supporting an L4S service in policy information received from a PCF, the SMF can select a UPF operation for supporting an L4S service, include corresponding operation information as an N4 rule in an N4 session establishment request message, and transmit the message. For example, when N3IWF is unable to directly mark congestion information in an IP header but is able to transmit the information through a GTP-U extension header, the SMF can include a QoS monitoring operation-related requirement for receiving congestion information in an N4 rule and transfer the same to a UPF. Also, when N3IWF is unable to mark congestion information in an IP header, the SMF can select a UPF supporting this function. The SMF can perform a UPF selection operation based on policy information received from a PCF. The SMF can determine whether to accept a request for L4S service support for a specific QoS flow based on a preconfigured policy or information transferred during a PDU session establishment procedure. The SMF can receive information whether an IPsec SA supports ECN from an AMF or a UE during a PDU session establishment procedure, and can determine whether to accept a request for L4S service support for a specific QoS flow of a UE transferred from an AF based on the information. Also, the SMF can determine whether to accept a request for L4S service support for a specific QoS flow based on whether N3IWF satisfies the following conditions. In a case where N3IWF is able to directly mark information regarding a congestion situation in a ToS field in an IP header, or in a case where N3IWF is able to mark congestion information in a GTP-U extension header and transmit the same to a UPF, it can be determined that N3IWF can support an L4S service. Also, in a case of using a service via a non-3GPP access, when N3IWF supports one or more marking methods for transmitting congestion information, and an ECN / L4S service (supporting ECN) can be supported in an IPsec SA part between N3IWF and a UE, the SMF can determine whether to accept a request for an L4S service for a corresponding QoS flow using a non-3GPP access.

[0127] In operation 506, the SMF can transfer the N2 SM information including the L4S service support QoS information and the L4S support indication information to the AMF. If the SMF identifies that the N3IWF does not support the operation of directly marking congestion information in the IP header when generating information for selecting the UPF in operation 505, the SMF can include the L4S support indication and the congestion control information transmission request information through the GTP-U extension header in the N2 SM information and transfer it to the AMF through the Namf_Communication_N1N2MessageTransfer message.

[0128] In operation 507, the AMF can transfer information such as the PDU session establishment related QoS profile and related QFI, PDU session ID, PDU session establishment acceptance, and / or L4S support indicator to the N3IWF through the N2 PDU session request message.

[0129] In operations 508a and 508b, based on the determination result of the SMF in operation 505, the SMF can include the N4 rule including the packet detection rule of the UPF, the operation of marking the congestion information in the IP header by the UPF, the operation of receiving the congestion information through the GTP-U extension header through the QoS monitoring, etc. in the N4 session establishment request message and transmit it to the UPF. Thereafter, the UPF can transmit the N4 session establishment request response message including the CN tunnel information, etc. to the SMF.

[0130] In operation 509, the N3IWF can determine the update of the IPsec sub-SAs between the UE and the N3IWF based on the information received from the AMF. If the existing QoS flow is being transferred through the IPsec SA that does not support ECN / L4S and the L4S service support request is received by the N3IWF, the N3IWF can determine to establish a new IPsec SA connection supporting ECN / L4S for the corresponding QoS flow. For example, when five QoS flows not supporting the L4S service are being transmitted from the N3IWF to one IPsec SA #1, one of the QoS flows can receive a request for providing the L4S service. The N3IWF can determine to generate IPsec SA #2 for supporting the L4S service for the QoS flow and update the QoS flow information for requesting the L4S service support from the existing IPsec SA #1 to the IPsec SA #2. To this end, the N3WIF can transmit an information request message including the QFI and additional QoS information related to the sub-SAs to update the QoS flow and sub-SA mapping information.

[0131] In operation 510, when the N3IWF determines to generate a new IPsec child SA, the N3IWF can transmit information of the QFI, PDU session ID, etc. of the IPsec child SA to the UE and perform a new IPsec SA establishment operation in order to support the L4S service.

[0132] In operation 511, when a new IPsec child SA supporting the L4S service is configured based on the N2 session request, the N3IWF can transfer success or failure of the request to the AMF.

[0133] In operations 512 to 513, the AMF can transfer the N2 SM information (including whether the request information for supporting the L4S service has been successfully processed) to the SMF through a PDU session related SM context update (Nsmf_PDUSession_UpdateSMContext request) message. If QoS flow information, etc. has been updated, the SMF can transfer the information to the UPF through an N4 session modification request operation.

[0134] In operation 514, a non-3GPP access point (e.g., Wi-Fi) can be added between the UE and the N3IWF. The UE can transmit and receive data to and from the N3IWF through the non-3GPP access point, and in this case, according to the structure of IPsec, the IP header and the payload transferred to the existing N3IWF can be defined as an inner IP packet. In the IPsec tunnel mode, an additional outer IP packet can be defined for including the corresponding inner IP packet in the payload. That is, in the IPsec SA part, the outer IP packet can be generated and transferred to the UE through the non-3GPP access point.

[0135] In operation 514a, when downlink data is transferred to the N3IWF, the N3IWF can perform an operation of being transferred through the SMF. In the case of transferring downlink data from the UPF, if a congestion situation occurs in the N3IWF or congestion occurs before the N3IWF, the N3IWF can mark the corresponding ECN bit in the inner IP header with CE or can receive an IP packet having the ECN bit marked with CE and transmit it to the UE as an inner packet. In addition, when congestion occurs in the non-3GPP access network, the N3IWF can mark the corresponding congestion information in the ECN bit in the outer packet header and transfer it to the UE.

[0136] In operation 514b, the UE that has received the downlink data can distinguish the congestion information as to whether the corresponding congestion situation has occurred in the non-3GPP access part or whether the congestion situation has occurred inside the 5GC with respect to the part in which the congestion situation has occurred, and can generate and transmit the congestion information to the AS to perform the queue management suitable for each situation.

[0137] In operation 515, when the congestion situation of the non-3GPP access part is marked via the external header during the uplink data transmission, the N3IWF can determine whether to generate the congestion information based on the ECN bit information of the external header for the information generated in the non-3GPP access network, and can transmit the scheme of marking and transmitting the congestion information based on the determination result of the SMF in operation 505.

[0138] FIG. 5B is a flowchart illustrating an operation and method of updating a QoS flow for L4S support by using a PDU session modification procedure when L4S service support request information is received from an AF in a non-3GPP access environment according to an embodiment of the disclosure.

[0139] In operation 520, the UE can send a request message for establishing N3WIF and IPsec SA connection and 5GC registration. The UE can receive information containing information about N3WIF and related IP address, etc. based on information received from the untrusted non-3GPP access network. Thereafter, the UE can select N3IWF based on information received from the untrusted non-3GPP access network, and can acquire IP address information of the selected N3IWF. The UE can initiate IKE initial exchange to configure IPsec security association (SA) with the selected N3IWF. All subsequent IKE messages can be encrypted and integrity protected by using the IKE SA configured in this operation. The UE can send an IKE_AUTH request message to initiate IKE_AUTH exchange. The N3IWF can respond with an IKE_AUTH response message containing an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet can inform the UE to start an EAP-5G session. The UE can send an IKE_AUTH request containing an EAP-Response / 5G-NAS packet containing Access Network parameters (AN parameters) and a registration request message. The AN parameters can contain information used by the N3IWF to select an AMF in the 5G core network. The information can include a GUAMI, a selected PLMN ID, a requested NSSAI, an establishment cause, etc. The establishment cause can provide a reason for requesting a signaling connection with the 5GC. Whether the UE includes the requested NSSAI as part of the AN parameters and the method of including the requested NSSAI can differ according to the value of the Access Stratum Connection Establishment NSSAI inclusion mode parameter. The registration request can contain an indication to support N3IWF selection by the UE based on a slice that the UE intends to use via the untrusted non-3GPP access. The N3IWF can select an AMF based on the received AN parameters and local policy. Thereafter, the N3IWF can transfer the registration request received from the UE to the selected AMF via a N2 message. The selected AMF can determine to send a NAS identity request message to the UE to request a SUCI. This NAS message and all subsequent NAS messages can be protected in an EAP / 5G-NAS packet and sent to the UE. The AMF can determine to authenticate the UE by using an AUSF. The AMF can send a NAS security mode command to the UE to activate NAS security. The N3IWF that has received the NAS security mode command message can include it in an EAP / 5G-NAS packet and send it to the UE. The UE can complete the EAP-AKA' authentication, generate a NAS security context and N3IWF keys, and send an EAP / 5G-NAS packet containing a NAS security mode complete message. The N3IWF can transfer the NAS security mode complete message to the AMF.When receiving the NAS security mode complete, the AMF can send the NGAP initial context setup request message containing the N3IWF key to the N3IWF. This can trigger the N3IWF to send the EAP-Success to the UE to complete the EAP-5G session and block further exchange of EAP-5G packets. The IPsec SA between the UE and the N3IWF can be established using the common N3IWF key generated by the UE and received by the N3IWF. After the signaling IPsec SA is established, the N3IWF can send the NGAP initial context setup response to the AMF to inform that the UE context containing the AN security has been generated. The signaling IPsec SA needs to be configured to operate in tunnel mode, and the N3IWF can assign an “internal” IP address to the UE. All subsequent NAS messages exchanged between the UE and the N3IWF can be sent through the signaling IPsec SA and transported through TCP / IP. The UE can send the NAS messages in TCP / IP packets with the source address as the UE’s “internal” IP address and the destination address as the NAS_IP_ADDRESS. Similarly, the N3IWF can also send the NAS messages in TCP / IP packets with the source address as the NAS_IP_ADDRESS and the destination address as the UE’s “internal” IP address. The TCP connection for reliable NAS transport between the UE and the N3IWF can be started immediately by the UE after the signaling IPsec SA is configured. The AMF can determine the requested NSSAI allowed by the subscribed S-NSSAI. The AMF can send the NAS registration accept message through the N2 message to be sent to the N3IWF. The N2 message can contain the allowed NSSAI for the access type of the UE. The allowed NSSAI can be part of the selected slice supported by the N3IWF. The N3IWF can transport the NAS registration accept message to the UE through the signaling IPsec SA. Operation 520 can correspond to operation 401 of FIG. 4A.

[0140] In operation 521, the AF can determine the L4S service support request in the non-3GPP access based service.

[0141] In operation 522, the AF can transmit the L4S service support request information (such as L4S support indication for non-3GPP access) to the NEF through the AFsessionWithQoS update request message based on the L4S support indication information.

[0142] In operation 503, after receiving the request information including the L4S support request, the congestion report request, etc. from the AF in the policy approval request procedure through the PCF in operation 522, the NEF can perform the following operations.

[0143] The NEF can identify the subscriber information related to the AF request to the UDM. When the subscriber information included in the AF request is a generic public subscriber identifier (GPSI), the NEF can request to replace it with a subscriber permanent identifier (SUPI) for referring to the subscriber within the 5GC network. When the subscriber information included in the AF request is the subscriber group information, the NEF can request to replace the subscriber group information within the 5GC network with a group identifier within the 5G network. When the subscriber information included in the AF request is the subscriber group information and can be replaced with a list of multiple subscriber information, the NEF can request such replacement by the UDM entity.

[0144] The NEF can perform an approval request of the AF request to the UDM entity in order to identify from the UDM entity whether the AF identifier, information about the service requested by the AF, and the subscriber information are in line with the subscription policy of the service provider.

[0145] In operation 524, the PCF can determine to update the PCC rule containing the L4S / ECN congestion control information based on the request received from the AF. When the PCF determines to provide the L4S / ECN service according to the service provider policy, the PCF can perform an SM policy control update notification procedure. The PCF can include the L4S / ECN related policy and charging control (PCC) rule in an SM policy control update notification request message and transmit it to the SMF. The L4S / ECN related PCC rule can contain the following information. Service data flow (SDF) information is information that can identify a service flow to which the L4S / ECN is to be applied. The SDF information can be expressed as a service data flow template. The SDF information can be expressed by an IP source / destination address or range and a source / destination port number or range. Alternatively, the SDF information can be expressed as a value of a fully qualified domain name (FQDN) or a range of FQDNs, for example, a range of FQDNs expressed in a regular expression format. L4S / ECN marking related information can include L4S / ECN marking policy and L4S / ECN congestion experience bit marking policy. The L4S / ECN marking policy can contain the following policies: L4S / ECN marking support including whether to support L4S / ECN marking, L4S / ECN marking version, and information for using a control plane.

[0146] In operation 525, upon receiving the updated PCC rule containing the L4S support indication information, the SMF can perform a determination on the operation of L4S support and select the NF providing the support. Specifically, the SMF can perform the selection of the NF supporting the ECN marking of L4S according to the policy of the network service provider, and in this case, the selected NF can be the NG-RAN or the UPF. According to the policy of the network service provider, when the SMF selects the UPF as the NF entity for supporting the L4S service, the SMF can include and transmit the ECN marking operation information as the N4 rule in the N4 session establishment request message. For example, when the N3IWF is unable to directly perform the congestion information marking in the IP header but is able to transmit the congestion information to the UPF through the GTP-U extension header, the SMF can include the QoS monitoring operation-related requirement for the reception of the congestion information in the N4 rule and transfer it to the UPF. The SMF can determine whether to accept the L4S service support request for a specific QoS flow based on a preconfigured policy or information transferred from the NG-RAN in the PDU session establishment procedure. The SMF can perform the selection of the NF performing the ECN marking operation of L4S based on the updated PCC rule containing the L4S indicator information received from the PCF. Thereafter, during the PDU session establishment or modification procedure, the SMF can transfer the N2 information (including the ECN marking of the L4S indicator or the QoS monitoring configuration of the congestion information) to the N3IWF via the AMF. If the N3IWF supports the ECN marking of the L4S indicator operation, the N3IWF can transfer the information on the established QoS flow state (active) for the ECN marking of L4S to the SMF through the AMF based on the information received from the SMF. If the N3IWF does not support the ECN marking of the L4S indicator operation, the N3IWF can transfer the information on the established QoS flow state (inactive) for the ECN marking of L4S to the SMF through the AMF. Furthermore, when the N3IWF supports the QoS monitoring configuration of the congestion information operation, the N3IWF can transfer the information on the established QoS flow state (active) for the QoS monitoring configuration of the congestion information to the SMF through the AMF based on the information received from the SMF. If the N3IWF does not support the congestion information QoS monitoring configuration, the N3IWF can transfer the information on the established QoS flow state (inactive) for the QoS monitoring configuration of the congestion information to the SMF through the AMF. If the N3IWF does not support the QoS monitoring configuration of the congestion information and the ECN marking of L4S, the SMF can determine that the QoS flow using the N3IWF does not support the ECN marking operation in consideration of L4S.The SMF can determine whether to accept the request for L4S service support for a specific QoS flow of the UE transmitted from the AF based on L4S support status information (e.g., congestion information QoS monitoring configuration, established QoS flow status (active / inactive), or L4S ECN marking established QoS flow status (active / inactive)) transmitted from the N3IWF or the UPF.

[0147] In operation 526, when the SMF has selected to use the ECN marking operation of the NG-RAN in order to perform the ECN marking operation for supporting the L4S service according to the NF selection result, the SMF can transmit N2 SM information containing QoS flow information for supporting the L4S service and L4S support indicator information to the AMF. When the SMF selects the ECN marking operation through operation 525 using the UPF or when the SMF receives information indicating that the operation of directly marking congestion information in the IP header is not supported from the N3IWF, the SMF can include QoS flow information for supporting the L4S service and configuration information for congestion information QoS monitoring through the GTP-U extension header in the N2 SM information, and transmit it to the AMF through the Namf_Communication_N1N2MessageTransfer message.

[0148] In operation 527, the AMF can transmit information such as PDU session establishment related QoS profile and related QFI, PDU session ID, PDU session establishment accept, and / or L4S support indicator to the N3IWF through the N2 PDU session request message.

[0149] In operations 528a and 528b, based on the determination result of the SMF in operation 525, the SMF can include N4 rules (containing packet detection rules of the UPF) in the N4 session establishment request message and transmit it to the UPF. The UPF can transmit the N4 session establishment request response message containing CN tunnel information, etc. to the SMF. When the SMF determines L4S service support using the UPF in operation 525, the SMF can transmit N4 rules containing the ECN marking operation, QoS monitoring configuration information for receiving ECN marking congestion information from the NG-RAN, etc. to the UPF.

[0150] In operation 529a, the N3IWF can select an L4S support operation that the N3IWF can support according to the capability of the N3IWF and / or the L4S support operation request message requested by the SMF. When the SMF determines to perform the ECN marking operation for supporting the L4S service using the NG-RAN in operation 525 and the N2 SM information transmitted to the N3IWF through operation 526 and operation 527 contains only the LS4 indicator of the ECN marking, the N3IWF can determine to perform operation 529b according to whether the operation is accepted.

[0151] In an embodiment, when the SMF determines to perform the ECN marking operation for supporting the L4S service using the UPF in operation 525 and the N2 SM information transmitted to the N3IWF through operation 526 and operation 527 contains the QoS monitoring configuration of the congestion information, the N3IWF can determine to perform operation 529b according to whether the operation is accepted. When the N3IWF does not support both the congestion information monitoring operation and the ECN marking operation for supporting the L4S service, operation 529b and operation 530 can be omitted. Thereafter, the N3IWF can transmit to the SMF that the corresponding QoS flow does not support the L4S service through operation 531 and operation 532.

[0152] In operation 529b, the N3IWF can determine to update the IPsec sub-SAs between the UE and the N3IWF based on the information received from the AMF. In the case where the existing QoS flow is being transmitted through an IPsec SA that does not support ECN / L4S, when the N3IWF receives a request for L4S service support, a new IPsec SA connection for supporting ECN / L4S can be determined for the QoS flow. For example, when five QoS flows that do not support the L4S service are being transmitted from the N3IWF to one IPsec SA #1, one of the QoS flows can receive a request for providing the L4S service. The N3IWF can determine to generate an IPsec SA #2 for supporting the L4S service for the QoS flow and update the QoS flow information for requesting the L4S service support from the existing IPsec SA #1 to the IPsec SA #2. To this end, the N3WIF can transmit an information request message containing the QFI and additional QoS information related to the sub-SAs to update the QoS flow and sub-SAs mapping information.

[0153] In operation 530, when the N3IWF determines to generate a new IPsec child SA, the N3IWF can transmit information of QFI, PDU session ID, etc. of the IPsec child SA to the UE and perform a new IPsec SA establishment operation in order to support the L4S service. Further, when the N3IWF is able to support the operation of the L4S service through operation 529a, but the N3IWF does not have information on whether the UE and the non-3GPP access network support the L4S service, the N3IWF can transmit information for identifying whether the UE and the non-3GPP access network support the L4S service to the UE. The information for identifying whether the L4S service is supported, which is transmitted from the N3IWF to the UE, can include an ECN mark of an L4S indicator, etc. When the UE has received the L4S support indicator of a specific QoS flow from the N3IWF, the UE can check whether the L4S is supported in a part between the UE and the non-3GPP access or whether the IPsec child SA supporting the L4S has been generated, and when the UE is unable to determine whether the L4S is individually supported, the UE can perform an operation for checking whether the L4S is supported in an uplink packet.

[0154] In operation 531 (531a and / or 531b), when a new IPsec child SA supporting the L4S service is configured based on the N2 session request, the N3IWF can transmit whether the N3IWF operation request for supporting the L4S service is accepted or supported to the AMF. The N3IWF can include, in the N2 SM information, the established QoS flow state (active / inactive) of the QoS monitoring configuration of the congestion information or the established QoS flow state (active / inactive) of the ECN mark of the L4S information whether the SMF accepts and supports the N3IWF operation request for supporting the L4S service, and can transmit the same to the AMF. Through operation 530, when the UE or the non-3GPP access network does not support the generation of the IPsec child SA supporting the L4S service or when at least one of the UE and the non-3GPP access network does not support the L4S function, the N3IWF can transmit the N2 SM information (including information indicating that the N3IWF operation request for supporting the L4S service is rejected or not supported) (the established QoS flow state (inactive) of the QoS monitoring configuration of the congestion information or the established QoS flow state (inactive) of the ECN mark of the L4S) to the AMF.

[0155] In operations 532 (532a and / or 532b) to operation 533 (533a and / or 533b), the AMF can transfer N2 SM information (including whether the request information for L4S service support has been successfully processed) to the SMF through a PDU session-related SM context update (Nsmf_PDUSession_UpdateSMContext request) message. When the QoS flow information or the like in the N2 SM information is updated, the SMF can transfer the updated information to the UPF through an N4 session modification request operation. When the SMF receives information indicating that the N3IWF does not support the operation for supporting the L4S service in the N2 SM information transmitted from the NG-RAN through operation 532a, the SMF can transfer the information to the AF through the PCF. In operations 522 and 523, the L4S service-related requirement information transmitted from the AF to the PCF can include, in addition to the L4S support indication information, requirement information requesting the reporting of an event to the AF when it is determined that the L4S service is not supported. In operation 524, when the SMF receives the established QoS flow state (inactive) of the QoS monitoring configuration of the congestion information and / or the established QoS flow state (inactive) of the ECN marking of the L4S information from the N3IWF through the policy control request trigger (PCRT), and the SMF has received that the L4S service support for the corresponding QoS flow is not available, the PCF can request the SMF to report the same to the PCF.

[0156] In operation 534 (534a and / or 534b), if the SMF receives information indicating that the L4S service for the corresponding QoS flow is not supported from the N3IWF, the SMF can transfer the information to the PCF through an event report, thereby indicating that the L4S service for the corresponding QoS flow is not supported. Based on the event report message received from the SMF, the PCF can transfer an event report message indicating that the L4S service for a specific QoS flow is not supported to the AF according to the AF request.

[0157] In operation 535, a non-3GPP access point (e.g., Wi-Fi) can be added between the UE and the N3IWF. The UE can transmit and receive data to and from the N3IWF through the non-3GPP access point, and in this case, according to the structure of IPsec, an IP header and a payload transferred to the existing N3IWF can be defined as an inner IP packet. In the IPsec tunnel mode, an additional outer IP packet can be defined for including the corresponding inner IP packet in the payload. That is, in the IPsec SA part, the outer IP packet can be generated and transferred to the UE through the non-3GPP access point.

[0158] In operation 535a, when the downlink data is transferred to the N3IWF, the N3IWF can perform an operation transferred through the SMF. In the case of transferring the downlink data from the UPF, if a congestion situation occurs in the N3IWF or congestion occurs before the N3IWF, the N3IWF can mark the corresponding ECN bits in the inner IP header with CE or can receive the IP packet having the ECN bits marked with CE and transmit it to the UE as an inner packet. In addition, when congestion occurs in the non-3GPP access network, the N3IWF can mark the corresponding congestion information in the ECN bits in the outer packet header and transfer it to the UE.

[0159] In operation 535b, the UE that has received the downlink data can distinguish the congestion information as to whether the corresponding congestion situation has occurred in the non-3GPP access part or the congestion situation has occurred inside the 5GC and can generate and transfer the congestion information to the AF to perform queue management suitable for each case.

[0160] In operation 536, when the congestion situation of the non-3GPP access part is marked via the outer header during uplink data transmission, the N3IWF can determine whether to generate congestion information for the information generated in the non-3GPP access network based on the ECN bit information of the outer header. For the congestion information marking scheme, the N3IWF can mark based on the details determined by the SMF in operation 525. In addition, based on the details determined by the SMF in operation 525, the N3IWF can transmit the congestion information to the UPF, and the UPF can mark.

[0161] Figure 6 An example of a functional structure of a UE 600 according to an embodiment of the disclosure is illustrated. As used herein, terms such as "…unit" and "…er" refer to an entity configured to process at least one function or operation, and can be implemented as hardware, software, or a combination of hardware and software. Figure 6 The UE in the above-described embodiment can correspond to Figure 1 to the user equipment (UE) described in FIG. 5.

[0162] Referring to Figure 6 The UE can include a communication unit 605, a storage 610, and a controller 615.

[0163] The communication unit 605 can perform a function of transmitting / receiving a signal through a radio channel. For example, the wireless communication unit 605 can perform a conversion function between a baseband signal and a bit string according to a physical layer specification of a system. For example, during data transmission, the communication unit 605 can encode and modulate a transmission bit string to generate a complex symbol. Also, during data reception, the communication unit 605 can demodulate and decode a baseband signal to recover a reception bit string. Furthermore, the communication unit 605 can up-convert a baseband signal to an RF band signal, and then transmit the converted RF band signal through an antenna, and down-convert an RF band signal received through an antenna to a baseband signal. For example, the communication unit 605 can include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, and an ADC.

[0164] Also, the communication unit 605 can include a plurality of transmission / reception paths. Furthermore, the communication unit 605 can include at least one antenna array including a plurality of antenna elements. In terms of hardware, the communication unit 605 can include a digital circuit and an analog circuit (e.g., a radio frequency integrated circuit (RFIC)). The digital circuit and the analog circuit can be implemented as a single package. Also, the communication unit 605 can include a plurality of RF chains. Furthermore, the communication unit 605 can perform beamforming.

[0165] The communication unit 605 can transmit and receive a signal as described above. Accordingly, all or a part of the communication unit 605 can be referred to as a "transmitter", a "receiver", or a "transceiver". Also, as used in the following description, the meaning of "transmission and reception performed through a radio channel" includes the meaning of the above-described processing performed by the communication unit 605.

[0166] The storage 610 can store a basic program, an application program, and data for operation of the UE, such as configuration information. The storage unit 610 can include a volatile memory, a non-volatile memory, or a combination of the volatile memory and the non-volatile memory. Also, the storage 610 can provide stored data at the request of the controller 615.

[0167] The controller 615 can control the overall operation of the UE. For example, the controller 615 can transmit and receive signals through the communication unit 605. In addition, the controller 615 records and reads data in and from the storage 610. In addition, the controller 615 can perform the functions of the protocol stack required by the communication specification. To this end, the controller 615 can include at least one processor or microprocessor, or can be a part of the processor. In addition, a part of the communication unit 605 and the controller 615 can be referred to as a communication processor (CP). According to various embodiments, the controller 615 can control to perform synchronization by using a wireless communication network. For example, the controller 615 can control the UE to perform operations according to various embodiments.

[0168] According to various embodiments of the disclosure, the UE can be configured by a mobile equipment (ME) and a universal mobile telecommunications service (UMTS) subscriber identity module (USIM). The ME can include a mobile terminal (MT) and a terminal equipment (TE). The MT can be a part that operates a radio access protocol, and the TE can be a part that operates a control function. For example, in the case of a wireless communication terminal (e.g., a mobile phone), the MT and the TE can be integrated, and in the case of a notebook computer, the MT and the TE can be separated. As used herein, the ME and the TE can be expressed as independent entities according to the operation of the respective components, but the disclosure is not limited thereto, and the ME and the TE as a whole can be expressed as a terminal (e.g., a UE), or the ME can be expressed as a terminal in describing various embodiments of the disclosure.

[0169] Figure 7 An example of a functional structure of a network entity 700 according to an embodiment of the disclosure is illustrated. Figure 7 Components of a network entity in a wireless communication system according to various embodiments of the disclosure are illustrated. As used herein, terms such as "…unit" and "…er" refer to an entity configured to process at least one function or operation, and can be implemented as hardware, software, or a combination of hardware and software. Figure 7 The network entity in Figure 1 to the network entity or network function described in FIG. 5.

[0170] Referring to Figure 7 The network entity 700 according to an embodiment of the disclosure can include a communication unit 705, a storage 710, and a controller 715.

[0171] The communication unit 705 can provide an interface for communicating with other devices in a network. That is, the communication unit 705 can convert a bitstream transmitted from a core network device to any other device into a physical signal and convert a physical signal received from any other device into a bitstream. The communication unit 705 can transmit / receive a signal. Accordingly, the communication unit 705 can be referred to as a modem, a transmitter, a receiver, or a transceiver. The communication unit 705 can be configured to enable the network entity to communicate with other devices or systems via a backhaul connection (e.g., a wired backhaul or a wireless backhaul) or via a network.

[0172] The storage 710 can store basic programs, application programs, and data for operations of the network entity, such as configuration information. The storage 710 can include a volatile memory, a non-volatile memory, or a combination of the volatile memory and the non-volatile memory. In addition, the storage 710 can provide stored data at the request of the controller 715.

[0173] The controller 715 can control overall operations of the network entity. For example, the controller 715 can transmit and receive signals through the communication unit 705. In addition, the controller 715 records and reads data in / from the storage 710. To this end, the controller 715 can include at least one processor. According to various embodiments, the controller 715 can control to perform synchronization by using a wireless communication network. For example, the controller 715 can control the network entity to perform operations according to various embodiments described below.

[0174] In the description of the embodiments of the disclosure, terms for identifying access nodes, terms for referring to network entities, terms for referring to messages, terms for referring to interfaces between network entities, terms for referring to various identification information, and the like are used for convenience and illustration. Accordingly, the disclosure is not limited to the terms used herein, and other terms referring to the subject matter having equivalent technical meanings can be used.

[0175] The method disclosed in the claims or the method according to the embodiments described in the specification of the disclosure can be implemented by hardware, software, or a combination of hardware and software.

[0176] When the method is implemented by software, a computer-readable storage medium for storing one or more programs (software modules) can be provided. The one or more programs stored in the computer-readable storage medium can be configured for execution by one or more processors within an electronic device. The one or more programs include instructions that cause the electronic device to execute the method according to the embodiments of the disclosure defined by the appended claims or disclosed herein.

[0177] These programs (software modules or software) can be stored in non-volatile memory including a random access memory and a flash memory, a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a magnetic disc storage device, a compact disc-ROM (CD-ROM), a digital versatile disc (DVD), or other type of optical storage device, or a magnetic cassette. Alternatively, some or all of them can form a memory in which a program is stored by any combination of them. In addition, a plurality of such memories can be included in the electronic device.

[0178] Further, the programs can be stored in an attachable storage device which can access the electronic device through a communication network such as the Internet, an intranet, a local area network (LAN), a wide LAN (WLAN), and a storage area network (SAN), or a combination thereof. Such a storage device can access the electronic device via an external port. In addition, a separate storage device on a communication network can access the portable electronic device.

[0179] In the above detailed embodiments of the disclosure, according to the presented detailed embodiments, the elements included in the disclosure are expressed in singular or plural. However, for the convenience of description, the singular form or the plural form is appropriately selected with respect to the presented situation, and the disclosure is not limited to the elements expressed in singular or plural. Therefore, the elements expressed in plural can also include a single element, or the elements expressed in singular can also include a plurality of elements.

[0180] Although specific embodiments have been described in the detailed description of the disclosure, various modifications and changes can be made thereto without departing from the scope of the disclosure. Therefore, the scope of the disclosure should not be defined as limited to the embodiments set forth herein, but should be defined by the appended claims and their equivalents.

Claims

1. A method performed by a non-3GPP interoperability function (N3IWF) entity in a wireless communication system, the method comprising: Session management information is received from the session management function (SMF) entity via the access and mobility management function (AMF) entity. The session management information includes an explicit congestion notification (ECN) flag indication for supporting low latency, low loss, and scalable throughput (L4S) in non-3GPP access. Determine the Internet Protocol Security (IPsec) Sub-Security Association (SA) connection that supports the Quality of Service (QoS) flow of the L4S; as well as Send a message to the terminal requesting the connection of the IPsec subSA.

2. The method of claim 1, wherein the session management information includes at least one of Protocol Data Unit (PDU) session ID, QoS Stream ID (QFI), or QoS profile.

3. The method of claim 1, wherein the message includes at least one of PDU session ID, QFI, Differentiated Services Field Code Point (DSCP) value, or additional QoS information.

4. The method of claim 1, wherein the session management information is included in the N2 PDU session request message, and The messages mentioned include the IKE CREATE CHILD SA request message.

5. The method of claim 4, further comprising sending an N2 PDU session response message to the AMF entity, the N2 PDU session response message including information regarding whether the connection of the IPsec subSA was successfully executed. The N2 PDU session response message also contains information related to the status of the QoS flow.

6. A method performed by a user equipment in a wireless communication system, the method comprising: Receive a first message from a non-3GPP interoperability function (N3IWF) entity, the first message being used to request an Internet Protocol Security (IPsec) sub-security association (SA) connection for a Quality of Service (QoS) flow that supports low latency, low loss, and scalable throughput (L4S). as well as A second message is sent to the N3IWF entity, the second message being a response to the first message.

7. The method of claim 6, wherein the first message further includes at least one of Protocol Data Unit (PDU) Session ID, QoS Stream ID (QFI), Differentiated Services Field Code Point (DSCP) value, or additional QoS information.

8. The method of claim 6, wherein the first message includes an IKE CREATE CHILD SA request message.

9. A non-3GPP interoperability function (N3IWF) entity in a wireless communication system, the N3IWF entity comprising: transceiver; as well as The controller is connected to the transceiver. The controller is configured as follows: Session management information is received from the session management function (SMF) entity via the access and mobility management function (AMF) entity. The session management information includes an explicit congestion notification (ECN) flag indication for supporting low latency, low loss, and scalable throughput (L4S) in non-3GPP access. Identify the Internet Protocol Security (IPsec) sub-security association (SA) connection that supports the Quality of Service (QoS) flow of the L4S; as well as Send a message to the terminal requesting the IPsec subSA connection.

10. The N3IWF entity as claimed in claim 9, wherein the session management information includes at least one of Protocol Data Unit (PDU) session ID, QoS Stream ID (QFI), or QoS profile.

11. The N3IWF entity as claimed in claim 9, wherein the message includes at least one of PDU session ID, QFI, Differentiated Services Field Code Point (DSCP) value, or additional QoS information.

12. The N3IWF entity as claimed in claim 9, wherein the session management information is included in the N2 PDU session request message, and The messages mentioned include the IKE CREATE CHILD SA request message.

13. The N3IWF entity of claim 9, wherein the controller is further configured to send an N2PDU session response message to the AMF entity, the N2PDU session response message including information on whether the IPsec subSA connection was successfully executed, and The N2 PDU session response message also contains information related to the status of the QoS flow.

14. A user equipment in a wireless communication system, the user equipment comprising: transceiver; as well as The controller is connected to the transceiver. The controller is configured as follows: Receive a first message from a non-3GPP interoperability function (N3IWF) entity, the first message being used to request an Internet Protocol Security (IPsec) sub-Security Association (SA) connection that supports Quality of Service (QoS) flows with low latency, low loss, and scalable throughput (L4S). as well as A second message is sent to the N3IWF entity, the second message being a response to the first message.

15. The user equipment of claim 14, wherein the first message includes an IKE CREATE CHILD SA request message, and The IKE CREATE CHILD SA request message further includes at least one of the following: Packet Data Unit (PDU) Session ID, QoS Flow ID (QFI), Differentiated Services Field Code Point (DSCP) value, or additional QoS information.

Images