Method and apparatus for providing access traffic steering functionality in a wireless communication system

Abstract

The present disclosure relates to a communication technique and system for converging a 5G communication system with IoT technology to support a higher data transmission rate after the 4G system. The present disclosure can be applied to intelligent services (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, healthcare, digital education, retail, security and safety related services) based on 5G communication technology and IoT related technology. In a wireless communication system according to an embodiment of the present disclosure, when a UE registers with an AMF that does not support ATSSS (registration procedure), a method in which an existing AMF checks this and releases an existing MA PDU Session and a method in which a UE checks this and releases an existing MA PDU Session are proposed.

Description

Technical Field

[0001] The present disclosure relates to a method and an apparatus for providing an access traffic steering function (Access Traffic Steering, Switching, Splitting (ATSSS)) in a wireless communication system.

Background Art

[0002] Efforts are being made to develop improved 5G or pre-5G communication systems to meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems. For this reason, 5G or pre-5G communication systems are also called Beyond 4G Network communication systems or Post LTE systems. To achieve high data transmission rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands (e.g., 60 GHz bands). To mitigate path loss and increase transmission distance in ultra-high frequency bands, beamforming, massive MIMO (Multiple-Input Multiple-Output), FD-MIMO (Full Dimensional MIMO), array antennas, analog beamforming, and large-scale antenna technologies are being discussed for 5G communication systems. Furthermore, to improve the system's network, 5G communication systems are undergoing technological development, including advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, D2D (device-to-device) communication, wireless backhaul, moving networks, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation.In addition, 5G systems have seen the development of advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), as well as advanced connectivity technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access).

[0003] Meanwhile, the internet is evolving from a human-centered network where humans generate and consume information to an IoT (Internet of Things) network where information is exchanged and processed between distributed components such as objects. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technologies through connections to cloud servers and other systems, is also emerging. To realize IoT, technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required. In recent years, technologies such as sensor networks, M2M (Machine to Machine), and MTC (Machine Type Communication) for connecting things have been researched. In an IoT environment, intelligent IT (Internet Technology) services can be provided that collect and analyze data generated between connected objects to create new value in human life. IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services through convergence and integration with existing IT (information technology) technologies and various industries.

[0004] As a result, various attempts are being made to apply 5G communication systems to IoT networks. For example, 5G communication technologies such as sensor networks, M2M (Machine to Machine), and MTC (Machine Type Communication) can be realized through techniques such as beamforming, MIMO, and array antennas. The application of cloud radio access networks (cloud RAN) as a big data processing technology can also be seen as an example of the convergence of 5G and IoT technologies.

[0005] 5G communication systems support connectivity with various access networks such as NR (new radio), Wireless LAN, and Wired LAN. Access Traffic Steering (ATSSS) technology, which enables traffic transmission using different access networks, is currently under development.

[0006] The information described above is provided solely as background information to aid in understanding this disclosure. No determination was made, and no claims were made, regarding which of the above can be applied as prior art in relation to this disclosure. [Overview of the Initiative] [Problems that the invention aims to solve]

[0007] In current 3GPP® standard communication systems, ATSSS requires that the UE (User Equipment), AMF (Access and Mobility Management Function), SMF (Session Management Function), and UPF (User Plane Function) support these functions. Assuming a scenario where a UE has established one or more MA PDU (Multi Access Packet Data Unit) sessions via an existing AMF, and then registers with a new AMF due to terminal relocation, if the new AMF does not support ATSSS, the MA PDU session for that access must be released. Currently, there is no technology to release such MA PDU sessions, and this disclosure proposes a method and apparatus to solve this problem. [Means for solving the problem]

[0008] In a wireless communication system according to one embodiment of the present disclosure, when a UE (User Equipment) registers with an AMF (Access and Mobility Management Function) that does not support ATSSS (registration procedure), an existing registered AMF can verify this and release the existing MA PDU Session, or the UE can verify this and release the existing MA PDU Session.

[0009] According to one embodiment of the present disclosure, a method for a first access and mobility management function (AMF) entity in a first wireless communication system is provided. The method includes the steps of: receiving a first message containing information about supported features of a second AMF entity; determining, based on the information, whether the second AMF entity supports access traffic steering, switching, splitting (ATSSS) functionality; the second AMF entity sending a second message containing user equipment (UE) context - if the second AMF does not support the ATSSS functionality, the UE context does not contain context for a multi-access packet data unit (MA PDU) session - and the session management function (SMF) entity sending a third message requesting the release of the MA PDU session, wherein the MA PDU session is released based on the third message.

[0010] The method described above is characterized in that the first message is received from the second AMF entity and is a message requesting the second AMF entity to transmit the UE context stored in the first AMF entity.

[0011] The method described above is characterized in that the first message is provided by a network repository function (NRF) entity, the first AMF entity is a source AMF entity related to the handover, and the second AMF entity is a target AMF entity related to the handover.

[0012] The method further includes the step of receiving a fourth message from the second AMF entity indicating that the handover was successful, wherein the third message is transmitted after the fourth message has been received.

[0013] The method described above is characterized in that the first message includes the network function (NF) profile of the second AMF entity, and the NF profile includes the information described above.

