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

Abstract

The present disclosure relates to a communication method and system for converging a 5th-Generation (5G) communication system for supporting higher data rates beyond a 4th-Generation (4G) system with a technology for Internet of Things (IoT). The present disclosure may be applied to intelligent services based on the 5G communication technology and the IoT-related technology, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services. The disclosure proposes, when a UE is registered in an AMF which does not support ATSSS (registration procedure), a method by which, an old AMF identifies the registration and releases an MA PDU session and a method by which the UE identifies the registration and releases the MA PDU session in a wireless communication system according to an embodiment.

Claims

1. A method performed by a first access and mobility management function (AMF) entity in a wireless communication system, the method comprising: receiving a first message including information on supported features of a second AMF entity; identifying whether the second AMF entity supports an access traffic steering, switching, splitting (ATSSS) function based on the information; transmitting, to the second AMF entity, a second message including a user equipment (UE) context, wherein the UE context does not include a context for a multi-access packet data unit (MA PDU) session, in case that the second AMF entity does not support the ATSSS function; and transmitting, to a session management function (SMF) entity, a third message requesting to release the MA PDU session, wherein the MA PDU session is released based on the third message.

2. The method of claim 1, wherein the first message is received from the second AMF entity, and wherein the first message is a message for requesting to transfer the UE context stored in the first AMF entity to the second AMF entity.

3. The method of claim 1, wherein the first message is provided by a network repository function (NRF) entity, wherein the first AMF entity is a source AMF entity associated with a handover, and wherein the second AMF entity is a target AMF entity associated with the handover.

4. The method of claim 3, the method further comprising receiving, from the second AMF entity, a fourth message notifying that the handover is successful, wherein the third message is transmitted after the fourth message is received.

5. The method of claim 3, wherein the first message includes a network function (NF) profile of the second AMF entity, the NF profile including the information.

6. A first access and mobility management function (AMF) entity in a wireless communication system, the first AMF entity comprising: a transceiver configured to transmit and receive a signal; and a controller coupled with the transceiver and configured to: receive a first message including information on supported features of a second AMF entity, identify whether the second AMF entity supports an access traffic steering, switching, splitting (ATSSS) function based on the information, transmit, to the second AMF entity, a second message including a user equipment (UE) context, wherein the UE context does not include a context for a multi-access packet data unit (MA PDU) session, in case that the second AMF entity does not support the ATSSS function, and transmit, to a session management function (SMF) entity, a third message requesting to release the MA PDU session, wherein the MA PDU session is released based on the third message.

7. The first AMF entity of claim 6, wherein the first message is received from the second AMF entity, and wherein the first message is a message for requesting to transfer the UE context stored in the first AMF entity to the second AMF entity.

8. The first AMF entity of claim 6, wherein the first message is provided by a network repository function (NRF) entity, wherein the first AMF entity is a source AMF entity associated with a handover, and wherein the second AMF entity is a target AMF entity associated with the handover.

9. The first AMF entity of claim 8, wherein the controller is further configured to receive, from the second AMF entity, a fourth message notifying that the handover is successful, wherein the third message is transmitted after the fourth message is received.

10. The first AMF entity of claim 8, wherein the first message includes a network function (NF) profile of the second AMF entity, the NF profile including the information.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference numerals represent like parts:

(2) FIG. 1 illustrates the architecture of a system which supports ATSSS in a 3GPP 5G system;

(3) FIG. 2 illustrates a problem to be solved by the disclosure;

(4) FIG. 3 illustrates a sequence diagram for a procedure in which an old AMF releases an old MA PDU session on the basis of an update SM context service;

(5) FIG. 4 illustrates a sequence diagram for a procedure in which an old AMF releases an old MA PDU session on the basis of a release SM context service;

(6) FIG. 5 illustrates a sequence diagram for a procedure for releasing an old MA PDU session on the basis of a PDU session release request including a specific request type of a UE;

(7) FIG. 6 illustrates a sequence diagram for a procedure for releasing an old MA PDU session on the basis of a PDU session release request of a UE;

(8) FIG. 7 illustrates a sequence diagram for a procedure in which a UE releases an old MA PDU session through local release;

(9) FIG. 8 illustrates a sequence diagram for a procedure in which an old AMF releases an old MA PDU session on the basis of an update SM context service when an AMF is changed due to N2 handover;

