Apparatus and method for supporting l4s in non-3GPP access environment

Abstract

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

Description

Device and method for supporting L4S in a non-3GPP access environment

[0001] The present disclosure relates to a device and method for supporting L4S in a communication system considering Non-3GPP Access.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] As described above and with the development of mobile communication systems, various services have become available, and methods for effectively providing these services are required.

[0009] L4S (low latency, low loss, and scalable throughput) service is supported by many devices and servers due to its advantage of transmitting signals indicating L4S (ECN (explicit congestion notification)) support and congestion through in-band marking on existing protocols without requiring separate control plane call processing signals between intermediate nodes.

[0010] In metaverse and XR applications, relatively large amounts of uplink data must be transmitted. When network congestion occurs, methods can be applied to adjust the uplink transmission rate to account for network congestion. For these L4S-supporting services to be provided in non-3GPP Access environments, technological improvements are needed in the transmission and operation of L4S service-related information.

[0011] One aspect of the present disclosure may be to provide a device and method capable of providing congestion information in a communication system including Non-3GPP Access.

[0012] One aspect of the present disclosure may be 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.

[0013] According to one aspect of the present disclosure, a method performed by a Non-3GPP Interworking Function (N3IWF) entity in a communication system based on Non-3GPP Access, the method comprising: an operation of including L4S support indicator information in an NGAP initial context setup response message and transmitting the message to an AMF; an operation of receiving an N2 PDU session request message including L4S support indicator information from the AMF; an operation of determining the number of IPsec Child SAs based on the N2 PDU session request message; and an operation of establishing an IPsec Child SA.

[0014] According to one aspect of the present disclosure, a method of operating an N3IWF (Non 3GPP Interworking Function) entity in a communication system based on Non-3GPP Access is provided, and the method of operating includes: an operation of receiving a message including information related to whether an L4S (low latency, low loss and scalable throughput) service is supported in an S-RAN in an IPsec Tunnel between a terminal, a Non-3GPP AP (Access Point), and an N3IWF; an operation of transmitting ECN marking supporting indication (ECN marking supporting indication in Non-3gpp AP or ECN marking supporting indication in IPsec SA) information to an SMF through an AMF in a corresponding IPsec security association section when a terminal registration (Registration) is requested on a 5G system after an IPsec security association (SA, Security Associations); and, based on the L4S service support indicator message, a protocol data unit (PDU) session management (SES) including information related to whether an L4S service is supported in the N3IWF as a session management function (SMF) entity. The method includes an action of sending a PDU Session SM Update Request message, and an action of receiving a PDU Session SM Update Response message from an SMF entity in response to the PDU Session SM Update Request message.

[0015] According to one aspect of the present disclosure, a communication system provides an access and mobility management function (AMF) entity, the AMF entity including a transceiver and at least one processor, wherein the at least one processor is configured to receive, through the transceiver, a message from an N3IWF connected to a terminal, the message including information related to whether a low latency, low loss and scalable throughput (L4S) service is supported in the N3IWF, transmit a protocol data unit (PDU) session management (SMF) update request message including information related to whether an L4S service is supported in an S-RAN to a session management function (SMF) entity, and receive, through the transceiver, a PDU session SM update response message from the SMF entity in response to the PDU session SM update request message.

[0016] According to one embodiment of the present disclosure, when a terminal searches for an N3IWF to use a base station based on a Non 3GPP Access and performs an IPsec SA process between the terminal, a Non 3GPP AP, and the N3IWF, ECN marking and L4S support between the UE, the Non 3GPP AP, and the N3IWF may be determined, and the corresponding ECN / L4S capability information may be transmitted through the AMF during the terminal registration process or may be transmitted to a session management function (SMF) entity when a PDU Session connection request is made. When an L4S support indicator is transmitted from an AF, etc., the N3IWF may perform ECN marking for supporting the corresponding L4S service, and in the case of an uplink packet, the N3IWF may perform ECN marking based on congestion situation information of the Non 3GPP AP based on information in the Outer header of the IPsec packet. In addition, in the case of a downlink, the UE may also report congestion situation information to the AS based on CE information in the outer header in order to identify the congestion situation of the Non 3GPP AP.

[0017] Basically, in order to access a 5G system using a non-3gpp connection, IPsec Tunneling is performed between the UE and the N3IWF so that the UE can perform authorization and security procedures for using the N3IWF. In non-3gpp Access, ECN marking can be divided into ECN information in the inner IP header, which includes ECN information of the UE in the uplink and of the N3IWF in the downlink, and ECN information in the outer header, which notifies the congestion status of the non-3gpp AP during each data transmission. In general, in IPsec Tunnel mode, for ECN capable connections, there are two operation modes: limited functionality that utilizes only the information in the inner header for security reasons, and full functionality that considers the information in the outer header.

[0018] In the case of Non-3gpp Access using N3IWF as an example of the present disclosure, when operating IPsec SA, an IKEv2-based key exchange protocol is basically utilized. In the case of an IPsec SA that supports ECN connected with an IKEv2-based protocol, the IPsec Tunnel can basically support Full functionality of the ECN functionality operation method.

[0019] Information about congestion with N3IWF can be transmitted to the 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 through in-band signaling. In this case, the N3IWF can utilize the ECN bit information of the outer header in the IPsec packet to generate congestion information of a non-3gpp AP based on this and transmit this to the UPF through the GTP-U extension header. In addition, congestion information can occur not only in the non-3gpp AP but also in the N3IWF. In this case, when generating congestion information, if the information is ECN marking for a downlink data packet, the ECN bit information of the inner header of the IPsec packet can be transmitted to the UPF, and if the information is ECN marking information for an uplink data packet, the ECN bit information of the outer header can be transmitted to the UPF. If a congestion situation occurs in both network entities (N3IWF and Non 3gpp AP), the congestion information can be separately transmitted for each network entity by distinguishing between congestion information from N3IWF and congestion information from Non 3gpp AP.

[0020] In addition, after the IPsec SA connection, the N3IWF receives a PDU session connection request (PDU session Establishment Request) message from the terminal and forwards it to the SMF through the AMF, so that the QoS profile and related QFI, PDU session ID, and / or PDU session Establishment Accept message can be forwarded through the AMF. Based on the information, the N3IWF can determine the number of IPsec Child SAs for each QoS. At this time, if there is a QoS flow with an L4S support request among the QoS flows received from the AMF, the N3IWF can decide to create an IPsec Child SA considering this. If the AMF receives information that there are 9 general QoS flows and 1 QoS flow that requires L4S service provision, the N3IWF can service the general QoS flows by using one IPsec SA as IPsec child SA#1 and an IPsec tunnel between the UE and the N3IWF, and for the QoS flows that require L4S service provision, it can decide to use the service by creating a separate channel from the general IPsec Child SA channel as IPsec Child SA#2. As in the example above, the N3IWF may not provide a service using ECN among services using Non 3gpp Access depending on the selection of the UE or the service provider for security reasons. In this case, the N3IWF can decide to connect at least two IPsec Child SAs, one of which is the IPsec Child SA that transmits the general QoS flow and the other is the QoS flow that supports L4S service through ECN marking, connected to the same UE.

[0021] According to one embodiment of the present disclosure, a L4S service can be supported in a Non-3GPP Access-based communication system by providing congestion information based on whether L4S (ECN) is supported in the Non-3GPP Access-based communication system.

[0022] FIG. 1 is a diagram illustrating a network structure and interface of a 5G system according to an embodiment of the present disclosure.

[0023] FIG. 2 is a diagram illustrating a 5GC registration process through untrusted Non-3GPP Access of a UE according to one embodiment of the present disclosure.

[0024] FIG. 3 is a diagram illustrating the operation of N3IWF in response to a request for L4S service support for a QoS flow being serviced through untrusted Non-3GPP Access in AF according to one embodiment of the present disclosure.

[0025] FIG. 4a and FIG. 4b are flowcharts illustrating an operation of transmitting ECN capability information of an IPsec SA to an SMF during a 5GC registration and PDU session connection process through untrusted Non-3GPP Access according to an embodiment of the present disclosure.

[0026] FIG. 5a is a flowchart illustrating a QoS flow update operation and method for L4S support according to one embodiment of the present disclosure.

[0027] FIG. 5b is a flowchart illustrating a QoS flow update operation and method for L4S support according to one embodiment of the present disclosure.

[0028] FIG. 6 illustrates an example of a functional structure of a terminal according to one embodiment of the present disclosure.

[0029] FIG. 7 illustrates an example of a functional structure of a network entity according to one embodiment of the present disclosure.

[0030] Hereinafter, one embodiment of the present disclosure will be described in detail with reference to the attached drawings.

[0031] In describing this disclosure, descriptions of technical details that are well-known in the technical field to which this disclosure pertains and are not directly related to this disclosure will be omitted. This is to avoid obscuring the gist of this disclosure by omitting unnecessary explanations and to convey it more clearly. Furthermore, the terms described below are defined based on their functions in this disclosure and may vary depending on the intent or custom of the user or operator. Therefore, their definitions should be based on the contents of this specification as a whole.

[0032] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0033] Hereinafter, a base station (BS) is an entity that performs resource allocation of a terminal, and may be at least one of a gNode B, an eNode B, a Node B (or an xNode B (where x is an alphabet including g or e)), a wireless access unit, a base station controller, a satellite, an airborn, or a node on a network. A user equipment (UE) may include a mobile station (MS), a vehicle, a satellite, an airborn, a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. In the present disclosure, a downlink (DL) is a wireless transmission path of a signal transmitted from a base station to a terminal, and an uplink (UL) means a wireless transmission path of a signal transmitted from a terminal to an air station. Additionally, a sidelink (SL) may exist, which means a wireless transmission path of a signal transmitted from a terminal to another terminal.