[0014] In another embodiment of the present disclosure, a first access and mobility management function (AMF) entity is provided in a wireless communication system. The first AMF entity includes a transceiver unit that transmits and receives signals, and a control unit coupled with the transceiver unit that receives a first message containing information about supported features of a second AMF entity, and based on the information determines whether the second AMF entity supports access traffic steering, switching, and splitting (ATSSS) functionality, and that the second AMF entity transmits a second message containing user equipment (UE) context - if the second AMF does not support the ATSSS functionality, the UE context does not contain context for a multi-access packet data unit (MA PDU) session - and a control unit that controls a session management function (SMF) entity to transmit a third message requesting the release of the MA PDU session, wherein the MA PDU session is released based on the third message.

[0015] Another embodiment of the present disclosure provides a method for a session management function (SMF) entity in a wireless communication system. The method includes the steps of: receiving a first message from a first access and mobility management function (AMF) entity to request the release of a multi-access packet data unit (MA PDU) session based on information about supported features of a second AMF entity; and releasing the MA PDU session based on the first message, wherein the information indicates whether the second AMF entity supports access traffic steering, switching, splitting (ATSSS) functionality; and if the second AMF does not support the ATSSS functionality based on the information, a second message including user equipment (UE) context is transmitted by the second AMF entity, wherein the UE context does not include context for the MA PDU session.

[0016] In another embodiment of the present disclosure, a session management function (SMF) entity is provided in a wireless communication system. The SMF includes a transceiver unit that transmits and receives signals, and a control unit coupled to the transceiver unit that controls the SMF to receive a first message requesting the release of a multi-access packet data unit (MA PDU) session based on information from a first access and mobility management function (AMF) entity to a second AMF entity, and controls the SMF to release the MA PDU session based on the first message, wherein the information indicates whether the second AMF entity supports access traffic steering, switching, splitting (ATSSS) functionality, and if the second AMF does not support the ATSSS functionality based on the information, a second message including user equipment (UE) context is transmitted by the second AMF entity, wherein the UE context does not include context for the MA PDU session. [Effects of the Invention]

[0017] This disclosure supports various methods for releasing MA PDU Sessions that are not supported by 3GPP® 5G systems. Based on the embodiments of this disclosure, existing MA PDU Sessions can be efficiently released when registering with an AMF that does not support ATSSS. [Brief explanation of the drawing]

[0018] For a more complete understanding of this disclosure and its merits, refer to the following description in conjunction with the attached drawings. Identifying reference numbers indicate the same part.

[0019] [Figure 1]This is a diagram illustrating the system architecture that supports ATSSS in a 3GPP(registered trademark) 5G system. [Figure 2] This diagram illustrates the problem that this disclosure aims to solve. [Figure 3] This is a sequence diagram showing the procedure by which an existing AMF releases an existing MA PDU Session based on the Update SM Context service. [Figure 4] This is a sequence diagram showing the procedure by which an existing AMF releases an existing MA PDU Session based on the Release SM Context service. [Figure 5] This is a sequence diagram illustrating the procedure for releasing an existing MA PDU Session based on a PDU Session release request that includes a specific Request Type in the UE. [Figure 6] This is a sequence diagram showing the procedure for releasing an existing MA PDU Session based on a UE PDU Session release request. [Figure 7] This is a sequence diagram showing the procedure for a UE to release an existing MA PDU Session via a local release. [Figure 8] This sequence diagram shows the procedure by which the existing AMF releases existing MA PDU sessions based on the Update SM Context service when the AMF is changed via N2 handover. [Figure 9] This diagram illustrates how, when a UE submits a registration request in an AMF that does not support ATSSS, the existing AMF releases the MA PDU Session after confirming that the UE has successfully registered in the new AMF. [Figure 10]When the UE's AMF changes to a new AMF that does not support ATSSS during the handover execution of the N2 infrastructure, this is a drawing showing the method for the existing AMF (S-AMF) to release the MA PDU Session after receiving a message indicating that the handover to the UE from the new AMF has been successful. [Figure 11] This is a block diagram showing the structure of a terminal (UE) according to an embodiment of the present disclosure. [Figure 12] This is a block diagram showing the structure of a higher-level node according to an embodiment of the present disclosure.

Mode for Carrying Out the Invention

[0020] Before proceeding with the following detailed description, it is necessary to define certain words and phrases used throughout this patent specification. The term "including" and its derivatives mean including without limitation. The term "or" has an inclusive meaning. And / or The terms "associated with" and "related to" and their derivatives mean "including", "contained within", "interconnected with", "containing", "contained in", "connected to or with", "coupled to or with", "communicable with", "cooperating with", "interleaving", "juxtaposing", "approaching", "bounded by or with", "having", "owning", "having a relationship with or to", etc. The term "control unit" means any device, system or part thereof that controls at least one operation. That is, the device can be implemented in hardware, firmware or software, or a combination of at least two of these. The functions related to any specific control unit can be centralized or distributed regardless of whether they are local or remote.