(10) FIG. 9 illustrates a method of releasing an MA PDU session after an old AMF identifies that a UE is successfully registered in a new AMF when the UE makes a request for registration in an AMF which does not support ATSSS;

(11) FIG. 10 illustrates a method by which, when an AMF of a UE is changed into a new AMF which does not support ATSSS during N2-based handover, an old AMF (S-AMF) receives a message indicating that the handover for the UE is successfully performed from the new AMF and then releases an MA PDU session;

(12) FIG. 11 illustrates a block diagram for the structure of a UE according to an embodiment; and

(13) FIG. 12 illustrates a block diagram for the structure of a higher node according to an embodiment.

DETAILED DESCRIPTION

(14) FIGS. 1 through 12, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

(15) In describing embodiments of the disclosure, descriptions related to technical contents well-known in the art and not associated directly with the disclosure will be omitted. Such an omission of unnecessary descriptions is intended to prevent obscuring of the main idea of the disclosure and more clearly transfer the main idea.

(16) For the same reason, in the accompanying drawings, some elements may be exaggerated, omitted, or schematically illustrated. Further, the size of each element does not completely reflect the actual size. In the drawings, identical or corresponding elements are provided with identical reference numerals.

(17) The advantages and features of the disclosure and ways to achieve them will be apparent by making reference to embodiments as described below in detail in conjunction with the accompanying drawings. However, the disclosure is not limited to the embodiments set forth below, but may be implemented in various different forms. The following embodiments are provided only to completely disclose the disclosure and inform those skilled in the art of the scope of the disclosure, and the disclosure is defined only by the scope of the appended claims. Throughout the specification, the same or like reference numerals designate the same or like elements.

(18) Here, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer usable or computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer usable or computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

(19) Further, each block of the flowchart illustrations may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

(20) As used herein, the “unit” refers to a software element or a hardware element, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), which performs a predetermined function. However, the “unit” does not always have a meaning limited to software or hardware. The “unit” may be constructed either to be stored in an addressable storage medium or to execute one or more processors. Therefore, the “unit” includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, properties, procedures, sub-routines, segments of a program code, drivers, firmware, micro-codes, circuits, data, database, data structures, tables, arrays, and parameters. The elements and functions provided by the “unit” may be either combined into a smaller number of elements, or a “unit”, or divided into a larger number of elements, or a “unit”. Moreover, the elements and “units” or may be implemented to reproduce one or more CPUs within a device or a security multimedia card.

(21) The disclosure relates to a method and an apparatus for supporting various services in a wireless communication system. Specifically, the disclosure describes a technology for providing an access traffic steering (Access Traffic Steering, Switching, Splitting (ATSSS)) function in a wireless communication system.

(22) As used in the following description, terms for identifying access nodes, terms referring to network entities or network functions (NFs), terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, and the like are illustratively used for the sake of convenience. Therefore, the disclosure is not limited by the terms as used below, and other terms referring to subjects having equivalent technical meanings may be used.

(23) FIG. 1 illustrates the system architecture for supporting Access Traffic Steering, Switching, Splitting (ATSSS) in a 3GPP 5G system. Through the ATSSS function, traffic transmission can be performed through multiple paths (for example, 3GPP access 110 and non-3GPP access 120) between a Protocol Data Unit (PDU) (or a packet data unit) session anchor User Plane Function (UPF) 104 and a User Equipment (UE) 101 as illustrated in FIG. 1. Meanwhile, in order to use ATSSS, the User Equipment (UE) 101, an Access and Mobility Management Function (AMF) 102, a Session Management Function (SMF) 103, and a User Plane Function (UPF) 104 should support the ATSSS.

(24) FIG. 2 illustrates a problem to be solved by the disclosure. FIG. 2 illustrates a situation in which a UE 210 registers to a new AMF 212 due to UE movement 200 in the state in which the UE 210 already established one or more MA PDU sessions with an old AMF 211. When the new AMF 212 does not support ATSSS (that is, ATSSS-incapable AMF), the old AMF 211 transmits context for the old MA PDU session to the new AMF through UE context transfer as indicated by reference numeral 202. At this time, although the new AMF does not support ATSSS, if the MA PDU session is not released, an unexpected operation may occur due to the existence of MA PDU sessions that are not released. Accordingly, for the efficient operation of the MA PDU session, MA PDU sessions for the corresponding access should be necessarily released. A technology for releasing the MA PDU session does not exist at present, and the disclosure proposes a method and an apparatus for solving the problem.