[0034] In addition, although LTE, LTE-A, or 5G systems may be described below as examples, embodiments of the present disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, this may include 5G-Advance or NR-Advance, or 6th generation mobile communication technology (6G) developed after 5G mobile communication technology (or new radio, NR), and the 5G described below may also include existing LTE, LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems with some modifications within a range that does not significantly deviate from the scope of the present disclosure, as determined by a person having skilled technical knowledge.

[0035] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0036] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0037] Here, the term '~ part' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be on an addressable storage medium or may be configured to play one or more processors. Therefore, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. Additionally, the components and '~parts' may be implemented to activate one or more CPUs within a device or secure multimedia card. In addition, in an embodiment, the '~parts' may include one or more processors.

[0038] 3GPP, responsible for cellular mobile communications standards, is standardizing a new core network architecture called 5G Core (5GC) to facilitate the evolution of 4G LTE systems to 5G systems. Compared to the Evolved Packet Core (EPC), the network core for 4G, 5GC supports the following differentiated features:

[0039] 5GC introduces the Network Slice feature. As a requirement of 5G, 5GC must support a variety of terminal types and services, such as enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC). These terminals and services each have different requirements for the core network. For example, eMBB services may require high data rates, while URLLC services may require high reliability and low latency. To meet these diverse service requirements, Network Slice technology has been proposed.

[0040] Network slicing can refer to a method of virtualizing a single physical network to create multiple logical networks (e.g., network slices). An activated network slice can be called a network slice instance, and each network slice instance (NSI) can have different characteristics. By configuring a network function (NF) for each NSI according to its characteristics, mobile carriers can satisfy various service requirements according to terminals / services. For example, mobile carriers can efficiently support various 5G services (e.g., eMBB, URLLC, or mMTC) by allocating an NSI that matches the characteristics of the service required for each terminal.

[0041] 5GC can easily support the network virtualization paradigm by separating mobility management functions from session management functions. In 4G LTE, all terminals can receive services from the network through signaling exchanges with a single core entity called the mobility management entity (MME), which is responsible for registration, authentication, mobility management, and session management. In 5G, the number of terminals (including MTC terminals) will explode, and the mobility and traffic / session characteristics that must be supported depending on the terminal type will become more specialized. Therefore, supporting all functions from a single entity (such as the MME) will inevitably reduce scalability by adding entities for each required function. Therefore, various functions are being developed based on a structure that separates mobility management and session management functions to improve scalability in terms of functional / implementation complexity and signaling load of the core entity responsible for the control plane.

[0042] Embodiments according to the present disclosure may represent a method for supporting a PDU set establishment request procedure of a terminal in untrusted or trusted non-3GPP access for connecting to 5GC through a non-3GPP access point from a UE, and a process for performing related operations. Specifically, embodiments according to the present disclosure may represent a method for supporting an L4S-based service for appropriate congestion control by transmitting congestion situation information to an AS or UE when a congestion situation occurs in a network, and related operations. A terminal (UE) may perform an IPsec SA connection operation between the UE and an N3IWF in order to perform a registration procedure of the terminal in order to use a service through 5GC in a non-3GPP access environment. During the IPsec SA connection establishment procedure between the UE and the N3IWF, whether the IPsec SA supports ECN / L4S may be determined together, and this may be transmitted to the AMF during the 5GC registration procedure of the terminal. For example, when establishing an IPsec SA connection between a UE and an N3IWF, if a non-3gpp AP (access point) supports ECN marking, the UE connected through the non-3gpp access point can transmit information to the network that it can support L4S-based services. The information that the 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. Then, when a PDU session establishment request is received from the UE, the information can be transmitted from the AMF to the SMF during the PDU session establishment procedure.Alternatively, if the N3IWF does not transmit information on whether the IPsec SA supports ECN to the AMF during a separate registration procedure, the UE can include the ECN / L4S support indication of the IPsec SA in the PDU session establishment request message and transmit it through a separate indicator (L4S support indication for IPsec SA). Through the above process, the SMF can recognize that the IPsec SA between the UE and the N3IWF connected through a specific non-3GPP access point can support the L4S service. Later, if information on requesting L4S support for a specific QoS flow is transmitted to the PCF through AF during service use through non-3GPP access, the PCF can transmit the information on requesting L4S service support for the specific QoS flow to the SMF through the PCC rule update procedure. The SMF can determine whether to accept the request for L4S service support for a specific QoS flow based on a preset policy or information transmitted during the PDU session establishment procedure. During the PDU session establishment process, the SMF can receive information on whether the IPsec SA supports ECN from the AMF or the UE, and based on this, can decide whether to accept a request for L4S service support for a specific UE's QoS flow delivered from the AF. In addition, whether the SMF supports L4S service for a specific QoS flow can be determined based on whether the N3IWF connected to the UE using the service through non-3gpp access can directly mark the ECN bit in the ToS field in the IP headers for information on congestion status, or whether the N3IWF can support marking of congestion information in the GTP-U extension header so that congestion information can be delivered to the UPF through the GTP-U extension header.If the N3IWF supports at least one of the two marking methods for conveying congestion information, the SMF can determine that the N3IWF can support L4S service. The SMF can determine whether the N3IWF supports ECN marking operation for conveying congestion information because it receives information about the marking methods that can be supported from the N3IWF during the PDU session establishment process. The SMF can recognize in advance that the N3IWF supports congestion information marking support operation information and that ECN / L4S marking is supported in the IPsec SA between the UE and the N3IWF using the QoS flow, and based on this, can determine whether to accept a request for L4S service support for a specific QoS flow conveyed from the AF.

[0043] If N3IWF fails to perform ECN marking for congestion information within the IP header, SMF can include congestion information in the GTP-U extension header and forward it to UPF. At this time, SMF can determine whether UPF can perform ECN marking, and if UPF does not support this function, it can decide to change to UPF that supports ECN marking operation.

[0044] The SMF can determine whether a specific QoS flow requested by the AF supports L4S based on the operation of the UPF and whether the IPsec SA supports ECN marking, according to the congestion information transfer method of the N3IWF. If L4S is determined not to be supported, the SMF can inform the AF that the QoS flow cannot use L4S-based services.

[0045] FIG. 1 is a diagram illustrating a network structure and interface of a 5G system according to an embodiment of the present disclosure.

[0046] A network entity included in the network structure of the 5G system of Fig. 1 may include a network function (NF) depending on the system implementation.

[0047] Referring to FIG. 1, the network structure of a 5G system (100) may include various network entities. For example, the 5G system (100) may include an authentication server function (AUSF) entity (108), an 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 slicing selection function (NSSF) entity (114), an edge application service domain repository (EDR), an edge application server (EAS), and an EAS discovery function (EAS). discovery function (EASDF), user plane function (UPF) entity (104), (radio) access network ((R)AN) (102), and terminal, for example, user equipment (UE) (101).

[0048] Each NF entity of the 5G system (100) supports the following functions.

[0049] AUSF (108) processes and stores data for authentication of UE (101).

[0050] AMF (103) provides functions for access and mobility management per UE, and one UE can basically be connected to one AMF. Specifically, the AMF (103) provides signaling between CN nodes 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 performance of paging retransmission), mobility management control (subscription and policy), intra-system mobility and inter-system mobility support, support for network slicing, SMF selection, lawful intercept (for AMF events and interfaces to the LI system), provision of forwarding of session management (SM) messages between UE and SMF, transparent proxy for SM message routing, access authentication, access authorization including roaming authorization check. It supports functions such as authorization, provision of SMS message transmission between UE and SMSF, security anchor function (SAF) and / or security context management (SCM). Some or all of the functions of an AMF entity (103) may be supported within a single instance of an AMF entity.

[0051] DN (110) refers to, for example, an operator service, Internet access, or a third-party service. DN (110) transmits a downlink protocol data unit (PDU) to the UPF entity (104) or receives a PDU transmitted from the UE (101) from the UPF entity (104).

[0052] The PCF entity (106) receives information about packet flows from the application server and provides a function to determine policies such as mobility management and session management. Specifically, the PCF entity (106) supports functions such as supporting a unified policy framework for controlling network operations, providing policy rules so that control plane function entity(ies) (e.g., AMF entity, SMF entity, etc.) can enforce the policy rules, and implementing a front end for accessing related subscription information for policy determination within a user data repository (UDR).

[0053] The SMF entity (105) provides a session management function, and when 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., session establishment, modification, and termination, including tunnel maintenance between the UPF entity (104) and (R)AN (102) nodes), UE IP address allocation and management (optionally including authentication), selection and control of UP functions, traffic steering setup to route traffic from the UPF entity (104) to the appropriate destination, termination of the interface to policy control functions, enforcement of the control portion of policies and quality of service (QoS), lawful intercept (for SM events and interfaces to the LI system), termination of the SM portion of NAS messages, downlink data notification, initiation of AN specific SM information (delivered to the (R)AN (102) via N2 via the AMF entity (103)), determination of the session and service continuity (SSC) mode of the session, roaming functions, etc. Some or all of the functions of an SMF entity (105) may be supported within a single instance of an SMF entity.

[0054] The UDM entity (109) stores user subscription data, policy data, etc. The UDM entity (109) includes two parts: an application front end (FE) (not shown) and a user data repository (UDR) (not shown).

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

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

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

[0058] (R)AN(102) is a general term for a new radio access network that supports both evolved E-UTRA, an evolved version of 4G radio access technology, and new radio (NR) (e.g., gNB).