[0021] Furthermore, the various functions described below can be embodied or supported by one or more computer programs, each formed in computer-readable program code and embodied in a computer-readable medium. The terms “application” and “program” refer to one or more computer programs, software components, a set of instructions, procedures, functions, objects, classes, instances, associated data, or parts thereof configured to be embodied in a suitable computer-readable program. The phrase “computer-readable program code” includes all types of computer code, including source code, purpose code, and executable code. The phrase “computer-readable medium” includes any type of medium that can be accessed by a computer, such as ROM (Read Only Memory), RAM (Random Access Memory), hard disk drives, CDs (Compact Discs), digital video discs (DVDs), or other types of memory. “Non-temporary” computer-readable medium excludes wired, wireless, optical, or other communication links that transmit temporary electrical or other signals. Non-temporary computer-readable media include media on which data is stored permanently, and media on which data is stored and later overwritten, such as re-recordable optical discs or erasable memory devices.

[0022] Definitions of other specific words and phrases are provided throughout this patent document. While it is not always the case, an ordinary person of the art should understand that these definitions apply to the prior and subsequent use of such defined words and phrases.

[0023] Figures 1 through 12 discussed below, and the various embodiments used in this patent document to illustrate the principles of the disclosure, are for illustrative purposes only and should not be construed in any way as to limit the scope of the disclosure. A person of ordinary skill will understand that the principles of the disclosure can be embodied in any system or device that is appropriately configured.

[0024] In describing the examples in this specification, explanations of technical content that is well known in the art to which this disclosure belongs and is not directly related to this disclosure will be omitted. This is to clarify and more clearly communicate the gist of this disclosure by omitting unnecessary explanations.

[0025] For similar reasons, some components in the attached drawings are exaggerated, omitted, or only schematically represented. Furthermore, the sizes of each component do not fully reflect their actual dimensions. The same or corresponding components are assigned the same reference number in each drawing.

[0026] The advantages and features of this disclosure, and how they are achieved, will become clear from the examples described below in detail with the accompanying drawings. However, this disclosure is not limited to the examples disclosed below and can be embodied in a variety of different forms, and these examples are provided only to complete the disclosure and to fully inform those who are ordinary skill in the art to which the disclosure pertains, and the disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same component.

[0027] At this point, it can be understood that the combination of each block in the processing flowchart and the flowchart diagram can be performed by computer program instructions. Since these computer program instructions can be implemented on the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions, delivered via the processor of the computer or other programmable data processing equipment, will generate means for performing the functions described in the flowchart blocks. Since these computer program instructions can also be stored in computer-available or computer-readable memory that can direct the computer or other programmable data processing equipment to embody the functions in a particular manner, the instructions stored in such computer-available or computer-readable memory can also produce manufactured items that contain instruction means for performing the functions described in the flowchart blocks. Since computer program instructions can also be implemented on a computer or other programmable data processing equipment, the instructions, which perform a series of operational steps on the computer or other programmable data processing equipment and generate processes to be executed on the computer, can also provide steps for performing the functions described in the flowchart blocks.

[0028] Furthermore, each block may represent a module, segment, or portion of code containing one or more executable instructions for performing a specified logical function. It should also be noted that in some alternative execution examples, the functions mentioned in a block may occur out of order. For example, two adjacent blocks may actually be performed substantially simultaneously, or they may sometimes be performed in reverse order by the functions in question.

[0029] In this embodiment, the term "~part" refers to software or hardware components such as FPGAs or ASICs, and the role that "~part" plays is not limited to software or hardware. "~part" can also be configured to reside in an addressable storage medium, or to regenerate one or more processors. Thus, as an example, "~part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided by the components and "~part" can be combined with a smaller number of components and "~part," or further separated with additional components and "~part." In addition, components and "~part" can also be embodied to regenerate one or more CPUs within a device or security multimedia card.

[0030] The following relates to methods and apparatus for supporting various services in the wireless communication system described herein. Specifically, this disclosure describes a technology for providing Access Traffic Steering, Switching, and Splitting (ATSSS) in a wireless communication system.

[0031] The terms used below to identify connected nodes, network entities or network functions (NFs), messages, interfaces between network entities, and various forms of identification information are provided as examples for the sake of clarity. Therefore, this disclosure is not limited to the terms described below, and other terms with equivalent technical meanings may be used.

[0032] Figure 1 is a diagram illustrating a system architecture for supporting ATSSS (Access Traffic Steering, Switching, Splitting) in a 3GPP® 5G system. By utilizing the ATSSS function, it is possible to transmit traffic through multiple paths (e.g., 3GPP® Access 110 and Non-3GPP® Access 120) between the PDU (Protocol Data Unit or Packet Data Unit), Session Anchor UPF (User Plane Function, 104), and UE (User Equipment, 101), as shown in Figure 1. On the other hand, in order to use ATSSS, the UE (User Equipment, 101), AMF (Access and Mobility Management Function, 102), SMF (Session Management Function, 103), and UPF (User Plane Function, 104) must support ATSSS.

[0033] Figure 2 is a diagram illustrating the problem that this disclosure aims to solve. Figure 2 shows a situation where UE210 has established one or more MA PDU Sessions via an existing AMF (old AMF, 211) and registers with a new AMF (new AMF, 212) via terminal movement 200, etc. Assuming that the new AMF (new AMF, 212) does not support ATSSS (i.e., an ATSSS-incapable AMF), the existing AMF (old AMF, 211) will send the context for the existing MA PDU Session to the new AMF via UE Context Transfer (202). At this time, if there are MA PDU Sessions that are not released despite the new AMF not supporting ATSSS, unpredictable behavior may occur. Therefore, for efficient operation of MA PDU Sessions, the MA PDU Session for the access in question must always be released. Currently, there is no technology for releasing such MA PDU Sessions, and this disclosure proposes a method and apparatus to solve this problem.