(25) FIG. 3 illustrates a method by which an old AMF releases an MA PDU session through UpdateSMContext according to an embodiment when a UE is registered in a new AMF which does not supports ATSSS.

(26) Referring to FIG. 3, in step 301, the UE may transmit a registration request message to the new MAF in order to perform a registration process for the new AMF (steps 1 to 3). Specifically, the UE may transmit an Access Node (AN) message including the registration request message to an AN in step 1, and the AN receiving the AN message may determine an AMF in step 2 and transmit an N2 message including the registration request message to the determined AMF (that is, a new AMP) in step 3.

(27) In step 304, the new AMF may transmit a Namf_Communication_UEContextTransfer request message to the old AMF. At this time, the corresponding message may include an access type and supported features of the UE. When the new AMF does not support ATSSS, the supported features do not include an MA PDU session support indicator.

(28) When it is determined that the new AMF does not support ATSSS, the old AMF identifies whether there is an MA PDU session for the access type received in step 304 in UE context in step 305. When there is an MA PDU session for the received access type, the old AMF may perform an operation for releasing the MA PDU session for the access type for the SMF. Specifically, the old AMF may transmit a Nsmf_PDUSession_UpdateSMContext request message to the SMF. The Nsmf_PDUSession_UpdateSMContext request message may include information on an SM context ID, a release indication, and access for MA PDU session release. At this time, the SM context ID is a context identifier for an MA PDU session ID which should be locally released, and should be shared between the AMF and the SMF. The release indication is an indicator indicating a release request, and the access for MA PDU session release is an access type which should be released.

(29) At this time, the old AMF may determine whether the new AMF supports ATSSS as follows: 1) an MA PDU session support indicator in a supported features field or parameter included in the request message of step 304, 2} an MA PDU session support indicator in a supported feature of an NF profile for the new AMF stored in a Network Repository Function (NRF), and 3) local configuration of the AMF

(30) Upon receiving the message of step 305 from the AMF, the SMF determines whether to release only the access type for receiving the MA PDU session mapped to the SM context ID or release all accesses through a local policy in step 306. The SMF may indicate to the UPF whether to release the MA PDU session only for one access or release MA PDU sessions for all accesses according to the determination result.

(31) The SMF transmits a Nsmf_PDUSession_UpdateSMContext response message including the result of the request of step 305 to the old AMF in step 307.

(32) Even though the response message from the SMF includes a message for making a request for transmission to the UE or the AN, the old AMF does not perform an operation such as transmission in step 308. The old AMF transmits UE context to the new AMF in response to the request message of step 304.

(33) At this time, the old AMF does not insert context for MA PDU sessions successfully released from the message from the SMF into UE context to be transmitted to the new AMF.

(34) In step 309, the remaining registration procedures of the UE are performed. When MA PDU session context missed in the UE context received in step 308 exists in the UE, the UE may locally release the MA PDU session existing only in the UE through a synchronization process with the new AMF.

(35) FIG. 4 illustrates a method by which an old AMF releases an old MA PDU session through ReleaseSMContext according to an embodiment when a UE is registered in a new AMF which does not supports ATSSS.

(36) Referring to FIG. 4, in step 401, the UE may transmit a registration request message to the new MAF in order to perform a registration process for the new AMF (steps 1 to 3). Specifically, the UE may transmit an Access Node (AN) message including the registration request message to an AN in step 1, and the AN receiving the AN message may determine an AMF in step 2 and transmit an N2 message including the registration request message to the determined AMF (that is, a new AMP) in step 3.

(37) In step 404, the new AMF may transmit a Namf_Communication_UEContextTransfer request message to the old AMF. At this time, the corresponding message may include an access type and supported features of the UE. When the new AMF does not support ATSSS, the supported features do not include an MA PDU session support indicator.

(38) When it is determined that the new AMF does not support ATSSS, the old AMF identifies whether there is an MA PDU session for the access type received in step 404 in UE context in step 405. When there is an MA PDU session for the received access type, the old AMF may perform an operation for releasing the MA PDU session for the access type for the SMF.

(39) Specifically, the old AMF may transmit a Nsmf_PDUSession_Release request message to the SMF. The Nsmf_PDUSession_Release request message may include information on an SM context ID and access for MA PDU session release. At this time, the SM context ID is a context identifier for an MA PDU session ID which should be locally released, and should be shared between the AMF and the SMF. The access for MA PDU session release is an access type which should be released.