[0059] The gNB provides functions for radio resource management (i.e., radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to the UE in uplink / downlink (i.e., scheduling), IP (internet protocol) header compression, encryption and integrity protection of user data streams, selection of an AMF upon attachment of the UE if routing to the AMF is not determined from the information provided to the UE, routing of user plane data to UPF(s), routing of control plane information to the AMF, connection setup and teardown, scheduling and transmission of paging messages (originating from the AMF), scheduling and transmission of system broadcast information (originating from the AMF or operating and maintenance (O&M)), measurement and measurement reporting setup for mobility and scheduling, transport level packet marking in uplink, session management, support for network slicing, and QoS flows. It supports features such as mapping to management and data radio bearers, support for UEs in inactive mode, distribution of NAS messages, NAS node selection, radio access network sharing, dual connectivity, and tight interworking between NR and E-UTRA.

[0060] UE (101) refers to a user equipment. The user equipment may be referred to by terms such as terminal, mobile equipment (ME), or mobile station (MS). Furthermore, the user equipment may be a portable device such as a laptop, mobile phone, personal digital assistant (PDA), smartphone, or multimedia device, or may be a non-portable device such as a personal computer (PC) or vehicle-mounted device.

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

[0062] EASDF is an NF that can add ECS options that can be expressed as the address of the DNS server to which the DNS request of the terminal will be forwarded and the IP subnet address to be added when forwarding the DNS request of the terminal, for each FQDN. EASDF receives EAS domain configuration information from EDR and, based on the received information, processes the DNS request message received from the terminal. In addition, EASDF is an NF that receives the terminal IP address and the location information of the terminal within 3GPP and the DNS message processing rule and the DNS message reporting rule from the SMF (105), processes the DNS Query message received from the terminal and the DNS response message received from the DNS server, and, based on the DNS message reporting rule, transmits the information in the DNS message and the statistical information processed therefrom to the SMF (105).

[0063] NRF supports service discovery. It receives NF discovery requests from NF instances and provides information about discovered NF instances to them. It also maintains a list of available NF instances and the services they support.

[0064] Meanwhile, for convenience of explanation, FIG. 1 illustrates a reference model for a case where a UE (101) accesses one DN (110) using one PDU session, but the present disclosure is not limited thereto.

[0065] A UE (101) can access two (i.e., local and central) data networks simultaneously using multiple PDU sessions. In this case, two SMFs can be selected for different PDU sessions. However, each SMF can have the ability to control both the local UPF and the central UPF within the PDU session.

[0066] Additionally, the UE (101) may simultaneously access two (i.e., local and central) data networks provided within a single PDU session.

[0067] In the 3GPP system, a conceptual link connecting NFs within a 5G system is defined as a reference point. For example, the reference point(s) included in the 5G system (100) of FIG. 1 are as follows.

[0068] - N1: Reference point between UE (101) and AMF (103)

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

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

[0071] - N4: Reference point between SMF (105) and UPF (104)

[0072] - N5: Reference point between PCF (106) and AF (107)

[0073] - N6: Reference point between UPF (104) and DN (110)

[0074] - N7: Reference point between SMF (105) and PCF (106)

[0075] - N8: Reference point between UDM (109) and AMF (103)

[0076] - N10: Reference point between UDM (109) and SMF (105)

[0077] - N11: Reference point between AMF (103) and SMF (105)

[0078] - N12: Reference point between AMF (103) and AUSF (108)

[0079] - N13: Reference point between UDM (109) and AUSF (108)

[0080] - N14: Reference point between two AMFs (103)

[0081] - N15: Reference point between PCF and AMF in non-roaming scenario, reference point between PCF and AMF in visited network in roaming scenario.

[0082] - Nx: Reference point between SMF(105) and EASDF

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

[0084] FIG. 2 illustrates a 5GC registration process via an untrusted Non-3GPP Access of a UE according to an embodiment of the present disclosure. More specifically, FIG. 2 illustrates an operation of transmitting ECN / L4S support status to a network in an IPsec SA between a UE and an N3IWF during the 5GC registration process.

[0085] Referring to Figure 2, the N3IWF can connect a UE connected to Non-3GPP access to the 5G Core Network through the IKEv2 / IPsec protocol and N2 interface linkage. An IPsec SA connection can be established between the UE and the N3IWF through separate security and authentication procedures. The message protocol used for this security and authentication procedure is the IKE (Internet Key Exchange) v2 protocol. Unlike the existing structure between the UE and the NG-RAN, in non-3gpp access, a Non-3gpp Access point (e.g., wifi) can be added between the UE and the N3IWF. The UE can exchange data through the Non-3gpp Access Point with the N3IWF. In this case, the IP header and payload transmitted to the existing N3IWF can be defined as an Inner IP packet according to the IPsec structure. In IPsec Tunnel mode, an additional outer IP packet with the Inner IP packet as the payload can be defined. That is, in the IPsec SA section, an outer IP packet can be generated and transmitted to the UE via a non-3gpp access point. For example, in the case of uplink, the IP packet transmitted by the UE can be included in the payload of the outer IP packet as an inner IP packet and transmitted. In this way, the non-3gpp AP can transmit congestion status information of the non-3gpp access section to the UE or N3IWF through the header of the outer IP packet.In this way, during the IPsec SA connection establishment process, the ECT (ECN Capable Transport) information of the corresponding UE, non-3gpp AP, and N3IWF can be exchanged through the IP header, and based on this, the SMF can determine whether the IPsec SA supports ECN marking and L4S service. IPsec SA based on non-3gpp access can exchange authentication and security messages using IKEv2. At this time, if the IPsec SA supports ECN or L4S, it can support full functionality by adding congestion information of the non-3gpp access section to the outer IP header.

[0086] 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 is received from the UE, the information can be transferred from the AMF to the SMF during the PDU session establishment procedure. Alternatively, if the N3IWF does not transfer information to the AMF regarding whether the IPsec SA supports ECN or L4S during a separate registration procedure, the UE can include information regarding whether the IPsec SA supports ECN / L4S in the PDU session establishment request message and transmit it to the SMF through a separate indicator (L4S support indication for IPsec SA).

[0087] SMF can recognize that L4S services can be supported through IPsec SA between UE and N3IWF connected through specific non-3gpp AP.

[0088] When L4S support request information for a specific QoS flow is transmitted to the PCF through AF during service use via non-3GPP access, the PCF can transmit the L4S service support request information for the specific QoS flow to the SMF through the PCC rule update process. The SMF can determine whether to accept the L4S service support request for the specific QoS flow based on a preset policy or information transmitted during the PDU session establishment process. The SMF can receive information on whether IPsec SA supports ECN from the AMF or UE during the PDU session establishment process, and based on this, determine whether to accept the L4S service support request for the QoS flow for the specific UE transmitted from the AF. 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 conditions below. If the N3IWF can mark information about the congestion situation in the ECN bit of the ToS field in the IP headers, or if the N3IWF can mark congestion information in the GTP-U extension header and transmit it to the UPF, the N3IWF can be determined to support the L4S service. In addition, when using the service through non-3gpp access, the SMF can determine whether to accept a request for L4S service support of the corresponding QoS flow using non-3gpp access when the N3IWF supports at least one marking method for transmitting congestion information and ECN / L4S service support (ECN capable) is possible in the IPsec SA section between the N3IWF and the UE.

[0089] Information about marking operations (IP header marking or GTP-U HE marking) for transmitting congestion information from N3IWF can be received from N3IWF during the PDU session establishment process. SMF can decide whether to accept a request for L4S service support of a specific QoS flow based on information about congestion information marking support operation of N3IWF, whether UPF supports operation for ECN bit marking in IP header according to congestion information marking support operation, and whether IPsec SA supports ECN / L4S for the corresponding QoS flow.

[0090] FIG. 3 is a diagram illustrating the operation of N3IWF in response to a request for L4S service support for a QoS flow being serviced through untrusted Non-3GPP Access in AF according to one embodiment of the present disclosure.

[0091] As shown in Fig. 2, when establishing an IPsec SA connection between a UE and an N3IWF, information indicating that the IPsec SA can support ECN / L4S can be stored in the AMF during the 5GC registration procedure through the UE's N3IWF. Then, information on whether the IPsec SA supports ECN / L4S stored in the AMF can be transmitted to the SMF during the subsequent PDU session establishment request procedure. Alternatively, instead of transmitting information on whether the IPsec SA supports ECN / L4S through the 5GC registration procedure, the UE can include a separate indicator (L4S support indication for IPsec SA) indicating whether the IPsec SA supports ECN / L4S in the PDU session establishment request message and transmit it to the SMF. Through this, the SMF can recognize that the L4S service can be supported through the IPsec SA between the UE and the N3IWF through a specific non-3gpp AP.

[0092] When L4S support request information for a specific QoS flow is transmitted to the PCF through AF during service use via non-3GPP access, the PCF can transmit the L4S service support request information for the specific QoS flow to the SMF through the PCC rule update process. The SMF can determine whether to accept the L4S service support request for the specific QoS flow based on a preset policy or information transmitted during the PDU session establishment process. The SMF can receive information on whether IPsec SA supports ECN from the AMF or UE during the PDU session establishment process, and based on this, determine whether to accept the L4S service support request for the QoS flow of a specific UE transmitted from the AF. In addition, whether the SMF accepts the L4S service support request for the specific QoS flow can be determined based on whether the following conditions are satisfied in the N3IWF. If the N3IWF can directly mark information about congestion status in the ECN bit in the ToS field of the IP headers, or if the N3IWF can mark congestion information in the GTP-U extension header and transmit it to the UPF, the N3IWF can be determined to support L4S service. In addition, when using a service through non-3gpp access, if the N3IWF supports at least one marking method for transmitting congestion information and the IPsec SA section between the N3IWF and the UE is ECN capable, the SMF can determine whether to accept the L4S service request of the QoS flow using non-3gpp access.

[0093] During the PDU session establishment process, the SMF can receive information about marking operations (IP header marking or GTP-U HE marking) for conveying congestion information from the N3IWF. The SMF can decide whether to accept a request for L4S service support of a specific QoS flow based on information about the congestion information marking support operation of the N3IWF, whether the UPF supports the operation for marking ECN bits in the IP header according to the congestion information marking support operation, and / or whether the IPsec SA for the corresponding QoS flow supports ECN / L4S.

[0094] When the N3IWF receives an L4S support indication or congestion information marking request information for L4S service support from the SMF, the N3IWF determines which IPsec child SA contains the QoS flow for which L4S service support is requested, and if the IPsec child SA is configured to support ECN / L4S, the N3IWF can perform L4S service support through ECN / L4S marking on the current IPsec child SA. However, if the specific QoS flow for which L4S service support is requested is contained in an IPsec child SA that does not support ECN, the N3IWF can move to an IPsec child SA that supports ECN separately for the QoS flow if there is one, or, if there is no separate IPsec child SA, can forward a connection request of the IPsec child SA to the UE so that the UE can newly connect an IPsec child SA that supports ECN. In order to support L4S service in N3IWF, the operation of connecting a separate IPsec child SA for a QoS flow can be performed based on parameters set in PCF for a specific QoS flow when a PDU session establishment request is made from a UE, or the operation can be determined based on a PDU session change request including L4S service support indicator information of a specific QoS flow separately from AF during service use.

[0095] Afterwards, N3IWF may transfer resources for QoS flows that have requested support for L4S services to the corresponding IPsec SA after establishing a new IPsec SA connection for ECN support, and may separately transmit L4S support indication information to the UE to notify that the terminal also needs to perform ECN / L4S operations, or may transmit policy information to the UE when establishing a new IPsec SA connection.

[0096] 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 process via untrusted Non-3GPP Access according to an embodiment of the present disclosure.

[0097] In step 401, the UE may transmit a request message to establish an IPsec SA connection with the N3WIF and register a 5GC. The UE may receive information including the N3IWF and its associated IP address based on information received from the untrusted non-3GPP access network. Thereafter, the UE may select an N3IWF based on the information received from the untrusted non-3GPP access network and obtain the IP address information of the selected N3IWF. The UE may then initiate an IKE initial exchange to establish an IPsec security association (SA) with the selected N3IWF. All subsequent IKE messages may be encrypted and integrity protected using the IKE SA established in this operation. The UE may initiate the IKE_AUTH exchange by sending an IKE_AUTH request message. The N3IWF may respond with an IKE_AUTH response message containing an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet may notify the UE to initiate an EAP-5G session. The UE may transmit 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 may include information used by the N3IWF to select an AMF in the 5G core network. This information may include GUAMI, the selected PLMN ID, the requested NSSAI, and the Establishment cause. The Establishment cause may provide the reason for requesting a signaling connection with the 5GC. Whether and how the UE includes the requested NSSAI as part of the AN parameters may vary depending on the value of the Access Layer Connection Establishment NSSAI Inclusion Mode parameter.The registration request may include an indication that the UE supports N3IWF selection based on the slice the UE intends to use over untrusted non-3GPP access. The N3IWF may select an AMF based on the received AN parameters and local policies. The N3IWF may then forward the registration request received from the UE to the selected AMF via an N2 message. The selected AMF may decide to request SUCI by sending a NAS Identity Request message to the UE. This NAS message and all subsequent NAS messages may be protected within an EAP / 5G-NAS packet and transmitted to the UE. The AMF may decide to authenticate the UE using the AUSF. The AMF may send a NAS Security Mode Command to the UE to enable NAS security. The N3IWF that receives the NAS Security Mode Command message may forward it to the UE within an EAP / 5G-NAS packet. The UE may complete EAP-AKA authentication, generate a NAS security context and an N3IWF key, and transmit an EAP / 5G-NAS packet containing a NAS security mode complete message. The N3IWF may forward the NAS security mode complete message to the AMF. Upon receiving the NAS security mode complete, the AMF may send an NGAP Initial Context Setup Request message containing the N3IWF key to the N3IWF. This triggers the N3IWF to send an EAP-Success to the UE, thereby completing the EAP-5G session and preventing further exchange of EAP-5G packets. An IPsec SA may be established between the UE and the N3IWF using the common N3IWF key generated by the UE and received by the N3IWF. After establishing the signaling IPsec SA, the N3IWF may send an NGAP Initial Context Setup Response to the AMF (operation 402) to indicate that a UE context including AN security has been created.The signaling IPsec SA must be configured to operate in tunnel mode, and the N3IWF may assign an "inner" IP address to the UE. All subsequent NAS messages exchanged between the UE and the N3IWF may be carried over the signaling IPsec SA and delivered over TCP / IP. The UE may send NAS messages within a TCP / IP packet whose source address is the UE's "inner" IP address and whose destination address is NAS_IP_ADDRESS. Similarly, the N3IWF may send NAS messages within a TCP / IP packet whose source address is NAS_IP_ADDRESS and whose destination address is the UE's "inner" IP address. The TCP connection used for reliable NAS transport between the UE and the N3IWF may be initiated by the UE immediately after the signaling IPsec SA is established. The AMF may determine the requested NSSAI allowed by the subscribed S-NSSAI(s). The AMF may send a NAS registration acknowledgement message in the N2 message sent to the N3IWF. The N2 message may include an Allowed NSSAI for the UE's access type. The Allowed NSSAI may be part of a slice supported by the selected N3IWF. The N3IWF may forward a NAS Registration Accept message to the UE via a signaling IPsec SA.

[0098] In operation 402, if N3IWF can determine whether the IPsec SA supports ECN / L4S during the IPsec SA establishment process, it can include ECN / L4S support indicator information in the NGAP initial context setup response message and forward it to AMF.

[0099] In operation 403, the UE may transmit to the AMF using a NAS message the S-NSSAI(s), UE Requested DNN, PDU Session ID, Request type, Old PDU Session ID, and / or N1 SM container including PDU Session Establishment Request. The PDU Session Establishment Request may include the PDU session ID, the requested PDU session type, the requested SSC mode, 5GSM Capability, PCO, SM PDU DN Request Container, and / or L4S support indication or ECN capable IPsec SA indication information. If the N3IWF sent ECN or L4S support indicator information to the AMF during the 5GC registration process in operation 402, separate ECN or L4S support indicator information may not be included in operation 403.

[0100] In actions 404 and 405, the AMF may select an SMF and then send a PDU session-related session management context creation request message (Nsmf_PDUSession_CreateSMContext Request) containing information such as L4S support indication or ECN capable IPsec SA indication to the SMF.

[0101] In operation 406, the SMF may create an SM context based on a PDU session-related session management context creation request message including L4S support indication or ECN capable IPsec SA indication information received from the AMF through operation 405, and may transmit the SM context ID to the AMF through a PDU session-related session management context creation request response (Nsmf_PDUSession_CreateSMContext Request response) message.

[0102] In operation 407, SMF can select a PCF through a PCF selection process based on information such as SUPI.

[0103] From action 408 to action 410, the SMF can receive policy information related to the PDU session (Npcf_SMPolicyControl_Create Response) from the PCF. The policy information transmitted from the PCF to the SMF may include QoS information including L4S support indicator information within the corresponding PDU session, depending on network operator settings, etc.

[0104] In operation 411, the SMF can perform a UPF selection operation based on the policy information received from the PCF. If the policy information received from the PCF contains information on QoS supporting L4S service, the SMF can select a UPF operation for supporting L4S service and transmit the operation information in an N4 Session Establishment Request message as an N4 rule. For example, if the N3IWF cannot directly mark congestion information in the IP header but can transmit it through the GTP-U extension header, the SMF can include the requirement for QoS monitoring operation for receiving congestion information in the N4 rule and transmit it to the UPF. In addition, the SMF can select a UPF that supports it if the N3IWF cannot mark congestion information in the IP header.

[0105] In actions 412 and 413, based on the decision of the SMF in action 411, the N4 rules including packet detection rules of the UPF, actions of marking congestion information in the IP header in the UPF, and actions of receiving congestion information through the GTP-U extension header through QoS monitoring can be included in the N4 Session Establishment request message and transmitted to the UPF. Thereafter, the UPF can transmit an N4 Session Establishment request response message including CN Tunnel Info, etc. to the SMF.

[0106] In operation 414, the SMF can forward N2 SM information including QoS information and L4S support indicator information supporting L4S service to the AMF. If the SMF recognizes that the N3IWF does not support the operation of directly marking congestion information in the IP header while generating information for selecting UPF in operation 411, the SMF can include L4S support indication and congestion control information forwarding request information through GTP-U extension header in the N2 SM information and forward it to the AMF through the Namf_Communication_N1N2MessageTransfer message.

[0107] At operation 415, the AMF may convey information related to PDU session establishment, such as QoS profile and related QFI, PDU session ID, PDU session Establishment Accept and / or L4S support indicator, to the N3IWF via an N2 PDU session request message.

[0108] In operation 416, the N3IWF may determine the number of IPsec Child SAs between the UE and the N3IWF based on the information received from the AMF. At this time, if there is a QoS flow requiring L4S service support among the PDU session establishment related information received from the AMF, the N3IWF may decide to create an IPsec Child SA by considering the QoS flow requiring L4S service support. For security reasons, the N3IWF may not provide a service using ECN among services using Non 3gpp Access depending on the selection of the UE or the service provider.

[0109] For example, N3IWF can receive information from AMF that there are four general QoS flows and one QoS flow that requires provision of L4S service. Based on the information, N3IWF can decide that the four general QoS flows use one IPsec SA as IPsec child SA#1, and that the one QoS flow that requires provision of L4S service uses the service through a separate IPsec SA channel as IPsec Child SA#2. In this case, N3IWF can decide to connect at least two IPsec Child SAs, including the IPsec Child SA that transmits the general QoS flow that is connected to the same UE and the IPsec Child SA that transmits the QoS flow that supports L4S service through ECN marking.

[0110] In actions 417a and 417b, if the N3IWF decides to create two IPsec child SAs, it may perform the first IPsec SA establishment operation by transmitting one or more QFIs, DSCP values, additional QoS information, etc. for IPsec child SA#1 to the UE.

[0111] In subsequent actions 417c and 417d, the N3IWF may transmit one or more QFIs, DSCP values, additional QoS information, etc. for additional IPsec child connections to the UE and establish an additional IPsec SA with the UE. If the QoS flow associated with the additional IPsec SA is a QoS flow that supports L4S service, the N3IWF may transmit operation request information for supporting L4S service by including information such as L4S support indication in the additional QoS information to the UE.

[0112] At step 418, after all IPsec Child SAs are established, the N3IWF may forward the PDU Session Establishment Acknowledgement message received at step 415 to the UE via the signaling IPsec SA.

[0113] At operation 419, the N3IWF may send a PDU session response message containing N2 SM information including AN Tunnel information to the AMF.

[0114] From step 420 to step 423, AMF can forward the information including N2 SM information and SM context ID received from N3IWF to SMF through PDU session related SM context update (Nsmf_PDUSession_UpdateSMContext Request) message. SMF can forward AN tunnel information to UPF through N4 Session Modification process. After that, UPF can forward N4 Session Modification response message to SMF, and SMF can send response message of SM context update request to AMF.

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

[0116] In step 500, a terminal (UE) may transmit a request message to establish an IPsec SA connection with an N3WIF and register a 5GC. The UE may receive information including an N3IWF and its associated IP address based on information received from an untrusted non-3GPP access network. Thereafter, the UE may select an N3IWF based on the information received from the untrusted non-3GPP access network and obtain IP address information of the selected N3IWF. The UE may then initiate an IKE initial exchange to establish an IPsec security association (SA) with the selected N3IWF. All subsequent IKE messages may be encrypted and integrity protected using the IKE SA established in this operation. The UE may initiate an IKE_AUTH exchange by transmitting an IKE_AUTH request message. The N3IWF may respond with an IKE_AUTH response message containing an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet may notify the UE to initiate an EAP-5G session. The UE may transmit 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 may include information used by the N3IWF to select an AMF in the 5G core network. The information may include a GUAMI, a selected PLMN ID, a requested NSSAI, and an Establishment cause. The Establishment cause may provide a reason for requesting a signaling connection with the 5GC. Whether and how the UE includes the requested NSSAI as part of the AN parameters may vary depending on the value of the Access Layer Connection Establishment NSSAI Inclusion Mode parameter.The registration request may include an indication that the UE supports N3IWF selection based on the slice the UE intends to use over untrusted non-3GPP access. The N3IWF may select an AMF based on the received AN parameters and local policies. The N3IWF may then forward the registration request received from the UE to the selected AMF via an N2 message. The selected AMF may decide to request SUCI by sending a NAS Identity Request message to the UE. This NAS message and all subsequent NAS messages are protected within an EAP / 5G-NAS packet and transmitted to the UE. The AMF may decide to authenticate the UE using the AUSF. The AMF may send a NAS Security Mode Command to the UE to enable NAS security. The N3IWF that receives the NAS Security Mode Command message may forward it to the UE within an EAP / 5G-NAS packet. The UE may complete EAP-AKA authentication, generate a NAS security context and an N3IWF key, and transmit an EAP / 5G-NAS packet containing a NAS security mode complete message. The N3IWF may forward the NAS security mode complete message to the AMF. Upon receiving the NAS security mode complete, the AMF may send an NGAP Initial Context Setup Request message containing the N3IWF key to the N3IWF. This triggers the N3IWF to send an EAP-Success to the UE, thereby completing the EAP-5G session and preventing further exchange of EAP-5G packets. An IPsec SA may be established between the UE and the N3IWF using the common N3IWF key generated by the UE and received by the N3IWF. After establishing the signaling IPsec SA, the N3IWF may send an NGAP Initial Context Setup Response to the AMF to indicate that a UE context containing AN security has been created.The signaling IPsec SA must be configured to operate in tunnel mode, and the N3IWF may assign an "inner" IP address to the UE. All subsequent NAS messages exchanged between the UE and the N3IWF may be carried over the signaling IPsec SA and delivered over TCP / IP. The UE may send NAS messages within a TCP / IP packet whose source address is the UE's "inner" IP address and whose destination address is NAS_IP_ADDRESS. Similarly, the N3IWF may send NAS messages within a TCP / IP packet whose source address is NAS_IP_ADDRESS and whose destination address is the UE's "inner" IP address. The TCP connection used for reliable NAS transport between the UE and the N3IWF may be initiated by the UE immediately after the signaling IPsec SA is established. The AMF may determine the requested NSSAI allowed by the subscribed S-NSSAI(s). The AMF may send a NAS registration acknowledgement message in the N2 message sent to the N3IWF. The N2 message may include an Allowed NSSAI for the UE's access type. The Allowed NSSAI may be part of a slice supported by the selected N3IWF. The N3IWF may forward a NAS registration acceptance message to the UE via a signaling IPsec SA. Operation 500 may correspond to operation 401 of FIG. 4A.

[0117] In operation 501, AF can decide to request L4S service support in non-3gpp access based service.

[0118] In operation 502, AF can transmit L4S service support request information, such as L4S Support indication for non-3gpp access, to NEF through an AFsessionWithQoS Update request message based on L4S support indicator information, etc.

[0119] In operation 503, NEF may perform the following actions after receiving request information including L4S support request, congestion report request, etc. from AF in operation 502 through policy approval request process to PCF.

[0120] The NEF can verify subscriber information for the AF request in the UDM. If the subscriber information included in the AF request is a generic public subscription identifier (GPSI), the NEF can request that it be replaced with a subscription permanent identifier (SUPI) to identify the subscriber within the 5GC network. If the subscriber information included in the AF request is subscriber group information, the NEF can request that the subscriber group information be replaced with a group identifier within the 5G network within the 5GC network. If the subscriber information included in the AF request is subscriber group information and can be replaced with a list of multiple subscriber information items, the NEF can request such replacement through the UDM entity.

[0121] NEF may request approval of an AF request from a UDM entity to verify that the AF identifier and information about the service requested by the AF and subscriber information comply with the operator's subscription policy.

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

[0123] At step 505, the SMF may make a decision on the action for L4S support and the selection of the NF to provide it after receiving the updated PCC rule including the L4S support indication information. In order to make the decision on L4S support, the SMF may be assumed to know whether the IPsec SA supports ECN / L4S and which congestion information marking method is supported by the N3IWF during the PDU session establishment process or based on the network operator's settings. If the policy information received from the PCF contains information on the QoS that supports the L4S service, the SMF may select the UPF action for L4S service support and include the action information in the N4 Session Establishment Request message as an N4 rule. For example, if the N3IWF cannot directly mark congestion information in the IP header but can transmit it through the GTP-U extension header, the SMF may include the requirement for the QoS monitoring action for receiving congestion information in the N4 rule and forward it to the UPF. In addition, the SMF can select a UPF that supports it when the N3IWF fails to mark congestion information in the IP header. The SMF can perform the UPF selection operation based on the policy information received from the PCF. The SMF can determine whether to accept a request for L4S service support for a specific QoS flow based on a preset policy or information transmitted during the PDU session establishment process. The SMF can receive information on whether IPsec SA supports ECN from the AMF or UE during the PDU session establishment process, and based on this, can decide whether to accept a request for L4S service support for a specific UE's QoS flow transmitted from the AF. In addition, the SMF can determine whether to accept a request for L4S service support for a specific QoS flow based on whether the following conditions are satisfied by the N3IWF.If the N3IWF can directly mark information about congestion status in the ECN bit in the ToS field of the IP headers, or can mark congestion information in the GTP-U extension header and pass it to the UPF, the N3IWF can be determined to support L4S service. In addition, when using the service through non-3gpp access, the SMF can determine whether to accept the L4S service request of the QoS flow using non-3gpp access if the N3IWF supports at least one marking method for passing congestion information and the IPsec SA section between the N3IWF and the UE is ECN capable.

[0124] In operation 506, the SMF can forward N2 SM information including QoS information and L4S support indicator information supporting L4S service to the AMF. If, while generating information for selecting UPF in operation 505, the N3IWF recognizes that the operation of directly marking congestion information in the IP header is not supported, the SMF can include L4S support indication and congestion control information forwarding request information through GTP-U extension header in the N2 SM information and forward it to the AMF through the Namf_Communication_N1N2MessageTransfer message.

[0125] At operation 507, the AMF may convey information related to PDU session establishment, such as QoS profile and related QFI, PDU session ID, PDU session Establishment Accept and / or L4S support indicator, to the N3IWF via an N2 PDU Session Request message.

[0126] In Actions 508a and 508b, based on the decision of the SMF in Action 505, the SMF may send an N4 Session Establishment request message to the UPF, including N4 rules including packet detection rules of the UPF, actions of marking congestion information in the IP header in the UPF, and actions of receiving congestion information through the GTP-U extension header through QoS monitoring. The UPF may then send an N4 Session Establishment request response message including CN Tunnel Info, etc., to the SMF.

[0127] In operation 509, the N3IWF may decide to update the IPsec Child SA between the UE and the N3IWF based on the information received from the AMF. If existing QoS flows are being transmitted through an IPsec SA that does not support ECN / L4S, when the N3IWF receives a request for L4S service support, it may decide to associate a new IPsec SA that supports ECN / L4S for the corresponding QoS flow. For example, when five QoS flows that do not support L4S service are being transmitted to one IPsec SA#1 in the N3IWF, one of the QoS flows may be requested to provide an L4S service. The N3IWF may decide to create IPsec SA#2 for the QoS flow that supports one L4S service and update the QoS flow information requesting L4S service support from the existing IPsec SA#1 to IPsec SA#2. To this end, N3WIF can update QoS flow and Child SA mapping information by sending an INFORMATIONAL request message including QFI and Additional QoS information related to Child SA.

[0128] In operation 510, if the N3IWF decides to create a new IPsec child SA, it can perform a new IPsec SA establishment operation that supports L4S service by transmitting QFI, PDU session ID, etc. for the IPSEC child SA to the UE.

[0129] In Action 511, if a new IPsec Child SA supporting L4S service is established based on the N2 session request, N3IWF can report the success or failure of the request to AMF.

[0130] From Action 512 to Action 513, AMF can forward N2 SM information, including the success or failure of the request information for L4S service support, to SMF via the PDU session related SM context update (Nsmf_PDUSession_UpdateSMContext Request) message. SMF can forward updated QoS flow information, etc. to UPF via the N4 Session Change Request action.

[0131] In operation 514, a non-3gpp access point (e.g., wifi) may be added between the UE and the N3IWF. The UE may transmit and receive data through the non-3gpp access point with the N3IWF. In this case, the IP header and payload transmitted to the existing N3IWF may be defined as an inner IP packet in relation to the IPsec structure. In IPsec Tunnel mode, an additional outer IP packet including the inner IP packet in the payload may be defined. That is, in the IPsec SA section, an outer IP packet may be generated and transmitted to the UE through the non-3gpp access point.

[0132] In operation 514a, when downlink data is transmitted to the N3IWF, the N3IWF can perform the operation transmitted through the SMF. When downlink data is transmitted from the UPF, if congestion occurs in the N3IWF or if congestion occurs before the N3IWF, the N3IWF can perform CE marking on the corresponding ECN bit of the Inner IP header, or receive an IP packet with CE marked in the ECN bit and transmit it to the UE as an Inner packet. In addition, when congestion occurs in a non-3gpp access network, the N3IWF can mark the corresponding congestion information on the ECN bit of the Outer packet header and transmit it to the UE.

[0133] In operation 514b, the UE that has received the downlink data can generate congestion information by distinguishing whether the congestion situation is a congestion situation in a non-3gpp access section or a congestion situation that occurred within 5GC, and can transmit this to the AS so that queue management can be performed according to each situation.

[0134] In operation 515, when the congestion situation of the Non-3gpp access section is marked and transmitted through the outer header during uplink data transmission, the N3IWF determines whether to generate congestion information based on the ECN bit information of the header of the outer header, and the method of marking and transmitting the congestion information can be transmitted based on the decision made in operation 505 in the SMF.

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

[0136] At step 520, the terminal (UE) may transmit a request message to establish an IPsec SA connection with the N3WIF and register a 5GC. The UE may receive information including the N3IWF and its associated IP address based on information received from the untrusted non-3gpp access network. Thereafter, the UE may select an N3IWF based on the information received from the untrusted non-3gpp access network and obtain IP address information of the selected N3IWF. Thereafter, the UE may initiate an IKE initial exchange to establish an IPsec security association (SA) with the selected N3IWF. All subsequent IKE messages may be encrypted and integrity protected using the IKE SA established in this operation. The UE may initiate the IKE_AUTH exchange by transmitting an IKE_AUTH request message. The N3IWF may respond with an IKE_AUTH response message containing an EAP-Request / 5G-Start packet. The EAP-Request / 5G-Start packet may notify the UE to initiate an EAP-5G session. The UE may transmit 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 may include information used by the N3IWF to select an AMF in the 5G core network. The information may include a GUAMI, a selected PLMN ID, a requested NSSAI, and an Establishment cause. The Establishment cause may provide a reason for requesting a signaling connection with the 5GC. Whether and how the UE includes the requested NSSAI as part of the AN parameters may vary depending on the value of the Access Layer Connection Establishment NSSAI Inclusion Mode parameter.The registration request may include an indication that the UE supports N3IWF selection based on the slice the UE intends to use over untrusted non-3GPP access. The N3IWF may select an AMF based on the received AN parameters and local policies. The N3IWF may then forward the registration request received from the UE to the selected AMF via an N2 message. The selected AMF may decide to request SUCI by sending a NAS Identity Request message to the UE. This NAS message and all subsequent NAS messages are protected within an EAP / 5G-NAS packet and transmitted to the UE. The AMF may decide to authenticate the UE using the AUSF. The AMF may send a NAS Security Mode Command to the UE to enable NAS security. The N3IWF that receives the NAS Security Mode Command message may forward it to the UE within an EAP / 5G-NAS packet. The UE may complete EAP-AKA authentication, generate a NAS security context and an N3IWF key, and transmit an EAP / 5G-NAS packet containing a NAS security mode complete message. The N3IWF may forward the NAS security mode complete message to the AMF. Upon receiving the NAS security mode complete, the AMF may send an NGAP Initial Context Setup Request message containing the N3IWF key to the N3IWF. This triggers the N3IWF to send an EAP-Success to the UE, thereby completing the EAP-5G session and preventing further exchange of EAP-5G packets. An IPsec SA may be established between the UE and the N3IWF using the common N3IWF key generated by the UE and received by the N3IWF. After establishing the signaling IPsec SA, the N3IWF may send an NGAP Initial Context Setup Response to the AMF to indicate that a UE context containing AN security has been created.The signaling IPsec SA must be configured to operate in tunnel mode, and the N3IWF may assign an "inner" IP address to the UE. All subsequent NAS messages exchanged between the UE and the N3IWF may be carried over the signaling IPsec SA and delivered over TCP / IP. The UE may send NAS messages within a TCP / IP packet whose source address is the UE's "inner" IP address and whose destination address is NAS_IP_ADDRESS. Similarly, the N3IWF may send NAS messages within a TCP / IP packet whose source address is NAS_IP_ADDRESS and whose destination address is the UE's "inner" IP address. The TCP connection used for reliable NAS transport between the UE and the N3IWF may be initiated by the UE immediately after the signaling IPsec SA is established. The AMF may determine the requested NSSAI allowed by the subscribed S-NSSAI(s). The AMF may send a NAS registration acknowledgement message in the N2 message sent to the N3IWF. The N2 message may include an Allowed NSSAI for the UE's access type. The Allowed NSSAI may be part of a slice supported by the selected N3IWF. The N3IWF may forward a NAS registration acceptance message to the UE via a signaling IPsec SA. Operation 520 may correspond to operation 401 of FIG. 4A.

[0137] In operation 521, AF may decide to request L4S service support in a non-3gpp access based service.

[0138] In operation 522, AF can transmit L4S service support request information, such as L4S Support indication for non-3gpp access, to NEF through an AFsessionWithQoS Update request message based on L4S support indicator information, etc.

[0139] In operation 523, NEF may perform the following actions after receiving request information including L4S support request, congestion report request, etc. from AF in operation 522 through policy approval request process to PCF.

[0140] The NEF can verify subscriber information for the AF request in the UDM. If the subscriber information included in the AF request is a generic public subscription identifier (GPSI), the NEF can request that it be replaced with a subscription permanent identifier (SUPI) to identify the subscriber within the 5GC network. If the subscriber information included in the AF request is subscriber group information, the NEF can request that the subscriber group information be replaced with a group identifier within the 5G network within the 5GC network. If the subscriber information included in the AF request is subscriber group information and can be replaced with a list of multiple subscriber information items, the NEF can request such replacement through the UDM entity.

[0141] NEF may request approval of an AF request from a UDM entity to verify that the AF identifier and information about the service requested by the AF and subscriber information comply with the operator's subscription policy.

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

[0143] At step 525, the SMF may receive the updated PCC rule including the L4S support indication information, and then make a decision on the operation for L4S support and the selection of the NF to provide it. Specifically, the SMF may select the NF that supports the ECN marking operation for L4S according to the network operator's policy, and the selected NF may be NG-RAN or UPF. If the SMF selects the UPF as the NF entity for L4S service support according to the network operator's policy, the ECN marking operation information may be included in the N4 Session Establishment Request message as an N4 rule and transmitted. For example, if the N3IWF cannot directly mark congestion information in the IP header but can transmit congestion information to the UPF through the GTP-U extension header, the SMF may include requirements related to the QoS monitoring operation for receiving congestion information in the N4 rule and transmit it to the UPF. The SMF can decide whether to accept a request for L4S service support for a specific QoS flow based on a pre-established policy or information received from the NG-RAN during the PDU session establishment process. The SMF can select an NF that supports ECN marking operation for L4S based on the updated PCC rules including the ECN marking for L4S indicator information received from the PCF. Thereafter, the SMF can forward N2 information including the ECN marking for L4S indicator or QoS monitoring configuration for congestion information to the N3IWF through the AMF during the PDU session establishment or modification process.Based on the information received from the SMF, if the N3IWF supports the ECN marking for L4S indicator operation, the N3IWF can forward the information of established QoS Flows status (active) for ECN marking for L4S to the SMF through the AMF. If the N3IWF does not support the ECN marking for L4S indicator operation, the N3IWF can forward the information of established QoS Flows status (inactive) for ECN marking for L4S to the SMF through the AMF. In addition, if the N3IWF supports the QoS monitoring configuration for congestion information operation based on the information received from the SMF, the N3IWF can forward the information of established QoS Flows status (active) for QoS monitoring configuration for congestion information to the SMF through the AMF. If the N3IWF does not support the QoS monitoring configuration for congestion information operation, the N3IWF can forward the information of established QoS Flows status (inactive) for QoS monitoring configuration for congestion information to the SMF through the AMF. If the N3IWF does not support QoS monitoring configuration for congestion information operation and ECN marking for L4S, the SMF may determine that the QoS flow using the N3IWF does not support ECN marking operation considering L4S. The SMF may check the L4S support status information (e.g.Based on the established QoS Flows status (active / inactive) for QoS monitoring configuration for congestion information or established QoS Flows status (active / inactive) for ECN marking for L4S), it is possible to decide whether to accept a request for L4S service support for a specific UE's QoS flow delivered from AF.

[0144] In operation 526, if the SMF selects the ECN marking operation using NG-RAN based on the result of NF selection that performs the ECN marking operation to support L4S service, the SMF may forward N2 SM information including QoS flow information supporting L4S service and L4S support indicator information (ECN marking for L4S indicator) to the AMF. In operation 525, if the SMF selects the ECN marking operation using UPF or receives information from the N3IWF that the operation of directly marking congestion information in the IP header is not supported, the SMF may include the QoS flow information supporting L4S service and configuration information for congestion information QoS monitoring for receiving congestion information through the GTP-U extension header in the N2 SM information and forward it to the AMF through the Namf_Communication_N1N2MessageTransfer message.

[0145] At operation 527, the AMF may convey information related to PDU session establishment, such as QoS profile and related QFI, PDU session ID, PDU session Establishment Accept and / or L4S support indicator, to the N3IWF via an N2 PDU Session Request message.

[0146] In steps 528a and 528b, based on the decision of the SMF in step 525, the SMF may transmit to the UPF an N4 Session Establishment request message including N4 rules including packet detection rules of the UPF, etc. The UPF may transmit to the SMF an N4 Session Establishment request response message including CN Tunnel Info, etc. If the SMF determines to support L4S service using the UPF in step 525, the SMF may transmit to the UPF an N4 rule including QoS monitoring configuration information for receiving ECN marking operation and congestion information for ECN marking from the NG-RAN.

[0147] In operation 529a, the N3IWF may select an L4S support operation that is supported by the N3IWF based on the Capability of the N3IWF and / or an operation request message for L4S support requested by the SMF. If the SMF decides to perform an ECN marking operation to support L4S service using NG-RAN in operation 525 and only the ECN marking for L4S indicator is included in the N2 SM information delivered to the N3IWF through operations 526 and 527, the N3IWF may decide to perform operation 529b based on whether to accept the operation.

[0148] In one embodiment, if the SMF determines to perform an ECN marking operation to support a 4S service using UPF in operation 525 and the QoS monitoring configuration for congestion information is included in the N2 SM information transmitted to the N3IWF through operations 526 and 527, the N3IWF may determine to perform operation 529b depending on whether to accept the operation. If the N3IWF does not support both the congestion information monitoring operation and the ECN marking operation to support the L4S service, operations 529b and 530 may be omitted. Thereafter, the N3IWF may notify the SMF that it cannot support the L4S service for the corresponding QoS flow through operations 531 and 532.

[0149] In operation 529b, the N3IWF may decide to update the IPsec Child SA between the UE and the N3IWF based on the information received from the AMF. If existing QoS flows are being carried through an IPsec SA that does not support ECN / L4S, when the N3IWF receives a request for L4S service support, it may decide to associate a new IPsec SA that supports ECN / L4S for the corresponding QoS flow. For example, when five QoS flows that do not support L4S service are being carried through one IPsec SA#1 in the N3IWF, one of the QoS flows may be requested to provide an L4S service. The N3IWF may decide to create IPsec SA#2 for the QoS flow that supports one L4S service and update the QoS flow information requesting L4S service support from the existing IPsec SA#1 to IPsec SA#2. To this end, N3WIF can update QoS flow and Child SA mapping information by sending an INFORMATIONAL request message including QFI and Additional QoS information related to Child SA.

[0150] In operation 530, if the N3IWF decides to create a new IPsec child SA, it can perform a new IPsec SA establishment operation that supports the L4S service by transmitting the QFI, PDU session ID, etc. for the IPSEC child SA to the UE. In addition, if the N3IWF can support an operation for the L4S service through operation 529a, but the N3IWF does not have information on whether the terminal and the Non-3GPP Access Network support the L4S service, information for checking whether the terminal and the Non-3GPP Access Network support the L4S service can be transmitted to the terminal. The information for checking whether the L4S service is supported that is transmitted from the N3IWF to the terminal can include an ECN marking for the L4S indicator, etc. When the terminal receives an L4S support indicator for a specific QoS flow from the N3IWF, the terminal checks whether L4S is supported in the section between the terminal and the non-3gpp access or whether an IPsec child SA supporting L4S is created, and if it cannot determine whether L4S is supported separately, it can perform an operation to check whether L4S is supported in the uplink packet.

[0151] In operation 531 (531a and / or 531b), if a new IPsec Child SA supporting L4S service is established based on the N2 session request, the N3IWF may notify the AMF whether it accepts or supports the N3IWF operation request to support the L4S service. The N3IWF may include the established QoS Flows status (active / inactive) for QoS monitoring configuration for congestion information or the established QoS Flows status (active / inactive) for ECN marking for L4S information in the N2 SM information to notify the AMF whether it accepts or supports the N3IWF operation request to support the L4S service. If the creation of IPsec Child SA supporting L4S service in UE or Non 3gpp Access network is not supported through operation 530 or at least one entity among UE or Non 3gpp Access network does not support L4S function, N3IWF may forward N2 SM information including information including rejection or non-support of N3IWF operation request to support L4S service (established QoS Flows status (inactive) for QoS monitoring configuration for congestion information or established QoS Flows status (inactive) for ECN marking for L4S) to AMF.

[0152] From operation 532 (532a and / or 532b) to operation 533 (533a and / or 533b), the AMF may forward N2 SM information, including whether the request information for L4S service support was successful, to the SMF via a PDU session related SM context update (Nsmf_PDUSession_UpdateSMContext Request) message. If Qos flow information, etc. in the N2 SM information is updated, the SMF may forward it to the UPF via an N4 session change request operation. If the SMF receives information in the N2 SM information received from the NG-RAN via operation 532a that the N3IWF does not support the operation for supporting L4S service, the SMF may forward this to the AF via the PCF. In addition to the L4S support indicator information, the L4S service related requirement information forwarded from the AF to the PCF in operation 522 and operation 523 may include requirement information for requesting event reporting of the corresponding information to the AF when it is determined that the L4S service is not supported. In operation 524, the PCF may request the SMF to report to the PCF, through a Policy Control Request Trigger (PCRT), that the SMF has received from the N3IWF established QoS Flows status (inactive) for QoS monitoring configuration for congestion information and / or established QoS Flows status (inactive) for ECN marking for L4S information, that the L4S service support for the corresponding QoS flow is not supported.

[0153] In operation 534 (534a and / or 534b), if the SMF receives from the N3IWF that the L4S service for the corresponding QoS flow is not supported based on the information received from the N3IWF, the SMF may notify the PCF of the non-support for L4S service for the corresponding QoS flow through event reporting. The PCF may notify the AF of the non-support for L4S service for a specific QoS flow requested by the AF based on the event reporting message received from the SMF.

[0154] In operation 535, a non-3gpp access point (e.g., wifi) may be added between the UE and the N3IWF. The UE may transmit and receive data through the non-3gpp access point with the N3IWF. In this case, the IP header and payload transmitted to the existing N3IWF may be defined as an inner IP packet in relation to the IPsec structure. In IPsec Tunnel mode, an additional outer IP packet including the inner IP packet in the payload may be defined. That is, in the IPsec SA section, an outer IP packet may be generated and transmitted to the UE through the non-3gpp access point.

[0155] In operation 535a, when downlink data is transmitted to the N3IWF, the N3IWF can perform the operation transmitted through the SMF. When downlink data is transmitted from the UPF, if congestion occurs in the N3IWF or if congestion occurs before the N3IWF, the N3IWF can perform CE marking on the corresponding ECN bit of the Inner IP header, or receive an IP packet with CE marked on the ECN bit and transmit it to the UE as an Inner packet. In addition, when congestion occurs in a non-3gpp access network, the N3IWF can mark the corresponding congestion information on the ECN bit of the Outer packet header and transmit it to the UE.

[0156] In operation 535b, the UE that has received the downlink data can generate congestion information by distinguishing whether the congestion situation is a congestion situation in a non-3gpp access section or a congestion situation that occurred within 5GC, and can transmit this to AF so that queue management can be performed according to each situation.

[0157] In operation 536, when the congestion situation of the Non-3gpp access section is marked and transmitted through the outer header during uplink data transmission, the N3IWF may determine to generate congestion information based on the ECN bit information of the header of the outer header, based on information generated in the Non-3gpp access network. With respect to the marking method of the congestion information, the N3IWF may perform marking based on the matters decided by the SMF in operation 525. In addition, based on the matters decided by the SMF in operation 525, the N3IWF may transmit the congestion information to the UPF, and the UPF may perform marking.

[0158] FIG. 6 illustrates an example of the functional structure of a terminal (600) according to one embodiment of the present disclosure. Terms such as "unit" and "unit" used hereinafter refer to a unit that processes at least one function or operation, which may be implemented using hardware, software, or a combination of hardware and software. The terminal of FIG. 6 may correspond to the UE (user equipment) depicted in FIGS. 1 to 5 .

[0159] Referring to FIG. 6, the terminal may include a communication unit (605), a storage unit (610), and a control unit (615).

[0160] The communication unit (605) can perform functions for transmitting and receiving signals via a wireless channel. For example, the communication unit (605) can perform a conversion function between a baseband signal and a bit stream according to the physical layer specifications of the system. For example, when transmitting data, the communication unit (605) can generate complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the communication unit (605) can restore a reception bit stream by demodulating and decoding a baseband signal. In addition, the communication unit (605) can upconvert a baseband signal to an RF band signal and transmit it through an antenna, and downconvert an RF band signal received through the 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, an ADC, etc.

[0161] In addition, the communication unit (605) may include a plurality of transmit / receive paths. Furthermore, the communication unit (605) may include at least one antenna array composed of a plurality of antenna elements. In terms of hardware, the communication unit (605) may be composed of digital circuits and analog circuits (e.g., radio frequency integrated circuits (RFIC)). Here, the digital circuits and analog circuits may be implemented in a single package. In addition, the communication unit (605) may include a plurality of RF chains. Furthermore, the communication unit (605) may perform beamforming.

[0162] The communication unit (605) can transmit and receive signals as described above. Accordingly, all or part of the communication unit (605) may be referred to as a "transmitter," a "receiver," or a "transmitting and receiving unit." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that processing as described above is performed by the communication unit (605).

[0163] The storage unit (610) can store data such as basic programs, application programs, and setting information for the operation of the terminal. The storage unit (610) can be composed of volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. In addition, the storage unit (610) can provide stored data upon request from the control unit (615).

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

[0165] According to various embodiments of the present disclosure, a terminal may be composed of a mobile equipment (ME) and a universal mobile telecommunications service (UMTS) subscriber identity module (USIM). The ME may include a mobile terminal (MT) and terminal equipment (TE). The MT may be a part where a wireless access protocol operates, and the TE may be a part where a control function operates. For example, in the case of a wireless communication terminal (e.g., a mobile phone), the MT and the TE may be integrated, and in the case of a laptop, the MT and the TE may be separate. In the present disclosure, depending on the operation of each component, the ME and the USIM may be expressed as distinct entities, but the present disclosure is not limited thereto, and various embodiments of the present disclosure may be described by expressing the ME and the USIM as a terminal (e.g., UE), or by expressing the ME as a terminal.

[0166] FIG. 7 illustrates an example of the functional structure of a network entity (700) according to one embodiment of the present disclosure. It illustrates components of a network entity in a wireless communication system according to various embodiments of the present disclosure. Terms such as "... unit" and "... unit" used hereinafter mean a unit that processes at least one function or operation, which may be implemented by hardware, software, or a combination of hardware and software. The network entity of FIG. 7 may correspond to the network entities or network functions described in FIGS. 1 to 5 .

[0167] Referring to FIG. 7, a network entity (700) according to one embodiment of the present disclosure may be configured to include a communication unit (705), a storage unit (710), and a control unit (715).

[0168] The communication unit (705) may provide an interface for communicating with other devices within the network. That is, the communication unit (705) may convert a bit string transmitted from a network entity to another device into a physical signal, and may convert a physical signal received from another device into a bit string. That is, the communication unit (705) may transmit and receive signals. Accordingly, the communication unit (705) may be referred to as a modem, a transmitter, a receiver, or a transceiver. In this case, the communication unit (705) may 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 the network.

[0169] The storage unit (710) can store data such as basic programs, application programs, and configuration information for the operation of core network objects. The storage unit (710) can be configured with volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. In addition, the storage unit (710) can provide stored data upon request from the control unit (715).

[0170] The control unit (715) can control the overall operations of the network entity. For example, the control unit (715) can transmit and receive signals through the communication unit (705). In addition, the control unit (715) can record and read data from the storage unit (710). For this purpose, the control unit (715) can include at least one processor. According to various embodiments of the present disclosure, the control unit (715) can control synchronization using a wireless communication network. For example, the control unit (715) can control the core network object to perform operations according to various embodiments described below.

[0171] The terms used in the description of one embodiment of the present disclosure to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, and the like are provided for convenience of explanation. Therefore, the present disclosure is not limited to these terms, and other terms referring to objects with equivalent technical meanings may be used.

[0172] The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0173] When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are 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 methods according to the embodiments described in the claims or specification of the present disclosure.