[0034] Figure 3 is a diagram illustrating how, according to one embodiment of this disclosure, an existing AMF (old AMF) releases an existing MA PDU Session via UpdateSMContext when a UE registers with a new AMF that does not support ATSSS.

[0035] Referring to Figure 3, in step 301, in order to proceed with the registration procedure for the New AMF, the UE can send a Registration request message to the New AMF (steps 1-3). Specifically, the UE sends an AN message containing the Registration Request message to the Access Node (AN) (step 1), the AN receives this and determines the AMF (step 2), and can then send an N2 message containing the Registration Request message to the determined AMF (i.e., the New AMF) (step 3).

[0036] At stage 304, the New AMF can send a Namf_Communication_UEContextTransfer Request message to the Old AMF.

[0037] In this case, the message may include the UE's Access Type and supported features. If the New AMF does not support ATSSS, the supported features will not include the MA PDU Session support indicator.

[0038] In step 305, if the Old AMF determines that the New AMF does not support ATSSS, it checks if an MA PDU Session exists in the UE Context for the Access Type received in step 304. If an MA PDU Session exists for the received Access Type, the Old AMF can instruct the SMF to release the MA PDU Session for that Access Type. Specifically, the Old AMF can send an Nsmf_PDUSession_UpdateSMContext Request message to the SMF. The Nsmf_PDUSession_UpdateSMContext Request message can include information such as the SM Context ID, Release indication, and access for MA PDU session release. In this case, the SM Context ID is an internal Context identifier for the MA PDU Session ID that must be released and is shared between the AMF and SMF. The Release indication is an indicator that it is a release request, and access for MA PDU Session release indicates the Access Type that must be released.

[0039] At this time, Old AMF can determine whether New AMF supports ATSSS based on the following: 1) the MA PDU Session support indicator in the supported feature field or parameter included in the request message of stage 304, 2) the MA PDU Session support indicator in the supported features of the NF Profile for New AMF stored in NRF (Network Repository Function), and 3) the AMF's local configuration.

[0040] In stage 306, upon receiving the message from AMF in stage 305, SMF decides, via its local policy, whether to release the MA PDU Session mapped to the SM Context ID only to the access type that received it, or to all access. Based on this decision, SMF can instruct UPF to release the MA PDU Session to one access or to all access.

[0041] In step 307, the SMF sends an Nsmf_PDUSession_UpdateSMContext Response message in Old AMF containing the result of the request in step 305.

[0042] In stage 308, even if the Response message from the SMF contains a message requesting transmission to the UE or AN, the Old AMF does not perform any actions such as transmission (308-1). In response to the request message in stage 304, the Old AMF sends the UE Context to the New AMF (308-2).

[0043] At this time, the Old AMF does not include the context for the MA PDU Session that was successfully released from the SMF in the UE Context that it sends to the New AMF.

[0044] In step 309, the remaining registration steps for the UE are performed. If the MA PDU Session Context that was missing in the UE Context received in step 308 exists in the UE, the UE can perform a local release of the MA PDU Session that exists only in itself through the synchronization process with the New AMF.

[0045] Figure 4 shows how, according to one embodiment of this disclosure, an existing AMF (old AMF) releases an existing MA PDU Session via ReleaseSMContext when a UE registers with a new AMF that does not support ATSSS.

[0046] Referring to Figure 4, in step 401, the UE can send a Registration request message to the New AMF to proceed with the registration procedure for the New AMF (steps 1-3). Specifically, the UE sends an AN message containing the Registration Request message to the Access Node (AN) (step 1), the AN receives this message, determines the AMF (step 2), and can then send an N2 message containing the Registration Request message to the determined AMF (i.e., the New AMF) (step 3).

[0047] At stage 404, the New AMF can send a Namf_Communication_UEContextTransfer Request message to the Old AMF. This message can include the UE's Access Type and supported features. If the New AMF does not support ATSSS, the supported features will not include the MA PDU Session support indicator.

[0048] In stage 405, if Old AMF determines that New AMF does not support ATSSS, it checks if an MA PDU Session for the Access Type received in stage 404 exists within the UE Context. If an MA PDU Session for the Access Type exists, Old AMF can instruct SMF to release the MA PDU Session for the Access Type.

[0049] Specifically, Old AMF can send an Nsmf_PDUSession_Release Request message to SMF. The Nsmf_PDUSession_Release Request message can include information such as the SM Context ID and access for MA PDU session release. In this case, the SM Context ID is an internal context identifier for the MA PDU Session ID that must be released, and is shared between AMF and SMF. "access for MA PDU Session release" indicates the Access Type that must be released.

[0050] At this time, the Old AMF can determine whether the New AMF supports ATSSS based on the following: 1) the MA PDU Session support indicator in the supported features included in the stage 404 request message, 2) the MA PDU Session support indicator in the supported features of the NF Profile for the New AMF stored in the NRF (Network Repository Function), and 3) the AMF's local configuration.

[0051] In stage 406, upon receiving the stage 405 message from the AMF, the SMF decides, via its local policy, whether to release the MA PDU Session mapped to the SM Context ID only to the access type that received it, or to all access. Based on this decision, the SMF can instruct the UPF to release the MA PDU Session to one access or to all access.