(40) At this time, the old AMF may determine whether the new AMF supports ATSSS as follows: 1) an MA PDU session support indicator in a supported features included in the request message of step 404, 2) an MA PDU session support indicator in a supported feature of an NF profile for the new AMF stored in a Network Repository Function (NRF), and 3) local configuration of the AMF

(41) Upon receiving the message of step 405 from the AMF, the SMF determines whether to release only the access type for receiving the MA PDU session mapped to the SM context ID or release all accesses through a local policy in step 406. The SMF may indicate to the UPF whether to release only the access for the MA PDU session or release all accesses according to the determination result.

(42) In step 407, the SMF transmits a Nsmf_PDUSession_ReleaseSMContext response including the result of the request of step 405.

(43) In step 408, the old AMF transmits UE context to the new AMF in response to the request message of step 404.

(44) At this time, the old AMF does not insert context for MA PDU sessions successfully released from the message from the SMF into UE context to be transmitted to the new AMF.

(45) In step 409, the remaining registration procedures of the UE are performed. When MA PDU session context missed in the UE context received in step 408 exists in the UE, the UE may locally release the MA PDU session existing only in the UE through a synchronization process with the new AMF.

(46) FIG. 5 illustrates an MA PDU session release method through an MA PDU session release request including a specific request type of the UE according to an embodiment when the UE is registered in a new AMF which does not support ATSSS.

(47) In step 500, the UE may perform a registration procedure of the new AMF. The registration procedure of the new AMF may be performed to be the same as the registration procedure of the new AMF according to the embodiments of FIGS. 3 and 4.

(48) In step 501, when an MA PDU session support indicator is not included in a registration accept message and there is a PDU session ID of the MA PDU session for an access type for which the registration accept message is received in a PDU session status of the registration accept message (501-1), the UE may insert the PDU session ID and a request type into a PDU session release request message with respect to all of the corresponding PDU session IDs and transmit the PDU session release request message to the new AMF (501-2).

(49) At this time, the release type is used to indicate an access type which the UE desires to release. When the UE desires to release the MA PDU session only for the access type for which the registration accept message is received, the release type may indicate the corresponding access type. When the UE desires to release MA PDU sessions for all accesses, the release type may be configured as an indicator making a request for releasing all accesses.

(50) In step 502, the new AMF may transmit an N1 SM container received from the UE to the SMF through a Nsmf_PDUSession_UpdateSMContext request message. At this time, the new AMF also transmits an SM context ID mapped to the PDU session ID.

(51) When the release type indicates to release all accesses, the SMF completely releases the corresponding MA PDU session in step 503. Meanwhile, when the release type indicates only one access type, the SMF may determine whether to release only the access type for which the MA PDU session mapped to the SM context ID or release all accesses through a local policy.

(52) When it is determined to release only one access type on the basis of the determination of step 503, the SMF indicates to release the MA PDU session for the corresponding access type to the UE, the Access Network (AN), and the UPF in step 504.

(53) Meanwhile, when it is determined to release all access types on the basis of the determination of step 503, the SMF indicates to release the MA PDU session for all access types to the UE, the Access Network (AN), and the UPF.

(54) FIG. 6 illustrates an MA PDU session release method through an MA PDU session release request of the UE according to an embodiment when the UE is registered in a new AMF which does not support ATSSS.

(55) In step 600, the UE may perform a registration procedure of the new AMF. The registration procedure of the new AMF may be performed to be the same as the registration procedure of the new AMF according to the embodiments of FIGS. 3 and 4.

(56) In step 601, when an MA PDU session support indicator is not included in a registration accept message and a PDU session ID of an MA PDU session exists in a PDU session status of the registration accept message for an access type for which the registration accept message is received (601-1), all of the corresponding PDU session IDs into the UE inserts a PDU session release request message and transmits the PDU session release request message to the AMF (601-2).

(57) In step 602, the new AMF may transfer an N1 SM container received from the UE to the SMF through a Nsmf_PDUSession_UpdateSMContext request message. At this time, the new AMF also transmits an SM context ID mapped to the PDU session ID.

(58) In step 603, the SMF indicates to releases the MA PDU session for all access types.

(59) FIG. 7 illustrates a sequence diagram for a procedure in which the UE releases an old MA PDU session through local release according to an embodiment.

(60) In step 700, the UE performs a registration procedure of the new AMF. When an MA PDU session support indicator is not included in a registration accept message and a PDU session ID of an MA PDU session exists for the access type for which the registration accept message is received, the UE may locally release all of the corresponding PDU session IDs.