[0174] These programs (software modules, software) may be stored in a non-volatile memory including random access memory, flash memory, read only memory (ROM), electrically erasable programmable read only memory (EEPROM), magnetic disc storage devices, compact disc ROMs (CD-ROMs), digital versatile discs (DVDs) or other forms of optical storage devices, magnetic cassettes, or may be stored in a memory configured as a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

[0175] Additionally, the program may be stored on an attachable storage device that is accessible via a communication network such as the Internet, an intranet, a local area network (LAN), a wide local area network (WLAN), a storage area network (SAN), or a combination thereof. Such a storage device may be connected to a device implementing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communication network may be connected to a device implementing an embodiment of the present disclosure.

[0176] In the specific embodiments of the present disclosure described above, components included in the present disclosure are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0177] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

Claims

1. A method performed by an N3IWF (non-3GPP interworking function) entity of a wireless communication system, A step of receiving session management information including an ECN (explicit congestion notification) marking instruction for supporting L4S (low latency, low loss and scalable throughput) in non-3GPP access from an SMF (session management function) entity via an AMF (access and mobility management function) entity; A step for determining the connection of an IPsec (internet protocol security) Child SA (security association) for a QoS (quality of service) flow supporting the above L4S; A step of transmitting a message to the terminal to request the IPsec Child SA connection; method.