[0052] In stage 407, SMF sends an Nsmf_PDUSession_ReleaseSMContext Response containing the result of the request in stage 405.

[0053] In stage 408, the Old AMF sends the UE Context to the New AMF in response to the request message in stage 404.

[0054] At this time, the Old AMF does not include the context for the MA PDU Session that was successfully released from the SMF in the UE Context that it sends to the New AMF.

[0055] In step 409, the remaining registration steps for the UE are performed. If the UE has a missing MA PDU Session Context from the UE Context received in step 408, the UE can perform a local release of the MA PDU Session that exists only for itself through the synchronization process with the New AMF.

[0056] Figure 5 illustrates an MA PDU Session release scheme through an MA PDU Session release request including a specific Request Type for the UE, when the UE registers with a new AMF that does not support ATSSS, according to one embodiment of the present disclosure.

[0057] At stage 500, the UE can perform the registration procedure for the New AMF. The registration procedure for the New AMF can be performed in the same way as the registration procedure for the New AMF in the embodiments shown in Figures 3 and 4 above.

[0058] In stage 501, if the Registration Accept message does not contain an MA PDU Session Support Indicator, and the PDU Session Status of the Registration Accept message contains a PDU Session ID for the Access type that received the Registration Accept message (501-1), the UE can send a PDU Session Release Request message containing the PDU Session ID and Request Type to a New AMF for all applicable PDU Session IDs (501-2).

[0059] In this case, Release Type is used to indicate the Access Type that the UE wants to release. If the UE only wants to release MA PDU Sessions for Access Types that have received a Registration Accept message, Release Type will indicate those Access Types. If the UE wants to release MA PDU Sessions for all Access, Release Type can be set to an indicator requesting all Access releases.

[0060] In step 502, the New AMF can communicate the N1 SM Container received from the terminal to the SMF via the Nsmf_PDUSession_UpdateSMContext request message. At this time, it sends the SM Context ID, which is mapped to the PDU Session ID.

[0061] In stage 503, if the received Release Type requests a release for all Access, the SMF fully releases the MA PDU Session. On the other hand, if the Release Type specifies only one Access Type, the SMF can decide via local policy whether to release the MA PDU Session, which is mapped to the SM Context ID, only for the receiving access type or for all access.

[0062] In step 504, if the decision in step 503 is to delete only one Access Type, the SMF instructs the UE, Access Network (AN), and UPF to release an MA PDU Session for that Access Type.

[0063] On the other hand, if the decision in stage 503 is to delete all Access Types, the SMF instructs the UE, Access Network (AN), and UPF to release MA PDU Sessions for all Access Types.

[0064] Figure 6 shows a 5sion release scheme according to one embodiment of this disclosure when a UE registers with a new AMF that does not support ATSSS.

[0065] In step 600, the UE performs the registration procedure for the New AMF. The registration procedure for the New AMF can be performed in the same way as the registration procedure for the New AMF in the embodiments shown in Figures 3 and 4 above.

[0066] In stage 601, if the Registration Accept message does not contain an MA PDU Session Support Indicator, and the PDU Session Status of the Registration Accept message contains a PDU Session ID for an MA PDU Session for the Access type that received the Registration Accept message (601-1), the UE sends a PDU Session Release Request message to the AMF for all applicable PDU Session IDs, including the PDU Session ID (601-2).

[0067] In step 602, the New AMF can communicate the N1 SM Container received from the terminal to the SMF via the Nsmf_PDUSession_UpdateSMContext request message. This message includes the SM Context ID, which is mapped to the PDU Session ID.

[0068] In stage 603, SMF instructs the release of MA PDU Sessions for all Access Types.

[0069] Figure 7 is a sequence diagram illustrating the procedure by which a UE releases an existing MA PDU Session via a local release according to one embodiment of the present disclosure.

[0070] At stage 700, the UE performs the registration procedure for the New AMF. If the Registration Accept message does not include the MA PDU Session Support Indicator, and a PDU Session ID for an MA PDU Session exists for the Access type that received the Registration Accept message, the UE can perform a local release for all relevant PDU Session IDs.

[0071] In stage 701, if the UE performed a local release to the MA PDU Session in stage 700, it can initiate a Service Request procedure. At this time, the PDU Session Status will not include the PDU Session ID of the MA PDU Session released in stage 700.

[0072] In step 702, the New AMF can transmit the N1 SM Container received from the terminal to the SMF via the Nsmf_PDUSession_ReleaseSMContext request message. At this time, it sends the SM Context ID which is mapped to the PDU Session ID.

[0073] In stage 703, SMF can perform MA PDU Session releases for all Access Types.

[0074] Figure 8 shows how, in one embodiment of this disclosure, when the UE's AMF is changed to a new AMF that does not support ATSSS during an N2 infrastructure handover, the existing AMF (old AMF) releases the existing MA PDU Session via UpdateSMContext.

[0075] Referring to Figure 8, the N2 handover procedure can be performed in step 801. The existing RAN of the UE (i.e., source RAN, S-RAN) can send a Handover Required message along with the Target ID to the existing AMF (i.e., Old AMF or source AMF, S-AMF).