(61) When the MA PDU sessions are locally released in step 700, the UE may perform a service request procedure in step 701. At this time, the PDU session IDs of the MA PDU sessions released in step 700 are not included in the PDU session status.

(62) In step 702, the new AMF may transfer an N1 SM container received from the UE to the SMF through a Nsmf_PDUSession_ReleaseSMContext request message. At this time, the new AMF also transmits an SM context ID mapped to the PDU session ID.

(63) In step 703, the SMF may perform MA PDU session release for all access types.

(64) FIG. 8 illustrates a method by which, when an AMF of the UE is changed into an AMF which does not support ATSSS during N2-based handover, an old AMF releases an old MA PDU session through UpdateSMContext according to an embodiment.

(65) Referring to FIG. 8, in step 801, an N2 handover procedure may be performed. An old RAN (that is, a source RAN or an S-RAN) may transmit a handover-required message along with a target ID to an old AMF (that is, a source AMF or an S-AMF).

(66) When it is determined that the old AMF cannot support the UE anymore, the old AMF may perform AMF discovery/selection to select a new AMF (that is, a target AMF or a T-AMF) in step 802. At this time, the old AMF can perform AMF discovery/selection through a Network Repository Function (NRF) or AMF discovery/selection through AMF local configuration.

(67) When AMF discovery/selection can be performed through the NRF, the old AMF may transmit a Nnrf_NFDiscovery Request message to the NRF in step 803a. The corresponding message may include various query parameters for discovering a new AMF, and an NF type parameter may be configured as an AMF and transmitted.

(68) In step 803b, the NRF may select a new AMF and transmit an NF profile of the corresponding AMF to the old AMF. At this time, the NF profile includes supported features for NF services which the AMF provides (for example, Namf_Communication). The supported features include information on whether ATSSS is supported (that is, MA PDU).

(69) When the MA PDU parameter does not exist in the supported features of the message received in step 803b, the old AMF may determine that new AMF does not support ATSSS in step 804 and perform step 805.

(70) When the old AMF determines that the new AMF does not support ATSSS in step 805, the old AMF identifies whether there is MA PDU session context in UE context of the old AMF. When there is MA PDU session context in UE context, the old AMF may perform an operation for releasing the MA PDU session for the SMF. Specifically, the old AMF may transmit a Nsmf_PDUSession_UpdateSMContext request message to the SMF. The Nsmf_PDUSession_UpdateSMContext request message may include information on an SM context ID, a release indication, and access for MA PDU session release. At this time, the SM context ID is a context identifier for an MA PDU session ID which should be locally released, and is shared between the AMF and the SMF. The release indication is an indicator indicating a release request, and the access for MA PDU session release is an access type which should be released.

(71) At this time, the old AMF may determine that the new AMF does not support ATSSS through the following methods: 1) the case in which there is no MA PDU support indicator in a supported feature of a response message from the NRF of step 803b when AMF discovery/selection through the NRF is supported, 2) the case in which the old AMF had exchanged supported features in the past through communication with the new AMF and the case in which there is no MA PDU support indicator in supported features at that time and information indicating that the new AMF does not support ATSSS is stored on the basis thereof, and 3) the case in which information indicating that the new AMF does not support ATSSS is stored through local configuration of the old AMF.

(72) Upon receiving the message in step 805 from the AMF, the SMF determines whether to release only the access type for receiving the MA PDU session mapped to the SM context ID or release all accesses through a local policy in step 806. The SMF may indicate to the UPF whether to release only the access for the MA PDU session or release all accesses according to the determination result.

(73) The SMF may transmit a Nsmf_PDUSession_UpdateSMContext response message including the result of the request of step 805 to the old AMF in step 807.

(74) Even though the message from the SMF includes a message for making a request for transmission to the UE or the AN, the old AMF does not perform an operation such as transmission in step 808. The old AMF transmits a Namf_Communication_CreateUEContext request message in order to transfer UE context to the new AMF.

(75) At this time, the old AMF does not insert context for successfully released MA PDU sessions into UE context to be transmitted to the new AMF.

(76) In step 809, the remaining procedures for N2-based handover of the UE may be performed. When MA PDU session context missed in the UE context received in step 808 exists in the UE, the UE may locally release the MA PDU session existing only in the UE through a synchronization process with the new AMF.