2. In paragraph 1, The above session management information includes a PDU (protocol data unit) session ID, and at least one of a QFI (QoS flow ID) or a QoS profile. method.

3. In paragraph 1, The message includes at least one of the PDU session ID, the QFI, a differentiated services field codepoint (DSCP) value, or additional QoS information. method.

4. In paragraph 1, The above session management information is included in the N2 PDU session request message, The above message contains an IKE CREATE CHILD SA request message. method.

5. In paragraph 4, Further comprising the step of transmitting an N2 PDU session response message including information on whether the IPsec Child SA connection was successful to the AMF entity; The above N2 PDU session response message further includes information about the status of the QoS flow. method.

6. A method performed by a user terminal of a wireless communication system, A step of receiving a first message requesting an IPsec (internet protocol security) Child SA (security association) connection for a QoS (quality of service) flow supporting L4S (low latency, low loss and scalable throughput) from an N3IWF (non-3GPP interworking function) entity; and A step of transmitting a second message for response to the first message to the N3IWF entity, method.

7. In paragraph 6, The first message further includes at least one of a PDU (protocol data unit) session ID, the QFI (QoS flow ID), a DSCP (differentiated services field codepoint) value, or additional QoS (quality of service) information. method.

8. In paragraph 6, The first message above includes an IKE CREATE CHILD SA request message, method.