[0076] At stage 802, if it is determined that the Old AMF can no longer support the UE, the Old AMF can perform AMF discovery / selection to select a new AMF (i.e., New AMF, target AMF, or T-AMF). At this time, the Old AMF can perform AMF discovery / selection through the Network Repository Function (NRF) or through the AMF local configuration.

[0077] In stage 803a, if AMF discovery / selection is possible through the NRF, the Old AMF can send an Nnrf_NFDiscovery Request message to the NRF. This message can contain various query parameters for searching for new AMFs, and the NF Type parameter can be set to AMF before being sent.

[0078] In stage 803b, the NRF can select a new AMF and send its NF Profile in Old AMF. At this time, the NF Profile includes supported features for the NF Services provided by the AMF (e.g., Namf_Communication). In this supported features, it includes whether or not ATSSS is supported (i.e., MA PDU).

[0079] In step 804, if the Old AMF does not find the MA PDU parameter in the supportedFeatures of the message received in step 803b, it can determine that the New AMF does not support ATSSS and proceed to step 805.

[0080] At stage 805, if the Old AMF determines that the New AMF does not support ATSSS, it checks if an MA PDU Session Context exists within its UE Context. If an MA PDU Session Context exists within the UE Context, the Old AMF can instruct the SMF to release the MA PDU Session. Specifically, the Old AMF can send an Nsmf_PDUSession_UpdateSMContext Request message to the SMF. The Nsmf_PDUSession_UpdateSMContext Request message can include information such as the SM Context ID, Release indication, and access for MA PDU session release. In this case, the SM Context ID is an internal Context identifier for the MA PDU Session ID that must be released, and is shared between the AMF and SMF. The Release indication is an indicator that it is a release request, and access for MA PDU Session release indicates the Access Type that must be released.

[0081] At this time, the Old AMF may determine that the New AMF does not support ATSSS through the following methods: 1) when AMF discovery / selection is supported via the NRF, if the MA PDU support indicator is not present in the supported features of the response message from the NRF in stage 803b; 2) if the Old AMF has previously exchanged supported features with the New AMF through communication, and the MA PDU support indicator is not present in those supported features, and based on this, information that the New AMF does not support ATSSS is stored; 3) if information that the New AMF does not support ATSSS is stored through the Old AMF's local configuration.

[0082] In stage 806, upon receiving a message from AMF in step 5, the SMF decides, via its local policy, whether to release the MA PDU Session mapped to the SM Context ID only to the access type that received it, or to all access. Based on this decision, it instructs the UPF to either release the MA PDU Session to one access or to all access.

[0083] In step 807, the SMF can send an Nsmf_PDUSession_UpdateSMContext Response message to the Old AMF containing the results of the request in step 805.

[0084] In stage 808, the Old AMF does not perform any actions, such as propagation, even if the message from the SMF contains a message requesting propagation to the UE or AN. The Old AMF sends a Namf_Communication_CreateUEContext Request message to the New AMF to propagate the UE Context.

[0085] At this time, the Old AMF does not include the context for the successfully released MA PDU Session in the UE Context it sends to the New AMF.

[0086] In step 809, the remaining steps of the N2 infrastructure handover to the UE can be performed. If the MA PDU Session Context that was missing in the UE Context received in step 808 exists in the UE, the UE can perform a local release to the MA PDU Session that exists only in itself through the synchronization process with the New AMF.

[0087] Figure 9 is a diagram illustrating how, in one embodiment of the present disclosure, when a UE executes a registration request in an AMF that does not support ATSSS, the existing AMF releases an MA PDU Session after confirming that the UE has successfully registered in the new AMF.

[0088] Referring to Figure 9, in step 901, in order to proceed with the registration procedure for the New AMF, the UE can send a Registration request message to the New AMF (steps 1-3). Specifically, the UE sends an AN message containing the Registration Request message to the Access Node (AN) (step 1), the AN determines the AMF (step 2), and the determined AMF (i.e., the New AMF) can send an N2 message containing the Registration Request message to the determined AMF (i.e., the New AMF) (step 3).

[0089] At stage 904, the New AMF can send a Namf_Communication_UEContextTransfer Request message to the Old AMF.

[0090] At this time, the message may include the UE's Access Type and supported features. In this case, the supported features include whether or not New AMF supports ATSSS, and Old AMF can determine whether or not New AMF supports ATSSS based on this.

[0091] In step 905, if it was determined in step 904 that the New AMF does not support ATSSS, the Old AMF can send the New AMF a UE Context without the context for the MA PDU Session.

[0092] In step 906, since the AMF has been modified, the New AMF can be registered with UDM (Unified Data Management) via the Nudm_UECM_Registration message (which includes SUPI (Subscription Permanent Identifier) ​​and Access Type).

[0093] In stage 907, the UDM can notify the Old AMF providing services for the UE's Access Type that a new AMF has been registered, via the Nudm_UECM_DeregistrationNotification message (including SUPI and Access Type).

[0094] In step 908, after receiving the message in step 907, the Old AMF can request the SMF to release the MA PDU Session via an Nsmf_PDUSession_UpdateSMContext Request or Nsmf_PDUSession_ReleaseSMContext Request message. This message may include the PDU Session ID for the MA PDU Session and the Access Type.

[0095] In stage 909, if the Access Type is explicitly stated in the message to SMF, SMF can release the MA PDU for that access. If the Access Type is not explicitly stated, SMF can release for both accesses.