(77) FIG. 9 illustrates a method of releasing an MA PDU session after the old AMF identifies that the UE is successfully registered in the new AMF according to an embodiment when the UE makes a request for registration in the AMF that does not support ATSSS.

(78) Referring to FIG. 9, in step 901, the UE may transmit a registration request message to the new AMF in order to perform a registration process for the new AMF (steps 1 to 3). Specifically, the UE may transmit an Access Node (AN) message including the registration request message to an AN in step 1, and the AN may determine an AMF in step 2 and transmit an N2 message including the registration request message to the determined AMF (that is, a new AMF) in step 3.

(79) In step 904, the new AMF may transmit a Namf_Communication_UEContextTransfer request message to the old AMF. At this time, the request message may include an access type and supported features of the UE. The supported features include information on whether the new AMF supports ATSSS, and the old AMF may recognize whether the new AMF supports ATSSS on the basis thereof.

(80) In case that it is determined that the new AMF does not support ATSSS in step 904, the old AMF may transmit UE context except for context for the MA PDU session to the new AMF in step 905.

(81) Since the AMF was changed, the new AMF may be registered in Unified Data Management (UDM) through a Nudm_UECM_Registration message (including a Subscription permanent Identifier (SUPI) and an access type) in step 906.

(82) In step 907, the UDM may inform the old AMF which provides the service for the access type of the corresponding UE that the new AMF has been registered through a Nudm_UECM_DeregistrationNotification message (including an SUPI and an access type).

(83) After receiving the message of step 907, the old AMF may make a request for releasing the MA PDU session through a Nsmf_PDUSession_UpdateSMContext request message or a Nsmf_PDUSession_ReleaseSMContext request message to the SMF in step 908. At this time, the messages may include a PDU session ID of the MA PDU session and an access type.

(84) When the access type is specified in the message to the SMF, the SMF may perform release for the corresponding access of the MA PDU in step 909. When the access type is not specified, release for both accesses may be performed.

(85) In step 910, the remaining registration procedures may be performed. The UE receives a registration accept message from the new AMF. At this time, when there is an MA PDU session which is not included in a PDU session status Information Element (IE) of the corresponding message, the UE may locally release the MA PDU session only for the access for which the registration accept message is received or locally release MA PDU sessions for both access types.

(86) FIG. 10 illustrates a method by which, when an AMF of the UE is changed into a new AMF which does not support ATSSS during N2-based handover, the old AMF (S-AMF) receives a message indicating that the handover for the UE is successfully performed from the new AMF and then releases the MA PDU session according to an embodiment.

(87) Referring to FIG. 10, in step 1001, the S-RAN may transmit a handover-required message to the S-AMF.

(88) When it is determined that the S-AMF (or old AMF) cannot support the UE anymore, the S-AMF performs AMF discovery/selection and selects a new AMF (that is, T-AMF) in step 1002. At this time, the S-AMF can perform AMF discovery/selection through a Network Repository Function (NRF) or AMF discovery/selection through AMF local configuration.

(89) When AMF discovery/selection can be performed through the NRF, the S-AMF may transmit a Nnrf_NFDiscovery request message to the NRF in step 1003a. The corresponding message may include various query parameters for discovering a new AMF, and an NF type parameter may be configured as the AMF and transmitted.

(90) In step 1003b, the NRF may select the new AMF and transmit an NF profile of the corresponding AMF to the S-AMF. At this time, the NF profile includes supported features for NF services (for example, Namf_Communication) which the AMF provides. The supported features include information indicating whether ATSSS is supported (that is, MA PDU).

(91) In step 1004, the S-AMF may determine whether the T-AMF supports ATSSS. The S-AMF determines that the T-AMF does not support ATSSS in the following cases: 1) the case in which the supported features of the message received in step 1003b do not have an MA PDU, 2) the case in which the T-AMF knows that there is no MA PDU in the supported features of the previous message, and 3) the case in which the T-AMF knows that ATSSS is not supported on the basis of local configuration.

(92) When it is determined that the T-AMF does not support ATSSS, the S-AMF may transmit UE context except for MA PDU session context to the T-AMF in step 1005.

(93) In step 1006, the UE may transmit a Handover Confirm message to the T-RAN and the T-RAN may transmit a Handover Notify message to the T-AMF as the N2 handover procedure.

(94) In step 1007, the T-AMF may transmit a message indicating that the N2 handover for the UE has been successfully performed to the S-AMF.