9. For the N3IWF (non-3GPP interworking function) entity of the wireless communication system, Transmitter and receiver; and Including a control unit connected to the above transmitter and receiver, The above control unit: Receive session management information including an ECN (explicit congestion notification) marking indication for supporting L4S (low latency, low loss and scalable throughput) in non-3GPP access from an SMF (session management function) entity via an AMF (access and mobility management function) entity; Determine an IPsec (internet protocol security) Child SA (security association) connection for a QoS (quality of service) flow supporting the above L4S; and It is set to transmit a message to the terminal to request the IPsec Child SA connection. N3IWF entity.

10. In paragraph 9, The above session management information includes a PDU (protocol data unit) session ID, and at least one of a QFI (QoS flow ID) or a QoS profile. N3IWF entity.

11. In paragraph 9, The message includes at least one of the PDU session ID, the QFI, a differentiated services field codepoint (DSCP) value, or additional QoS information. N3IWF entity.

12. In paragraph 9, The above session management information is included in the N2 PDU session request message, The above message contains an IKE CREATE CHILD SA request message. N3IWF entity.

13. In paragraph 9, The control unit is further configured to transmit an N2 PDU session response message including information on whether the IPsec Child SA connection is successful to the AMF entity, The above N2 PDU session response message further includes information about the status of the QoS flow. N3IWF entity.

14. In the terminal of a wireless communication system, Transmitter and receiver; and Including a control unit connected to the above transmitter and receiver, The above control unit: Receive a first message requesting an IPsec (internet protocol security) Child SA (security association) connection for a QoS (quality of service) flow supporting L4S (low latency, low loss and scalable throughput) from an N3IWF (non-3GPP interworking function) entity; and Set to transmit a second message to the above N3IWF entity in response to the above first message, Terminal.

15. In paragraph 14, The above first message includes an IKE CREATE CHILD SA request message, The above IKE CREATE CHILD SA request message further includes at least one of a PDU (packet data unit) session ID, the QFI (QoS flow ID), a DSCP (differentiated services field codepoint) value, or additional QoS (quality of service) information. Terminal.

Images