[0096] At stage 910, the remaining registration steps can be performed. The UE receives a Registration Accept message from New AMF. At this time, if there are MA PDU Sessions that are not included in the PDU Session Status IE (information element) of the message, the UE may locally release the MA PDU Session only to the Access that received the Registration Accept message, or it may locally release the MA PDU Session to both Access Types.

[0097] Figure 10 shows how, during an N2 infrastructure handover, when the UE's AMF is changed to a new AMF that does not support ATSSS, one embodiment of the present disclosure releases the MA PDU Session after the existing AMF (S-AMF) receives a message indicating that the handover from the new AMF to the UE was successful.

[0098] Referring to Figure 10, in step 1001, S-RAN can send a Handover Required message to S-AMF.

[0099] In stage 1002, if it is determined that S-AMF (or Old AMF) can no longer support UEs, S-AMF performs AMF discovery / selection to select a new AMF (i.e., New AMF or T-AMF). At this time, S-AMF can perform AMF discovery / selection via the Network Repository Function (NRF) or via AMF local configuration.

[0100] In step 1003a, if AMF discovery / selection is possible via NRF, S-AMF can send an Nnrf_NFDiscovery Request message to NRF. This message can contain various query parameters for discovering new AMFs, and the NF Type parameter can be set for the AMF before being sent.

[0101] In step 1003b, the NRF can select a new AMF and send its NF Profile via S-AMF. This NF Profile includes supported features for the NFServices provided by the AMF (e.g., Namf_Communication). These supported features include whether ATSSS is supported (i.e., MA PDU).

[0102] In step 1004, S-AMF can determine whether T-AMF supports ATSSS. S-AMF will determine that T-AMF does not support ATSSS if:

[0103] 1) If the MA PDU is not listed in the supportedFeatures of the message received in step 1003b, 2) If T-AMF recognizes that the MA PDU is not listed in the supportedFeatures of previous messages, 3) If it recognizes that it is not supported based on the local configuration.

[0104] In step 1005, if it is determined that T-AMF does not support ATSSS, S-AMF may send T-AMF the UE Context excluding the MA PDU Session context.

[0105] In step 1006, as part of the N2 handover procedure, the UE can send a Handover Confirm message to the T-RAN, and the T-RAN can send a Handover Notify message to the T-AMF.

[0106] In step 1007, T-AMF can send a message to S-AMF notifying it that the N2 handover to the UE was successful.

[0107] In step 1008, after receiving the message in step 1007, S-AMF can request an MA PDU Session release from SMF via an Nsmf_PDUSession_UpdateSMContext Request or Nsmf_PDUSession_ReleaseSMContext Request message. This message may include the PDU Session ID for the MA PDU Session and the Access Type.

[0108] In stage 1009, if the Access Type is explicitly stated in the message to SMF, SMF can release the MA PDU for that access. If the Access Type is not explicitly stated, it will release for both accesses.

[0109] In step 1010, the remaining handover procedures can be performed. The UE can receive a Registration Accept message from the New AMF. At this time, if there are MA PDU Sessions that are not included in the PDU Session Status IE of the message, the UE may locally release the MA PDU Sessions only to the Access that received the Registration Accept message, or it may locally release the MA PDU Sessions to both Access Types.

[0110] Figure 11 is a block diagram showing the structure of a terminal (UE) according to one embodiment of the present disclosure.

[0111] Referring to Figure 11, the terminal may include a transceiver 1110, a terminal control unit 1120, and a storage unit 1130. In this disclosure, the terminal control unit 1220 may be defined as a circuit or application-specific integrated circuit or at least one processor.

[0112] The transmitting / receiving unit 1110 can send and receive signals with other network entities. For example, the transmitting / receiving unit 1110 can receive system information from a base station and can receive synchronization signals or reference signals.

[0113] The terminal control unit 1120 can control the overall operation of the terminal according to the embodiment proposed in this disclosure. For example, the terminal control unit 1120 can control the signal flow between each block to perform the operation of the terminal according to the flowchart described above.

[0114] The storage unit 1130 can store at least one of the information transmitted and received via the transmitting and receiving unit 1110 and the information generated via the terminal control unit 1120.

[0115] Figure 12 is a block diagram showing the structure of a higher-level node according to one embodiment of the present disclosure.

[0116] The block diagram shown in Figure 12 can be any block diagram relating to the aforementioned higher-level nodes, such as AMF, SMF, and UPF.

[0117] In this disclosure, core network entities or network functions such as AMF, SMP, and UPF are all referred to as upper-level nodes.

[0118] Referring to Figure 12, the upper node may include a transceiver unit 1210, an upper node control unit 1220, and a storage unit 1230. In this disclosure, the upper node control unit 1220 may be defined as a circuit or application-specific integrated circuit or at least one processor.

[0119] The transmitting / receiving unit 1210 can send and receive signals with other network entities. For example, the transmitting / receiving unit 1210 can send and receive signals for embodiments of this disclosure with an adjacent higher-level node.

[0120] The upper node control unit 1220 can control the overall operation of the upper node according to the demonstration proposed in this disclosure. For example, the upper node control unit 1220 can control the signal flow between each block to perform the operation of the upper node according to the flowchart described above.