(95) After receiving the message of step 1007, the S-AMF may make a request for releasing the MA PDU session through a Nsmf_PDUSession_UpdateSMContext request message or a Nsmf_PDUSession_ReleaseSMContext request message to the SMF in step 1008. At this time, the messages may include a PDU session ID of the MA PDU session and an access type.

(96) In step 1009, when the access type is specified in the message to the SMF, the SMF may perform release for the corresponding access of the MA PDU. When the access type is not specified, release for both accesses is performed.

(97) In step 1010, the remaining handover procedures may be performed. The UE receives a registration accept message from the new AMF. At this time, when there is an MA PDU session which is not included in a PDU session status IE of the corresponding message, the UE may locally release the MA PDU session only for the access for which the registration accept message is received or locally release MA PDU sessions for both access types.

(98) FIG. 11 illustrates a block diagram for the structure of a UE according to an embodiment.

(99) Referring to FIG. 11, the UE may include a transceiver 1110, a UE controller 1120, and a storage unit 1130. In the disclosure, the UE controller 1220 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

(100) The transceiver 1110 may transmit and receive a signal to and from another network entity. The transceiver 1110 may receive, for example, system information from a base station and receive a synchronization signal or a reference signal.

(101) The UE controller 1120 may control the overall operation of the UE according to an embodiment proposed in the disclosure. For example, the UE controller 1120 may control the signal flow between blocks to perform the operation of the UE according to the aforementioned flowchart.

(102) The storage unit 1130 may store at least one piece of information transmitted and received through the transceiver 1110 and information generated through the UE controller 1120.

(103) FIG. 12 illustrates a block diagram for the structure of a higher node according to an embodiment.

(104) The block diagram illustrated in FIG. 12 may be a block diagram of the aforementioned higher nodes, for example, the AMF, the SMF, and the UPF.

(105) In the disclosure, core network entities or network functions such as the AMF, the SMP, and the UPF are all referred to as higher nodes.

(106) Referring to FIG. 12, the higher node may include a transceiver 1210, a higher node controller 1220, and a storage unit 1230. In the disclosure, the higher node controller 1220 may be defined as a circuit, an application-specific integrated circuit, or at least one processor.

(107) The transceiver 1210 may transmit and receive a signal to and from another network entity. The transceiver 1210 may transmit and receive a signal according to an embodiment to and from, for example, adjacent higher nodes.

(108) The higher node controller 1220 may control the overall operation of the higher node according to an embodiment proposed in the disclosure. For example, the higher node controller 1220 may control the signal flow between blocks to perform the operation of the higher node according to the aforementioned flowchart.

(109) The storage unit 1230 may store at least one piece of information transmitted and received through the transceiver 1210 and information generated through the higher node controller 1220.

(110) According to the embodiments, when a UE registered in an AMF which supports ATSSS is registered in an AMF which does not support ATSSS, it is possible to efficiently release old MA PDU sessions to perform smooth communication.

(111) Methods disclosed in the claims and/or methods according to various embodiments described in the specification of the disclosure may be implemented by hardware, software, or a combination of hardware and software.

(112) When the methods are implemented by software, a computer-readable storage medium for storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium may be configured for execution by one or more processors within the electronic device. The at least one program may include instructions that cause the electronic device to perform the methods according to various embodiments of the disclosure as defined by the appended claims and/or disclosed herein.

(113) The programs (software modules or software) may be stored in non-volatile memories including a random access memory and a flash memory, a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a magnetic disc storage device, a compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other type optical storage devices, or a magnetic cassette. Alternatively, any combination of some or all of them may form a memory in which the program is stored. Further, a plurality of such memories may be included in the electronic device.

(114) In addition, the programs may be stored in an attachable storage device which may access the electronic device through communication networks such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), and Storage Area Network (SAN) or a combination thereof. Such a storage device may access, via an external port, a device which performs embodiments of the disclosure. Further, a separate storage device on the communication network may access a device which performs embodiments of the disclosure.

(115) In the above-described detailed embodiments of the disclosure, an element included in the disclosure is expressed in the singular or the plural according to presented detailed embodiments. However, the singular form or plural form is selected appropriately to the presented situation for the convenience of description, and the disclosure is not limited by elements expressed in the singular or the plural. Therefore, either an element expressed in the plural may also include a single element or an element expressed in the singular may also include multiple elements.

(116) Although the present disclosure has been described with various embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.