[0121] The storage unit 1230 can store at least one of the information transmitted and received via the transmitting and receiving unit 1210 and the information generated via the upper node control unit 1220.

[0122] According to the embodiments of this disclosure described above, when a terminal registered with an AMF that supports ATSSS is registered with an AMF that does not support ATSSS, the existing MA PDU Session can be efficiently released and smooth communication can be performed.

[0123] The methods described in the claims or specifications of this disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0124] When implemented in software, a computer-readable storage medium can be provided that stores one or more programs (software modules). The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to perform the methods according to the embodiments described in the claims or specification of this disclosure.

[0125] Such programs (software modules, software) can be stored in random access memory, non-volatile memory including flash memory, ROM (read-only memory), 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 in a memory composed of some or all of these. Furthermore, each constituent memory can include multiple instances.

[0126] Furthermore, the program can be stored in an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, LAN (local area network), WAN (wide area network), or SAN (storage area network), or a combination thereof. Such a storage device can be connected to the device performing the embodiments of this disclosure via an external port. Alternatively, a separate storage device on the communication network can be connected to the device performing the embodiments of this disclosure.

[0127] In the specific embodiments of the Disclosure described above, the components included in the Disclosure are expressed singly or plurally by the specific embodiments presented. However, the singly or plural representations are chosen to suit the circumstances presented for the sake of explanation, and the Disclosure is not limited to singly or plural components; a component expressed plural may consist of singular components, and a component expressed singly may consist of plural components.

[0128] Although this disclosure has been described in various embodiments, various changes and modifications can be proposed to those skilled in the art. This disclosure is intended to include such changes and modifications that fall within the claims attached. [Explanation of Symbols]

[0129] 1110 Transceiver 1120 UE Controller 1130 storage 1210 Transceiver 1220 Upper node controller 1230 storage

Claims

1. A wireless communication system comprising a first access and mobility management function (AMF) entity method, The steps include receiving a first message containing information about the access type of the user equipment (UE) and the supported feature of the second AMF entity, where the information about the supported feature includes a multi-access package data unit (MA PDU) session support indicator. Based on the information received from the second AMF entity regarding the supported feature, the step of determining whether the second AMF entity supports the access traffic steering, switching, and splitting (ATSSS) function, If, as a result of the above verification, the information for the supported feature does not include the MA PDU session support indicator, then the second AMF entity determines that it does not support the ATSSS function. The steps include sending a second message containing a UE context to the second AMF entity, where if the second AMF entity does not support the ATSSS function, the UE context does not contain a context for a multi-access package data unit (MA PDU) session. If the second AMF entity does not support the ATSSS function, the steps include determining whether an MA PDU session exists for the received access type, and If an MA PDU session exists for the received access type, the step includes sending a third message to the session management function (SMF) entity requesting the release of the MA PDU session corresponding to the access type, A method characterized in that the MA PDU session is released based on the third message.

2. The first message is received from the second AMF entity, The method according to claim 1, characterized in that the first message is a message for requesting the UE context stored in the first AMF entity to be transmitted to the second AMF entity.

3. The first message is provided by a network repository function (NRF) entity. The first AMF entity is the source AMF entity involved in the handover, The second AMF entity is the target AMF entity related to the handover, and The method according to claim 1, characterized in that the first message includes a network function (NF) profile of a second AMF entity, and the NF profile includes the information.

4. The process further includes receiving a fourth message from the second AMF entity indicating that the handover was successful, The method according to claim 3, characterized in that the third message is transmitted after the fourth message has been received.

5. A wireless communication system comprising a first access and mobility management function (AMF) entity, which includes a transmitting and receiving unit for transmitting and receiving signals, and It is coupled with the transmitting / receiving unit and receives a first message containing information about the access type of the user equipment (UE) and the supported feature of the second AMF entity, - the information about the supported feature includes a multi-access package data unit (MA PDU) session support indicator - Based on the information received from the second AMF entity regarding the supported feature, it is determined whether the second AMF entity supports the access traffic steering, switching, and splitting (ATSSS) function. If, as a result of the above verification, the information for the supported feature does not include the MA PDU session support indicator, then it is determined that the second AMF entity does not support the ATSSS function. A second message containing a UE context is sent to the second AMF entity, and if the second AMF entity does not support the ATSSS function, the UE context does not contain a context for a multi-access package data unit (MA PDU) session. If the second AMF entity does not support the ATSSS function, it is determined whether an MA PDU session exists for the received access type, and The system includes a control unit that controls the sending of a third message to a session management function (SMF) entity requesting the release of the MA PDU session corresponding to the access type, if an MA PDU session exists for the received access type. A first AMF entity characterized in that the MA PDU session is released based on the third message.

6. The first message is received from the second AMF entity, The first AMF entity according to claim 5, characterized in that the first message is a message for requesting the second AMF entity to transmit the UE context stored in the first AMF entity.

7. The first message is provided by a network repository function (NRF) entity. The first AMF entity is the source AMF entity involved in the handover, The second AMF entity is the target AMF entity related to the handover, and The first AMF entity according to claim 5, characterized in that the first message includes a network function (NF) profile of the second AMF entity, and the NF profile includes the information.

8. The control unit is controlled to receive a fourth message from the second AMF entity indicating that the handover was successful. The first AMF entity according to claim 7, characterized in that the third message is transmitted after the fourth message has been received.

Images