WO2015069060A1

WO2015069060A1 - Apparatus and method for managing mobility in wireless communication system

Info

Publication number: WO2015069060A1
Application number: PCT/KR2014/010685
Authority: WO
Inventors: 권기석; 예긴알퍼; 박중신; 이진성
Original assignee: 삼성전자주식회사
Priority date: 2013-11-07
Filing date: 2014-11-07
Publication date: 2015-05-14

Abstract

The present invention relates to management of mobility of a terminal in a wireless communication system, and an operating method of the terminal comprises: a step of transmitting a first message requesting mobility-related capability information of an access network, and a step of receiving a second message informing of the mobility-related capability information of the access network. In addition, the present invention includes other embodiments in addition to the aforementioned embodiment.

Description

Apparatus and method for mobility management in wireless communication system

The present invention relates to mobility management in a wireless communication system.

Mobile user equipment (UE), such as mobile phones, tablets, laptops, and the like, may change the point of attachment (PoA) for a network. Each time the UE changes its access point, an IP (Internet Protocol) subnet to which the UE attaches may be different. This change in IP subnet causes a change in the IP address of the UE.

If the IP address is changed while the UE has a data flow with a remote end, a session may be interrupted by the change. For example, if the data flow uses a transmission control protocol (TCP) connection, the TCP connection is broken and a new TCP connection must be established. If the data flow uses a user datagram protocol (UDP) connection, the UDP connection may be maintained until the remote end is informed of the IP address change of the UE.

Various techniques have been proposed to prevent disruption of on-going data flows that may occur for UEs changing IP addresses due to mobility. For example, Client Mobile IP, Proxy Mobile IP, General Packet Radio Service Tunneling Protocol (GTP), Mobility and Multi-homing Protocol (MOBIKE), Multipath TCP (MPTCP), SCTP ( Various techniques, such as stream control transmission protocol (LIP), locator / identifier separation protocol (LISP), host identity protocol (HIP), session initiation protocol (SIP), etc., are provided for the purpose of handling UE mobility or in addition to the main purpose It has been presented for additional purposes. Furthermore, some applications, such as instant messengers, can also manage UE mobility.

One of the differences of the above techniques is the operating network layer. 1 illustrates an example of mobility management schemes divided according to a hierarchical structure. Referring to FIG. 1, the client mobile IP 164 and the MOBIKE 166 operate at the IP layer 138, that is, L3 (layer-3). The LISP, the proxy mobile IP, and the GTP 170, at the sub-IP layer, the operation is not visible in the IP layer of the UE even if using IP-based signaling (signaling) Can be classified as operating. The invisibility is due to the protocols being terminated in the access network and not seen by the UE. The MPTCP 158 and the SCTP 160 operate in a transport layer, namely L4 (layer-4). The SIP 156 operates in a session layer. Application in-

app mobility techniques

152 and 154 operate at the application layer, L7 (layer-7). The higher layer schemes above L4 operate in an end-to-end manner. In other words, the UE and communication remote end are directly related to the execution of such techniques.

Many of the various mobility management schemes that operate in the different network layers described above may be supported by one terminal. However, each mobility management technique operates independently, without consideration of other techniques. Thus, the advantages of each technique cannot be taken at the same time.

An embodiment of the present invention provides an apparatus and method for managing mobility of a terminal in a wireless communication system.

Another embodiment of the present invention provides an apparatus and method for efficient mobility management in a wireless communication system.

Another embodiment of the present invention provides an apparatus and method for providing an optimal data path during handover in a wireless communication system.

Another embodiment of the present invention provides an apparatus and method for supporting seamless handover in a wireless communication system.

Another embodiment of the present invention provides an apparatus and method for obtaining mobility related capability information of a network in a wireless communication system.

Another embodiment of the present invention provides an apparatus and method for obtaining mobility related capability information of a remote end in a wireless communication system.

In a wireless communication system according to an embodiment of the present invention, a method of operating a terminal includes transmitting a first message for requesting mobility-related capability information of an access network, and transmitting the mobility-related capability information of the access network. The notifying includes receiving a second message.

In a wireless communication system according to an embodiment of the present invention, a method of operating a network entity includes receiving a first message requesting mobility-related capability information from a terminal, and transmitting the mobility-related capability information to the terminal. The notifying includes transmitting a second message.

In a wireless communication system according to an embodiment of the present invention, the terminal apparatus includes a transmitter for transmitting a first message for requesting mobility-related capability information of an access network, and a second message for notifying the mobility-related capability information of the access network. It includes a receiving unit for receiving.

In a wireless communication system according to an embodiment of the present invention, a network object apparatus may include a receiver configured to receive a first message requesting mobility-related capability information from a terminal, and a second message informing of the mobility-related capability information to the terminal. And a transmitting unit.

In a handover in which an Internet Protocol (IP) address is changed in a wireless communication system, it is possible to provide an optimal data path and minimize transmission delay due to handover.

1 illustrates an example of mobility management schemes classified according to a hierarchical structure in a wireless communication system.

2 illustrates an example of the impact between mobility management techniques in a wireless communication system.

3 illustrates an example of a detour occurring in a wireless communication system.

4 illustrates an example in which a handover delay occurs in a wireless communication system.

5A to 5F illustrate an example of mobility management in a wireless communication system according to an embodiment of the present invention.

6 illustrates a terminal including a mobility adjusting unit in a wireless communication system according to an embodiment of the present invention.

7 illustrates an example of a hierarchical structure of a terminal and a network in a wireless communication system according to an embodiment of the present invention.

8 illustrates an example of a mobility management scheme supported by a terminal and a network in a wireless communication system according to an embodiment of the present invention.

9A and 9B illustrate examples of a state change of a terminal during handover in a wireless communication system according to an exemplary embodiment of the present invention.

10 is a flowchart illustrating a procedure for checking mobility-related capability of a network in a wireless communication system according to an exemplary embodiment of the present invention.

FIG. 11 is a flowchart illustrating a mobility related capability of a remote end in a wireless communication system according to an exemplary embodiment of the present invention.

12 illustrates a procedure for selecting a mobility management scheme in a wireless communication system according to an embodiment of the present invention.

13 illustrates a procedure for performing handover according to a mobility management scheme selected in a wireless communication system according to an embodiment of the present invention.

14 illustrates an interaction between a mobility adjuster and a mobility management scheme for handover in a wireless communication system according to an embodiment of the present invention.

15 illustrates a signaling procedure between a terminal and network objects in a wireless communication system according to an embodiment of the present invention.

16 illustrates an example of a functional structure of a terminal in a wireless communication system according to an embodiment of the present invention.

17 illustrates a signaling procedure between functional elements and network objects of a terminal in a wireless communication system according to an embodiment of the present invention.

18 illustrates an operation procedure of a terminal in a wireless communication system according to an embodiment of the present invention.

19 illustrates an operation procedure of a terminal in a wireless communication system according to another embodiment of the present invention.

20 illustrates an operation procedure of a network object in a wireless communication system according to an embodiment of the present invention.

21 is a block diagram of a terminal in a wireless communication system according to another embodiment of the present invention.

22 is a block diagram of a network object in a wireless communication system according to an embodiment of the present invention.

Hereinafter, the operating principle of the present invention will be described in detail with reference to the accompanying drawings. In the following description, detailed descriptions of well-known functions or configurations related to the present invention will be omitted when it is determined that the detailed description of the present invention may unnecessarily obscure the subject matter of the present invention. Terms to be described later are terms defined in consideration of functions in the present invention, and may be changed according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout the specification.

Hereinafter, a description will be given of a technique for managing mobility in a wireless communication system.

Terms used to describe the elements of the device used in the following description, terms referring to network entities, terms referring to a connection state, and the like are illustrated for convenience of description. Therefore, the present invention is not limited to the terms described below, and other terms may be used to refer to objects having equivalent technical meanings.

For example, the terminal may be referred to as a user equipemnt (UE), a mobile station (MS), a user terminal (UT), or the like. The terminal may be a portable electronic device used by a user, and may be a smart phone, a portable terminal, a mobile phone, a mobile pad, a media player. (media player), a tablet computer (tablet computer), a handheld computer (handheld computer) or a personal digital assistant (PDA). In addition, the electronic device may be a device combining two or more functions of the above-described devices.

For convenience of description below, the present invention uses the terms and names defined in the 3GPP LTE (3rd Generation Partnership Project Long Term Evolution) standard. However, the present invention is not limited to the above terms and names, and may be equally applied to systems conforming to other standards.

As described above, Client Mobile Internet Protocol (Proxy), Proxy Mobile IP (General), General Packet Radio Service Tunneling Protocol (GTP), Mobility and Multi-homing Protocol (MOBIKE), Multipath TCP (MPTCP), Mobility management techniques such as stream control transmission protocol (SCTP), locator / identifier separation protocol (LISP), host identity protocol (HIP), and session initiation protocol (SIP) are known, and some applications manage mobility management internally. It may include a function for. The application having the mobility management function may notify the communication peer of the new IP address when the IP address of the terminal is changed.

Looking at a networking layer in which the above-described techniques operate, the client mobile IP and the MOBIKE operate in an IP layer, that is, L3 (layer-3). The LISA, the proxy mobile IP, and the GTP operate at a sub-IP layer. The MPTCP and the SCTP operate in a transport layer, that is, L4 (layer-4). The SIP operates at the session layer. In-app mobility techniques operate at the application layer, L7 (layer-7). For convenience of description below, the L4 and higher layers are referred to as 'higher-layers'.

The advantages and disadvantages of mobility management schemes by layer are as follows.

In general, mobility management techniques operating in the sub-IP are available in all 3rd generation (3G) networks and 4th generation (4G) networks. For convenience of description below, the mobility management scheme operating in the sub-IP is referred to as a 'sub-IP scheme'. When the sub-IP scheme is executed, the terminal does not need to execute anything, and most operations are performed by the network. Since the sub-IP schemes operate at a layer below IP, all applications running on the terminal can benefit from them. In addition, the sub-IP techniques can provide seamless handover. The seamless handover is a type of IP handover procedure that minimizes interruptions (e.g., packet loss and delay) for ongoing data flows. The seamless handover is possible when the procedure can be completed by signaling between nearby network elements such as the old access gateway and the new access gateway. A disadvantage of the sub-IP schemes is that IP packets are controlled to be traversed to dedicated network elements such as packet data network gateways (PGWs) or home agents (HAs) in the core network. This de-tour, or triangular route, causes additional latency of end-to-end transmission.

Mobility management techniques operating at the IP layer are available in some terminal stacks, but not all terminals support mobility management techniques operating at the IP layer. For convenience of description, the mobility management scheme operating at the IP layer is referred to as an 'IP layer scheme'. If the IP layer scheme is supported, all applications running on the terminal can benefit from their services. When the IP layer scheme is executed, the seamless handover is also possible. However, IP layer schemes can result in a triangular route, similar to the sub-IP scheme.

Mobility management techniques operating at higher layers are available in some terminal stacks, but not all terminals support mobility management techniques operating at the upper layers. For convenience of description below, mobility management schemes operating in the upper layer are referred to as 'higher layer scheme'. Since the higher layer techniques apply to a subset of applications, they may be supported by some applications. For example, the SCTP only benefits applications that use the SCTP. Applications using TCP are not able to benefit from the SCTP. In addition, the higher layer schemes operate on an end-to-end basis and thus do not provide seamless handover. Handover involving a change of IP address requires end-to-end signaling between the terminal and the remote end. Due to the transmission delay caused by the signaling, the handover procedure cannot be completed in a short time. However, the higher layer techniques can create a direct data path between end points. As a result, a triangular route is not generated, and as a result, unnecessary transmission delay may not occur on the data path by the mobility management scheme.

At least one of the above mobility management schemes may be supported by one terminal. However, each mobility management technique operates independently, without consideration of other techniques. At this time, there is an unintended interaction between the IP / sub-IP layer scheme and the higher layer scheme, as shown in FIG. 2. 2 illustrates an example of the impact between mobility management techniques in a wireless communication system. As shown in FIG. 2, when the IP layer scheme or the sub-IP scheme scheme is used, the upper-layer scheme cannot recognize mobility events. For example, when GTP 270 is used, the GTP 270 blocks the mobility view of the mobile IP 264. This is because when the GTP 270 is used, the terminal maintains a fixed home address. In addition, when the mobile IP 264 is used, the mobile IP 264 blocks the mobility observation of the MPTCP (258). Accordingly, the MPTCP 258 recognizes that it is still connecting to the same IP subnet. That is, even if the IP subnet of the terminal is changed, by the IP / sub-IP scheme, the upper layer scheme cannot recognize the change of the IP address. Therefore, when the IP or the sub-IP layer scheme is adopted, the higher layer scheme is not executed.

For example, when both the IP layer / sub-IP layer scheme and the higher layer scheme are supported, a bypass path as shown in FIG. 3 may be generated. 3 illustrates an example in which the bypass path occurs in a wireless communication system. Referring to FIG. 3, the terminal 310 has a first application 352 having a mobility management (MM) function 353 and a second application 354 having no mobility management function 353. In other words, it is running. The first application 352 communicates with the remote end 1 326-1, and the second application 354 communicates with the remote end 2 326-2. The network 320 includes a local / serving gateway (L / SGW) 322 and a packet data network gateway (PGW) 324. Since the PMIP / GTP 370 is supported in the network 320, the PMIP / GTP 370 is executed. Accordingly, the mobility management function 353 included in the first application 352 of the terminal 310, that is, the application internal mobility management scheme is not executed. In other words, since the mobility event is blocked by a sub-IP scheme (eg, the PMIP / GTP 370), the application internal mobility management scheme does not operate. Accordingly, although the first application 352 has a higher layer scheme, it bypasses the bypass path including the tunnel 392 generated by the PMIP / GTP 370, rather than the shorter path. Communicate via To this end, the IP address IP _HoA used includes the prefix Prefix _PGW corresponding to the PGW 324.

As another example, when only the upper layer scheme is supported, a handover delay may occur as shown in FIG. 4. 4 illustrates an example in which a handover delay occurs in a wireless communication system. Referring to FIG. 4, the terminal 410 includes a first application 452 having a mobility management function 453 and a second application 454 having no mobility management function 453. Running The first application 452 communicates with the remote end 1 426-1, and the second application 454 communicates with the remote end 2 426-2. Network 420 includes LGW (Local gateway) 422. The LGW 422 is a serving gateway of the terminal 410. Since the sub-IP scheme is not supported in the network 420, the mobility management function 453 of the first application 452, that is, an application internal mobility management scheme is executed. Accordingly, the IP address changed by end-to-end signaling is transferred to the remote end 1 426-1 and the remote end 2 426-2, and is shorter than the case of FIG. 3. Communication can be performed. For this purpose, IP addresses that are used include prefixes Prefix _LGW corresponding to the LGW (422). However, due to the end-to-end signaling, the round-trip time increases, which may result in a handover delay. Furthermore, packet loss may occur in the process of reestablishing the connection due to the change of the IP address.

As mentioned above, each mobility management technique has advantages and disadvantages. There is no single technique that can simultaneously provide the seamless handover and the most direct data-path. Accordingly, the present invention presents various embodiments that can achieve the seamless handover and direct data path through coordinated execution of available mobility techniques.

Referring to FIG. 5A, the terminal 510 includes a first application 552 having a mobility management function 553 and a second application 554 having no mobility management function 553. Running The first application 552 communicates with the remote end 1 526-1, and the second application 554 communicates with the remote end 2 526-2. Network 520 includes L / SGW 522 and PGW 524. The first application 552 uses the IP address IP1, and the second application 554 uses the IP address IP2. Here, using the IP address IP1 means setting the source address in the IP header of the packet transmitted from the terminal 510 to the IP1. The IP1 is allocated by the L / SGW 522 and includes a prefix Prefix _LGW corresponding to the L / SGW 522. In addition, the IP2 is allocated by the PGW 524 and includes a prefix Prefix _PGW corresponding to the PGW 524. That is, since the second application 554 uses the IP2 anchored to the PGW 524, data transmitted and received through the second application 554 is transmitted through the tunnel 592. .

Referring to FIG. 5B, two IP addresses of the terminal 510 are bound to different plumbing. The first path corresponding to the first application 552 consists of the first application 552-TCP-IP, and the second path corresponding to the second application 554 corresponds to the second application 554. It consists of TCP-IP. Since the second application 554 uses IP2 including the prefix Prefix _PGW corresponding to the PGW 524, the data transmitted and received through the second application 554 is transmitted to the L / SGW 522. Tunnel 592 is delivered through the PGW 524. In contrast, since the first application 552 uses the IP address IP1 including the prefix Prefix _XGW corresponding to the currently connected gateway, the data transmitted and received through the first application 552 is transmitted to the L / SGW. Passed only through 522.

Referring to FIG. 5C, the terminal 510 performs a handover. That is, the terminal 510 changes the IP subnet from the L / SGW1 522-1 to the L / SGW2 522-2 by movement. Since the first application 552 has the mobility management function 553, the first application 552 may directly set a path through the L / SGW2 522-2 without the tunnel 594. However, according to an embodiment of the present invention, in order to reduce transmission delay due to handover, the data flow of the first application 552 is temporarily anchored to the L / SGW1 522-1, which is a previous access network. Accordingly, the network 520 generates a tunnel 594 between the L / SGW2 522-2 and the L / SGW1 522-1, and uses the tunnel 594 to perform the first application ( The data of 552 is controlled to be transmitted through the L / SGW1 522-1. That is, the L / SGW2 522-2 notifies the L / SGW1 522-1 that the terminal 510 accesses the IP subnet of the L / SGW2 522-2. SGW1 522-1 forwards the packet from the remote end 1 526-1 to the terminal 510 to the L / SGW2 522-2, and the L / SGW2 522-2 is the terminal. The packet from 510 to the remote end 1 526-1 is forwarded to the L / SGW1 522-1. To this end, the first application 552 uses an IP address including the prefix Prefix _LGW1 corresponding to the L / SGW1 522-1. Since the second application 554 does not include the mobility management function 553, the second application 554 still communicates with the PGW 524 by a sub-IP scheme. In this case, the network 520 does not create a tunnel between the L / SGW2 522-2 and the PGW 524, and uses the temporarily generated tunnel 594. That is, the network 522 transfers data of the second application 554 to the PGW 524 through the tunnel 594 and the tunnel 592. To this end, the second application 554 uses an IP address including the prefix Prefix _PGW corresponding to the PGW 524.

Referring to FIG. 5D, a local IP address IP1 ′ for the first application 552 is configured and provided to the mobility management function 553. If it is recognized that the terminal 510 accesses the IP subnet of the L / SGW2 522-2, the terminal 510 requests allocation of a new IP address. As the new IP address, the IP1 'is assigned. Accordingly, the first application 552 establishes a direct path with the remote end 1 526-1 through the L / SGW2 522-2. That is, the IP1 'includes the prefix Prefix _LGW2 corresponding to the L / SGW2 522-2. Accordingly, the first application 522 may temporarily use two paths, a path using the IP1 and a path using the IP1 '.

Referring to FIG. 5E, the first application 522 reconfigures the anchored IP address IP1 after completing the direct path setup. That is, the first application 522 releases the IP1. In other words, the first application 522 uses only the IP1 '. To this end, the first application 522 may transmit a message indicating the release of the IP1 to the L / SGW1 522-1. Alternatively, as the setting of the direct path is completed, the L / SGW2 522-2 may transmit a message notifying release of the IP1 to the L / SGW1 522-1. Alternatively, the IP1 may be released as the direct path is completed, without an explicit message indicating release of the IP1. In this case, the L / SGW2 522-2 may notify the L / SGW1 522-1 of setting up the direct path, that is, completing IP handover.

Referring to FIG. 5F, the network 520 reconstructs the core anchor tunnel and unplumbing the temporarily generated tunnel 594. That is, since the tunnel 594 is removed, there is no path for transmitting the data of the second application 554 to the PGW 524, so that the L / SGW2 522-2 and the PGW 524 exist. ) Tunnel 596 is created, and the tunnel 592 between the L / SGW1 522-1 and the PGW 524 is removed.

In order to perform the procedure as illustrated in FIGS. 5A to 5F, the terminal may include components as shown in FIG. 6. 6 illustrates a terminal including a mobility orchestrator in a wireless communication system according to an embodiment of the present invention. The mobility adjustment unit may be referred to as a 'multi-layer mobility controller'. Referring to FIG. 6, the terminal 610 includes a first application 652 having a mobility management function 653 and a second application 654 not having the mobility management function 653. According to an embodiment of the, the mobility adjustment unit 612 further includes.

The mobility adjustment unit 612 controls coordinated execution between a plurality of mobility management techniques so that the procedures illustrated in FIGS. 5A to 5F can be performed. Specifically, the mobility adjustment unit 612 has the ability to engage different mobility protocols to operate in association with each other. In this case, which mobility protocol, that is, mobility management techniques, may be determined according to mobility-related capabilities of the terminal 610, the network 620, and the remote terminals 626-1 and 626-2. In addition, the mobility adjustment unit 612 may execute different mobility protocols using tight coordination. In this way, the mobility adjusting unit 612 may provide an optimal data path while providing a seamless handover during handover.

Referring to FIG. 7, the terminal 710 includes an application layer 732, a session layer 734, a transport layer 736, and an IP layer 738, and the network 720 includes a sub-IP layer 740. ). According to an embodiment of the present invention, the terminal 710 includes a mobility adjustment unit 712 which is a new functional entity for interaction between a plurality of layers. The mobility adjustment unit 712 is a method of mobility management scheme through an orchestrated way to achieve seamless handover using the most direct data path on a per-flow basis. Determine the best combination and run it.

As a specific example, the function of the mobility adjusting unit 712 is as follows. The mobility adjustment unit 712 may discover the capabilities of the terminal 710 and the network 720. That is, the mobility adjustment unit 712 discovers which mobility management scheme is provided by the terminal 710 and the network 720. For example, the mobility adjusting unit 712 may confirm that the terminal 710 supports MPTCP and the network 720 supports proxy mobile IP. The mobility adjuster 712 can also discover the capabilities of the remote termination. In other words, the mobility adjustment unit 712 searches for which mobility management scheme is supported by the remote end. For example, the mobility adjustment unit 712 may confirm that the remote end supports MPTCP. The mobility adjuster 712 may determine an optimal set of mobility management techniques to use for a given data flow. In detail, the mobility adjustment unit 712 may determine a primary mobility management technique and an auxiliary mobility management technique to be applied to the given data flow. For example, for a particular application, the mobility adjustment unit 712 may determine to apply an application internal mobility management scheme using a temporary proxy mobile IP for seamless handover. In addition, the mobility adjusting unit 712 may control coordinated execution of selected mobility techniques for a specific data flow.

Hereinafter, a control procedure of the mobility adjustment unit according to an embodiment of the present invention will be described using specific examples.

8 illustrates an example of a mobility management scheme supported by a terminal and a network in a wireless communication system according to an embodiment of the present invention. Referring to FIG. 8, the terminal 810 supports the MPTCP 858 operating in the transport layer, and the network 820 supports the GTP 870 operating in the sub-IP layer. Accordingly, the mobility adjustment unit 812 controls the cooperative execution between the MPTCP 858 and the GTP 870.

For example, the mobility adjustment unit 812 may be used for an application in which the network 820 provides the GTP 870 as a sub-IP scheme, and the MPTCP 858 is running in the terminal 810. find (available) The mobility coordinator 812 also finds that the remote end of the application supports the MPTCP 858. Since the terminal 810 and the remote end support the MPTCP 858, the mobility adjustment unit 812 gives the MPTCP 858 a primary role for mobility management, and the corresponding data flow. Disables the GTP 870 for. However, for seamless handover of the terminal 810, the mobility adjustment unit 812 may temporarily enable the GTP 870. The temporary intable of the GTP 870 is illustrated in FIGS. 9A and 9B below.

9A and 9B illustrate examples of a state change of a terminal during handover in a wireless communication system according to an exemplary embodiment of the present invention. 9A illustrates a previous section in which the terminal 910 moves from the source access gateway 922-1 (s-XGW: source access gateway) to the target access gateway 922-2 (t-XGW: target access gateway). transition period). Referring to FIG. 9A, after the terminal 910 connects to the target access gateway 922-2, the mobility adjustment unit 912 determines an IP address obtained by the terminal 910 from the serving access gateway. Instruct the network to establish an inter-access gateway tunnel 992 so that IP1 can continue to be used. The IP1 is an IP address used for ongoing data flow with the remote end 926. At the same time, the mobility coordination unit 912 instructs the network to allocate a new IP address IP2 from the target access gateway 922-2, which is not served by the GTP. That is, the IP address IP2 is not anchored to the core network element, but directly anchored to the target access gateway 922-2. The mobility coordinator 912 may enable the MPTCP in the terminal 910 to perform an IP handover with a peer at the remote end 926, and a new IP address available for the MPTCP of the terminal 910. Notify IP2.

Referring to FIG. 9B, the mobility adjustment unit 912 is notified by the MPTCP after the MPTCP completes the handover. At this time, the mobility adjustment unit 912 instructs the network to tear down the tunnel 992 between the source access gateway 922-1 and the target access gateway 922-2 and release the IP1. do. As a result, the terminal 910 maintains the IP2 and uses the IP2 for communication with the peer through the ongoing data flow.

As shown in FIGS. 9A and 9B, seamless handover according to an embodiment of the present invention may include the most direct data path between the terminal 910 and the remote end 926. While MPTCP is operating as the primary mobility management scheme to take advantage of the most direct data path, it may be achieved by temporary use of the GTP tunnel 992 between gateways.

According to the above embodiments, the terminal or the mobility adjustment unit in the terminal obtains the mobility-related capability information of the terminal, the network, the remote end that is the communication partner (correspondent). The mobility coordination unit probes a stack, inspects configuration files in the stack, or has its own configuration file describing what techniques are provided in the same stack. Discover related abilities. The configuration file may be generated manually or dynamically.

In general, some network structures, such as 3rd generation partnership project (3GPP), provide default mobility management techniques such as GTP, proxy mobile IP, and the like. If the network is known to follow such a structure, the mobility coordinator may assume that mobility management schemes such as the GTP and the proxy mobile IP are supported. If the mobility-related capability of the network is not known in advance, the mobility coordinator may transmit a probe message that explicitly discovers the mobility-related capability of the network. For example, a new DHCP option may be defined for performing this discovery via dynamic host configuration protocol (DHCP). For example, the mobility-related capability of the network can be identified as shown in FIG. 10.

10 is a flowchart illustrating a procedure for checking mobility-related capability of a network in a wireless communication system according to an exemplary embodiment of the present invention. Referring to FIG. 10, in step 1001, the terminal 1010 transmits a request for mobility capability information of a network to the gateway 1022. For example, the request may be transmitted during the initial access procedure of the terminal 1010. As another example, the request may be transmitted after entering the network of the terminal 1010. In step 1003, the gateway 1022 transmits mobility capability information to the terminal 1010. For example, the mobility capability information may indicate at least one mobility management scheme supported by the network. Specifically, the mobility capability information may indicate proxy mobile IP v6 (version 6), proxy mobile IP v4 (version 4), mobile IP v4 FA (Forign Agent), and the like.

In order to check the mobility related information of the remote end, the terminal may use a domain name system (DNS) query. It is assumed that the administrator of the remote end provides this additional information about its host to the DNS. If the DNS does not have any mobility information for the remote end, the terminal may assume that the remote end does not support anything. For example, the mobility-related capability of the network can be identified as shown in FIG.

FIG. 11 is a flowchart illustrating a mobility related capability of a remote end in a wireless communication system according to an exemplary embodiment of the present invention. Referring to FIG. 11, in step 1101, the terminal 1110 transmits a request for mobility capability information of a specific remote end to the DNS server 1128. In the request, the specific remote end may be identified by the domain name of the specific remote end. For example, the request may be sent with a query of an IP address via a domain name, or may be sent separately from a query of the IP address. In step 1103, the DNS server 1128 transmits mobility-related capability information of the specific remote end to the terminal 1110. For example, the mobility capability information may indicate at least one mobility management scheme supported by the network.

The mobility coordinator of the terminal may execute an algorithm for determining an optimal set of mobility techniques to be executed for a given data flow. For example, the mobility coordinator selects the highest layer scheme among the mobility management schemes common between the terminal and the remote end, and disables another mobility scheme. Specifically, if application in-app mobility, SCTP, and client mobile IP are available, the mobility coordinator enables the application internal mobility and disables the SCTP and client mobility IP. However, the mobility coordinator temporarily enables tunneling between gateways using a technique available at the lowest layer. For example, if a client mobile IP and a proxy mobile IP are available, the mobility adjustment unit uses the proxy mobile IP. 12, 13, and 14 below are examples of the algorithms.

Referring to FIG. 12, the terminal checks the end-to-end mobility management protocol of the remote end in step 1201. In other words, the terminal identifies an end-to-end mobility management scheme supported by the remote end. For example, the terminal can identify the mobility management scheme supported by the remote end from a separate server. For example, the separate server may be a DNS server, in which case a DNS query may be used.

In step 1203, the terminal determines whether a common protocol exists between the terminal and the remote end. In other words, the terminal determines whether at least one common mobility management scheme is supported between the terminal and the remote end. That is, the terminal determines whether it can support at least one of at least one mobility management scheme supported by the remote end.

If the common protocol exists, the terminal proceeds to step 1205 and selects one of the at least one common protocol as the primary mobility management scheme. That is, since the end-to-end mobility management scheme provides a direct data path, the terminal selects the end-to-end mobility management scheme as the main scheme for the optimal data path. For example, the terminal may select the highest layer scheme among common mobility management schemes. If multiple mobility management schemes exist in the same layer, the terminal may select one mobility management scheme based on a preference list. For example, the preference list may be defined as MPMP over SCTP, client mobile IP over MOBKE, and the like.

In step 1207, the terminal determines whether the access network supports the IP / sub-IP mobility management scheme. In other words, the terminal determines whether the network supports a mobility management scheme based on anchoring, that is, tunneling. For example, the terminal may determine whether the access network supports the IP / sub-IP mobility management scheme based on previously known information. As another example, the terminal may check whether the access network supports the IP / sub-IP mobility management scheme by querying an entity in the access network. For example, the entity may be a gateway. If it is confirmed at the time of initial access whether the IP / sub-IP mobility management scheme is supported, the inquiry procedure may be omitted.

If the access network supports the IP / sub-IP mobility management scheme, the terminal proceeds to step 1209 to assist one of at least one IP / sub-IP mobility management scheme supported by the access network. Select a mobility management technique. In other words, the terminal selects one of the at least one IP / sub-IP mobility management scheme as a mobility management scheme to be used temporarily.

On the other hand, if the access network does not support the IP / sub-IP mobility management scheme, the terminal proceeds to step 1211 and determines that the auxiliary mobility management scheme is not defined. That is, the terminal does not define a mobility management scheme to be used temporarily during the handover process.

In step 1203, if there is no common protocol between the terminal and the remote node, the terminal proceeds to step 1213 to determine whether the access network supports the IP / sub-IP mobility management scheme. In other words, the terminal determines whether the network supports a mobility management scheme based on anchoring, that is, tunneling. For example, the terminal may determine whether the access network supports the IP / sub-IP mobility management scheme based on previously known information. As another example, the terminal may check whether the access network supports the IP / sub-IP mobility management scheme by querying an entity in the access network. For example, the entity may be a gateway. If it is confirmed at the time of initial access whether the IP / sub-IP mobility management scheme is supported, the inquiry procedure may be omitted.

If the access network supports the IP / sub-IP mobility management scheme, the terminal proceeds to step 1215 and performs one of at least one IP / sub-IP mobility management scheme supported by the access network. Select by technique. At the same time, the terminal determines that the auxiliary mobility management scheme is not defined. That is, the terminal does not define a mobility management scheme to be used temporarily during the handover process.

On the contrary, if the access network does not support the IP / sub-IP mobility management scheme, the terminal proceeds to step 1217 and determines that the main mobility management scheme and the auxiliary mobility management scheme are not defined. That is, the terminal determines that no mobility management scheme is used. In this case, during handover, the session connection may be disconnected.

Referring to FIG. 13, the terminal determines whether a mobility management scheme is used in step 1301. For example, if there is no mobility management scheme common between the terminal and the remote end, and the access network does not support the mobility management scheme, the mobility management scheme may not be used.

If the mobility management scheme is not used, the terminal proceeds to step 1303 and releases the previous IP address. The previous IP address means an IP address assigned by the serving gateway before handover. Accordingly, the session established based on the previous IP address may be terminated.

In step 1305, the terminal configures a new IP address in the new serving gateway. That is, the terminal is assigned a new IP address from the serving gateway after the handover. Accordingly, the terminal can establish a new session using the new IP address.

In step 1301, if the mobility management scheme is used, the terminal proceeds to step 1307 to determine if the mobility management scheme operating only in the sub-IP is used. That is, the terminal determines that there is no common upper layer scheme between the terminal and the remote end, and that the mobility management scheme operating in the sub-IP is supported by the access network.

If the mobility management scheme operating only in the sub-IP is used, the terminal proceeds to step 1309 and anchors the IP address in the previous gateway using the sub-IP mobility management scheme. Accordingly, the terminal is anchored to the previous serving gateway after the handover, and transmits and receives data through a bypass path including a tunnel between the current serving gateway and the previous serving gateway.

If the mobility management scheme operating only in the sub-IP is not used, the terminal proceeds to step 1311 to determine whether only the main mobility management scheme of the upper layer is used and the auxiliary mobility management scheme is not used. Here, the upper layer means a layer of L3 or more or L4 or more. That is, the terminal determines whether there is a higher layer scheme common between the terminal and the remote end and the mobility management scheme operating in sub-IP is not supported by the access network.

If only the main mobility management scheme of the upper layer is used, the terminal proceeds to step 1313 to release the previous IP address. The previous IP address means an IP address assigned by the serving gateway before handover.

In step 1315, the terminal configures a new IP address in the new serving gateway. That is, the terminal is assigned a new IP address from the serving gateway after the handover. Accordingly, the terminal can establish a new session using the new IP address.

In step 1317, the terminal performs handover using the mobility management scheme of the higher layer. The handover refers to the handover of the IP layer. Accordingly, transmission delay may occur, but disconnection of the connection may be prevented. For the handover, the terminal may perform signaling for the handover. The signaling may include at least one of transmitting at least one signal or receiving at least one signal. For example, the terminal may transmit a message indicating a new IP address, that is, an allocated IP address from the serving gateway after handover, to the other end.

In step 1311, if only the main mobility management scheme of the upper layer is not used, the terminal proceeds to step 1319 and anchors the IP address to the previous gateway using the auxiliary mobility management scheme. The anchoring is by temporary use of the auxiliary mobility management technique. That is, the terminal requests tunneling between the old serving gateway and the new serving gateway to the network, and uses the IP address allocated from the previous serving gateway.

In step 1321, the terminal configures a new IP address in the new serving gateway. That is, the terminal is assigned a new IP address from the serving gateway after the handover. Accordingly, the terminal can establish a new session using the new IP address.

Subsequently, the terminal proceeds to step 1323 to perform a handover using the mobility management scheme of the higher layer. The handover refers to the handover of the IP layer. For the handover, the terminal may perform signaling for the handover. The signaling may include at least one of transmitting at least one signal or receiving at least one signal.

In step 1325, the terminal determines whether there is a data flow using the sub-IP mobility management scheme as the main mobility management scheme. The main mobility management scheme may be selected for each data flow. This is because higher layer mobility management is not supported in all applications. Therefore, there may exist a data flow that is not subjected to the mobility management scheme of the upper layer.

If there is no data flow using the sub-IP mobility management scheme as the main mobility management scheme, the terminal proceeds to step 1327 to release the anchored IP address. That is, since there is no data flow not subject to the mobility management scheme of the higher layer, there is no need to maintain a temporarily generated tunnel after IP handover. Accordingly, the terminal releases the anchored IP address, thereby controlling all data paths to have direct paths.

Referring to FIG. 14, in step 1401, the mobility adjustment unit determines whether a mobility management scheme of a sub-IP layer or more is used. If the mobility management scheme above the sub-IP layer is used, in step 1403, the mobility coordinator enables the IP address anchored to the previous serving gateway. Subsequently, in step 1405, the mobility adjustment unit configures a new serving gateway and a new IP address. In step 1407, the mobility coordinator notifies the selected mobility management scheme of the availability of the new IP address. Accordingly, in step 1409, the mobility management scheme initiates mobility management signaling using the new IP address. In step 1411, the mobility management scheme notifies the mobility coordinator of successful completion of mobility management signaling. Accordingly, in step 1413, the mobility adjustment unit receives a notification from the mobility management scheme. Then, in step 1415, the mobility adjustment unit determines whether there is another session using the anchored IP address. If there is no other session using the anchored IP address, in step 1417, the mobility adjustment unit releases the anchored IP address.

15 illustrates a signaling procedure between a terminal and network objects in a wireless communication system according to an embodiment of the present invention. 15 illustrates a signaling procedure from initial access to handover of the terminal. In the embodiment illustrated in FIG. 15, signaling not directly related to the present invention is omitted.

Referring to FIG. 15, in step 1501, the terminal 1510 checks mobility-related capabilities of the terminal 1510. In other words, the terminal 1510 identifies at least one mobility management scheme supported by the terminal 1510.

In step 1503, the terminal 1510 checks the mobility-related capability of the network through the source access gateway 1522-1. For example, the terminal 1510 may transmit a message requesting the mobility-related capability to the source access gateway 1522-1 and receive a response message from the source access gateway 1522-1. . For example, the terminal 1510 may perform the procedure as shown in FIG. 10.

In step 1505, the terminal 1510 confirms mobility-related capability of the remote end 1526. To this end, the terminal 1510 may transmit a message requesting the mobility-related capability of the remote end 1526 to the DNS server 1628, and receive a response message from the DNS server 1628. For example, the message requesting the mobility-related capability may be included in a DNS query. For example, the terminal 1510 may perform the procedure as shown in FIG. 11.

In step 1507, the terminal 1510 may start an IP flow with the remote end 1526 using the IP address IP1. In other words, the terminal 1510 and the remote end 1526 may transmit and receive data through a data flow established based on the IP1.

In step 1509, the terminal 1510 determines the change of the IP subnet. That is, the IP subnet may change due to the movement of the terminal 1510, and the terminal 1510 may recognize the change of the IP subnet.

In step 1511, the terminal 1510 checks the mobility-related capability of the network through the target access gateway 1522-2. For example, the terminal 1510 may transmit a message requesting the mobility-related capability to the target access gateway 1522-2 and receive a response message from the target access gateway 1522-2. . For example, the terminal 1510 may perform the procedure as shown in FIG. 10.

In step 1513, the terminal 1510 requests IP address anchoring for the IP1. That is, the terminal 1510 requests the target access gateway 1522-2 to create a tunnel between the target access gateway 1522-2 and the source access gateway 1522-1, and to bypass data. .

In step 1515, the terminal 1510 requests allocation of a new IP address IP2 that is not anchored. That is, since the anchoring of the IP1 is temporary, the terminal 1510 requests allocation of an IP address to form a direct path.

In step 1517, the terminal 1510 provides a new IP address IP2 as a higher layer mobility protocol. That is, the terminal 1510 internally provides the IP2 to the mobility management scheme of the higher layer for handover by the mobility management scheme of the higher layer.

In step 1519, the terminal 1510 performs a higher layer mobility protocol handover from IP1 to IP2. The handover may be performed according to a procedure defined by the mobility management scheme of the higher layer. That is, the terminal 1510 may perform signaling for the handover. The signaling may include at least one of transmitting at least one signal or receiving at least one signal.

In step 1521, the terminal 1510 requests to end anchoring of IP1 according to completion of higher layer mobility management. That is, since the direct path is established with the remote end 1526 through the target access gateway 1522-2 due to the handover, the terminal 1510 may remove the bypass path temporarily used. Request termination of anchoring.

Referring to FIG. 16, the terminal includes a mobility controller 1612, an IP layer mobility protocol module 1613, an IP address configuration module 1614, an IP handover module 1615, and a DHCP client. Module 1616, DNS client module 1615, and higher layer mobility protocol module 1618.

The mobility coordinator 1612 interacts with the IP layer mobility protocol module 1613 and the higher layer mobility protocol module 1618 to discover their presence.

The IP handover module 1615 detects a change in the IP subnet, and triggers an action to be taken by the mobility adjustment unit 1612. The mobility adjuster 1612 interacts with the IP address configuration module 1614 in response to IP handover. The IP address configuration module 1614 may operate according to a plurality of protocols such as DHCP, IPv6 stateless address autoconfiguration (SLAAC), packet data protocol (PDP), and the like. The client side of the protocols is included in the terminal and operates according to a server side and each protocol existing outside the terminal. Depending on the data flow and associated mobility techniques managed by the mobility coordinator 1612, at least one anchored IP address may be requested by the mobility coordinator 1612 in accordance with the IP handover and may not be anchored. That is, a local IP address may be requested by the mobility adjustment unit 1612 according to the IP handover.

When a new IP address is available and the mobility coordinator 1612 knows that an IP-layer or higher layer mobility protocol is waiting to be used, the mobility coordinator 1612 may request to use the new IP address for each mobility protocol module ( 1613, 1618. When each of the mobility protocols 1613 and 1618 completes the IP handover, the mobility coordinator 1612 is notified of the completion of the IP handover. Accordingly, the mobility adjustment unit 1612 determines the time to release the IP address, and notifies the IP address configuration module 1614 of the release of the IP address.

The mobility coordinator 1612 may interact with the DHCP client module 1616 to discover the mobility capabilities of the network. The DHCP client module 1616 may perform signaling and operation according to a DHCP protocol in turn with a DHCP server which is an external entity. The IP address configuration module 1614 may perform signaling according to DHCP. Thus, the DHCP client module 1616 can be included in the IP address configuration module 1614. The mobility coordinator 1612 may interact with the DNS client module 1617 to obtain the mobility capability of the remote end. The DNS client module 1617 controls signaling according to external DNS servers and the DNS protocol.

Referring to FIG. 16, an interface 1 between the mobility adjustment unit 1612, the IP layer mobility protocol module 1613, and the higher layer mobility protocol module 1618 is defined, and the mobility adjustment unit 1612 is defined. The interface 2 between the IP address configuration module 1614 is defined, the interface 3 between the mobility adjustment unit 1612 and the IP handover module 1615 is defined, and the mobility adjustment unit 1612 and the DHCP client module 1616 are defined. ) Interface 4 is defined, and interface 5 between the mobility adjustment unit 1612 and the DNS client module 1617 is defined. For example, functions provided in each interface may be defined as shown in Tables 1 to 5 below.

Table 1

TABLE 2

TABLE 3

Table 4

Table 5

Referring to FIG. 17, in step 1731, the MPTCP 1719 registers mobility capability with the mobility adjustment unit 1712. For example, the MPTCP 1719 may use the function 'Register_mobility_capability (capabilities)' illustrated in Table 1 above.

In step 1733, the mobility adjustment unit 1712 discovers the mobility capability of the network using the DHCP client module 1716 and configures a local IP address. For example, the DHCP client module 1716 may use the function 'Discover_Network_Mobility_Capability' illustrated in Table 4 above. Accordingly, the source access gateway 1722-1 provides mobility related capability information of the network.

In operation 1735, the application 1711 queries the DNS client module 1917 for the host name of the remote end 1726. In other words, the application 1711 triggers the DNS client module 1917 to send a DNS query to the DNS server 1728. Accordingly, the DNS client module 1917 requests the host name of the remote end 1726 to the DNS server. The host name may be requested through a DNS query, and the DNS query may include a request for mobility capability.

In step 1737, the DNS client module 1917 receives the host name of the remote end 1726 to the DNS server 1728, and also discovers the mobility-related capability of the remote end 1726. That is, the DNS server 1728 provides a host name of the remote end 1726 and mobility-related capability information of the remote end 1726.

In step 1739, the application 1711 and the remote end 1726 start an end-to-end IP flow. Accordingly, the application 1711 and the remote end 1726 transmit and receive data through the IP flow.

In step 1741, the IP handover module 1715 detects the change in the IP subnet, and notifies the mobility adjustment unit 1712 of the change in the IP subnet. To this end, the IP handover module 1715 may use the function 'IP_subnet_change_detected' illustrated in Table 3 above.

In step 1743, the mobility adjustment unit 1712 discovers network mobility capability through the DHCP client module 1716. For example, the DHCP client module 1716 may use the function 'Discover_Network_Mobility_Capability' illustrated in Table 4 above. Accordingly, the target access gateway 1722-2 provides mobility related capability information of the network.

In step 1745, the mobility adjustment unit 1712 requests an IP address anchoring to the target access gateway 1722-2 through the DHCP client module 1716. That is, the mobility adjustment unit 1712 requests the target access gateway 1722-2 to create a tunnel between the target access gateway 1722-2 and the source access gateway 1722-1, and to bypass data. do. To this end, the mobility adjusting unit 1712 may use the function 'Request_IP_anchoring (IPaddr)' illustrated in Table 2. In this case, the parameter 'IPaddr' is set to an IP address allocated from the source access gateway 1722-1. According to another embodiment of the present invention, step 1745 may be performed through the IP address configuration module 1614.

In step 1747, the mobility adjustment unit 1712 requests a new IP address, that is, a local IP address, which is not anchored to the target access gateway 1722-2 through the DHCP client module 1716. That is, since the anchoring is temporary, the mobility adjustment unit 1712 requests allocation of an IP address for forming a direct path. To this end, the mobility adjustment unit 1712 may use the function 'Request_local_IPaddr' illustrated in Table 2. According to another embodiment of the present disclosure, step 1747 may be performed through the IP address configuration module 1614.

In step 1749, the mobility adjustment unit 1712 notifies the MPTCP 1917 of the availability of a new IP address. To this end, the mobility adjusting unit 1712 may use the function 'New_IP_address_available (IPaddr)' illustrated in Table 1 above. In this case, the parameter 'IPaddr' is set to an IP address allocated from the target access gateway 1722-2.

In step 1751, the MPTCP 1917 performs an MTPCP handover from the anchored IP address to the local IP address. The handover may be performed according to the procedure defined by the MPTCP. That is, the MPTCP 1725 may perform signaling for the handover. The signaling may include at least one of transmitting at least one signal or receiving at least one signal.

In step 1753, the MPTCP 1719 notifies the mobility adjustment unit 1712 of the completion of the handover. To this end, the MPTCP 1917 may use the function 'Handover_done (IPaddr)' illustrated in Table 1 above.

In step 1755, the mobility adjustment unit 1712 releases the anchored IP address of the IP address configuration module 17. To this end, the mobility adjustment unit 1712 performs the function 'Release_IP_address (IPaddr) illustrated in Table 2. In this case, the parameter 'IPaddr' is set to an IP address allocated from the source access gateway 1722-1. According to another embodiment of the present invention, the step 1755 is the IP address. It may be performed through the configuration module 1614.

Referring to FIG. 18, in step 1801, the terminal transmits a message for requesting mobility related capability information. Here, the requested mobility-related capability information may be mobility-related capability information of a network or a counterpart end performing communication. For example, when mobility-related capability information of the network is requested, the terminal may transmit the message to the gateway upon initial access or handover. As another example, when the mobility-related capability information of the counterpart end is requested, the terminal may transmit the message to the DNS server when generating a data flow with the counterpart end. However, according to another embodiment of the present invention, the terminal may transmit the message to the counterpart end.

In step 1803, the terminal receives a message indicating the mobility-related capability. For example, when the mobility-related capability information of the network is requested, the terminal receives the mobility-related capability information of the network from the gateway. In this case, the message may inform at least one mobility management scheme operating at an IP layer or a sub-IP layer supported in the network. As another example, when the mobility-related capability information of the counterpart end is requested, the terminal receives the mobility-related capability information of the counterpart end from the DNS server. In this case, the message may inform at least one mobility management scheme (eg, mobility management scheme operating in a higher layer) operating in an end-to-end manner supported by the counterpart end.

Referring to FIG. 19, in step 1901, the terminal transmits a request for anchoring of the first IP address allocated by the first gateway. That is, the terminal performs a handover by moving, and thus the IP subnet is changed. Accordingly, since the serving gateway is changed, an anchoring request for the first gateway, which is the previous access gateway, is requested to the second gateway, which is a new access gateway.

Subsequently, the terminal proceeds to step 1903 and transmits a request for allocation of a second IP address to the second gateway. That is, the terminal requests allocation of a local IP address. Accordingly, the terminal is assigned the second IP address. In addition, the terminal may establish a direct path using the second IP address.

In step 1905, the terminal performs a handover between the first IP address and the second IP address. The handover may be performed by a mobility management scheme commonly supported between the terminal and the other end. To this end, the terminal may perform signaling for the handover.

In step 1907, the terminal transmits a request for termination of anchoring of the first IP address. That is, when the handover between the IP addresses is completed, the end of the anchoring is requested to transmit and receive data through the direct path through the second gateway instead of the bypass path through the anchoring. In other words, the anchoring is temporarily maintained during the handover procedure. To this end, the terminal may request the release of the first IP address to the first gateway. Accordingly, the terminal sets the source address of the packet transmitted to the counterpart end as the second IP address.

20 illustrates an operation procedure of a network object in a wireless communication system according to an embodiment of the present invention. The network object that is the operation subject of FIG. 20 may be one of a gateway and a DNS server.

Referring to FIG. 20, in operation 2001, the network object receives a message for request for mobility related capability information from the terminal. Here, the requested mobility-related capability information may be mobility-related capability information of a network or a counterpart end performing communication. For example, when the network object is the gateway, mobility related capability information of the network is requested. As another example, when the network object is the DNS server, mobility related capability information of the other party's terminal communicating with the terminal is requested.

In step 2003, the network object transmits a message indicating the mobility-related capability to the terminal. For example, when the network object is the gateway, the message may inform at least one mobility management scheme of operating in an IP layer or a sub-IP layer supported in the network. As another example, when the network object is the DNS server, the message may inform at least one mobility management scheme (eg, mobility management scheme operating at a higher layer) that operates in an end-to-end manner supported by the counterpart end. .

Referring to FIG. 21, the terminal includes a radio frequency (RF) processor 2110, a baseband processor 2120, a storage 2130, and a controller 2140.

The RF processor 2110 performs a function for transmitting and receiving a signal through a wireless channel such as band conversion and amplification of a signal. That is, the RF processor 2110 up-converts the baseband signal provided from the baseband processor 2120 into an RF band signal and transmits the same through an antenna, and transmits an RF band signal received through the antenna to a baseband signal. Downconvert to. For example, the RF processor 2110 may include at least one of a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog converter (DAC), and an analog to digital converter (ADC). Can be. In FIG. 21, only one antenna is illustrated, but the terminal may include a plurality of antennas. In addition, the RF processor 2110 may include a plurality of RF chains. In addition, the RF processor 2110 may perform beamforming. For the beamforming, the RF processor 2110 may adjust the phase and magnitude of each of the signals transmitted and received through a plurality of antennas or antenna elements.

The baseband processor 2120 performs a baseband signal and bit string conversion function according to the physical layer standard of the system. For example, during data transmission, the baseband processor 2120 generates complex symbols by encoding and modulating a transmission bit stream. In addition, when receiving data, the baseband processor 2120 restores the received bit string by demodulating and decoding the baseband signal provided from the RF processor 2110. For example, according to an orthogonal freqeuncy division multiplexing (OFDM) scheme, during data transmission, the baseband processor 2120 generates complex symbols by encoding and modulating a transmission bit stream and maps the complex symbols to subcarriers. After that, OFDM symbols are configured through an inverse fast Fourier transform (IFFT) operation and cyclic prefix (CP) insertion. In addition, when receiving data, the baseband processor 2120 divides the baseband signal provided from the RF processor 2110 in OFDM symbol units and performs the signals mapped to the subcarriers through a fast Fourier transform (FFT) operation. After reconstruction, the reception bit stream is reconstructed by demodulation and decoding.

The baseband processor 2120 and the RF processor 2110 transmit and receive signals as described above. Accordingly, the baseband processor 2120 and the RF processor 2110 may be referred to as a transmitter, a receiver, a transceiver, or a communicator. Furthermore, at least one of the baseband processor 2120 and the RF processor 2110 may include a plurality of communication modules to support a plurality of different communication standards. In addition, at least one of the baseband processor 2120 and the RF processor 2110 may include different communication modules to process signals of different frequency bands.

The storage unit 2130 stores data such as a basic program, an application program, and setting information for the operation of the terminal. In particular, the storage unit 2130 may include mobility-related information. The mobility related information includes information on at least one mobility management scheme supported by the terminal, a communicating party's terminal, an access network, and at least one mobility management scheme selected to be used when the terminal changes an IP subnet. The storage unit 2130 provides stored data at the request of the controller 2140.

The controller 2140 controls the overall operations of the terminal. For example, the controller 2140 transmits and receives a signal through the baseband processor 2120 and the RF processor 2110. In addition, the controller 2140 records and reads data in the storage 2140. To this end, the controller 2140 may include at least one processor. For example, the controller 2140 may include a communication processor (CP) for performing control for communication and an application processor (AP) for controlling a higher layer such as an application program. According to an embodiment of the present disclosure, the controller 2140 includes a mobility manager 2142 that manages mobility according to a change of an IP subnet due to movement of the terminal. The mobility manager 2142 may control overall functions for mobility management. For example, the mobility manager 2142 may perform at least one of the mobility adjuster 1612 and at least one module illustrated in FIG. 16. For example, the controller 2140 may be configured such that the terminal is illustrated in FIGS. 5A to 6F, 6, 9A and 9B, 10, 11, 12, 13, and 13. 14, 15, 17, 18, and 19 may be controlled to perform the procedure. Operation of the control unit 2140 according to an embodiment of the present invention is as follows.

According to an embodiment of the present disclosure, the controller 2140 generates a message for requesting mobility-related capability information and transmits the message through the baseband processor 2120 and the RF processor 2110. Here, the requested mobility-related capability information may be mobility-related capability information of a network or a counterpart end performing communication. Subsequently, the controller 2140 receives a message indicating the mobility-related capability. For example, when the mobility-related capability information of the network is requested, the controller 2140 receives the mobility-related capability information of the network from the gateway. In this case, the message may inform at least one mobility management scheme operating at an IP layer or a sub-IP layer supported in the network. As another example, when the mobility related capability information of the counterpart end is requested, the controller 2140 receives the mobility related capability information of the counterpart end from the DNS server. In this case, the message may inform at least one mobility management scheme (eg, mobility management scheme operating in a higher layer) operating in an end-to-end manner supported by the counterpart end.

According to another embodiment of the present disclosure, the controller 2140 may operate as follows when handover in which an IP subnet is changed. The controller 2140 transmits a request for anchoring of the first IP address allocated by the first gateway. In operation 1903, the controller 2140 transmits a request for allocation of a second IP address to the second gateway. Accordingly, the controller 2140 is assigned the second IP address. In addition, the controller 2140 may set a direct path using the second IP address. The controller 2140 performs a handover between the first IP address and the second IP address. The handover may be performed by a mobility management scheme commonly supported between the terminal and the other end. Subsequently, when the handover between the IP addresses is completed, the controller 2140 anchors the first IP address to transmit / receive data through a direct path through the second gateway instead of a bypass path through the anchoring. Send a request for the termination of. To this end, the controller 2140 may request release of the first IP address from the first gateway. Accordingly, the controller 2140 sets the source address of the packet transmitted to the counterpart end as the second IP address.

22 is a block diagram of a network object in a wireless communication system according to an embodiment of the present invention. The block configuration shown in FIG. 22 may be applied to a gateway or a DNS server.

As shown in FIG. 22, the network object includes a communication unit 2210, a storage unit 2220, and a control unit 2230.

The communication unit 2210 provides an interface for communicating with other objects in the network. That is, the communication unit 2210 converts a bit string transmitted from the network object to another node, for example, a gateway, a base station, etc., into a physical signal, and converts a physical signal received from the other node into a bit string. That is, the communication unit 2210 may transmit and receive a signal. Accordingly, the communication unit 2210 may be referred to as a transmitter, a receiver, or a transceiver.

The storage unit 2220 stores data such as a basic program, an application program, and setting information for the operation of the network object. The storage unit 2220 provides the stored data according to a request of the controller 2230.

The controller 2230 controls overall operations of the network object. For example, the controller 2230 transmits and receives a signal through the communication unit 2210. In addition, the controller 2230 records and reads data in the storage 2220. According to an embodiment of the present disclosure, the controller 2230 may provide mobility-related capability information at the request of the terminal. For example, the controller 2230 controls the network object to perform the procedure shown in FIG. 10 or 11. Operation of the controller 2230 according to an embodiment of the present invention is as follows.

According to an embodiment of the present disclosure, the controller 2230 receives a message for requesting mobility related capability information from the terminal. Here, the requested mobility-related capability information may be mobility-related capability information of a network or a counterpart end performing communication. For example, when the network object is the gateway, mobility related capability information of the network is requested. As another example, when the network object is the DNS server, mobility related capability information of the other party's terminal communicating with the terminal is requested. Subsequently, the controller 2230 transmits a message indicating the mobility-related capability to the terminal. For example, when the network object is the gateway, the message may inform at least one mobility management scheme of operating in an IP layer or a sub-IP layer supported in the network. As another example, when the network object is the DNS server, the message may inform at least one mobility management scheme (eg, mobility management scheme operating at a higher layer) that operates in an end-to-end manner supported by the counterpart end. .

Methods according to the embodiments described in the claims or the specification of the present invention may be implemented in the form of hardware, software, or a combination of hardware and software.

When implemented in software, a computer-readable storage medium for storing one or more programs (software modules) may be provided. One or more programs stored in a computer readable storage medium are configured for execution by one or more processors in an electronic device. One or more programs include instructions that cause an electronic device to execute methods in accordance with embodiments described in the claims or specification of the present invention.

Such programs (software modules, software) may include random access memory, non-volatile memory including flash memory, read only memory (ROM), and electrically erasable programmable ROM. (EEPROM: Electrically Erasable Programmable Read Only Memory), magnetic disc storage device, compact disc ROM (CD-ROM), digital versatile discs (DVDs) or other forms It can be stored in an optical storage device, a magnetic cassette. Or, it may be stored in a memory composed of some or all of these combinations. In addition, each configuration memory may be included in plural.

In addition, the program may be configured through a communication network such as the Internet, an intranet, a local area network (LAN), a wide area network (WLAN), or a storage area network (SAN), or a combination thereof. It may be stored in an attachable storage device that is accessible. Such a storage device may be connected to a device for performing an embodiment of the present invention through an external port. In addition, a separate storage device on a communication network may be connected to a device for performing an embodiment of the present invention.

In specific embodiments of the present invention described above, the components included in the invention are expressed in the singular or plural number according to the specific embodiments presented. However, the singular or plural expressions are selected to suit the circumstances presented for convenience of description, and the present invention is not limited to the singular or plural elements, and the singular or plural elements may be used in the singular or the singular. Even expressed components may be composed of a plurality.

Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications are possible without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the scope of the following claims, but also by the equivalents of the claims.

Claims

In the method of operation of a terminal in a wireless communication system,

Transmitting a first message requesting mobility-related capability information of an access network;

And receiving a second message informing of the mobility-related capability information of the access network.
The method of claim 1,

Transmitting a third message for requesting mobility-related capability information of the other end of the communication;

And receiving a fourth message informing of the mobility related capability information of the counterpart end.
The method of claim 2,

And wherein the third message is transmitted to a server providing an Internet Protocol (IP) address corresponding to a host name of the counterpart end.
The method of claim 1,

Requesting an anchoring for the first IP address assigned by the first gateway when a serving gateway is changed from the first gateway to the second gateway due to the movement of the terminal;

Performing a handover from the first IP address to a second IP address assigned by the second gateway;

Requesting termination of anchoring for the first IP address.
The method of claim 1,

When the serving gateway is changed from the first gateway to the second gateway due to the movement of the terminal, transmitting data through a de-tour through the first gateway during the handover procedure;

And after the handover is completed, transmitting data in a direct path through the second gateway.
The method of claim 5,

The process of transmitting data in a de-tour through the first gateway,

And setting the source address of the transmitted packet to the IP address assigned by the first gateway.
The method of claim 1,

Determining, as a primary mobility management scheme, a mobility management scheme commonly supported between the other party's terminal that performs communication and the terminal;

Determining a mobility management scheme supported by the access network as an auxiliary mobility management scheme;

Disabling the auxiliary mobility management scheme.
The method of claim 7, wherein

And temporarily enabling the auxiliary mobility management scheme when a handover of the IP subnet of the terminal is changed.
A method of operating a network entity in a wireless communication system,

Receiving a first message requesting mobility-related capability information from a terminal;

And transmitting a second message informing the mobility related capability information to the terminal.
The method of claim 9,

The mobility-related capability information includes information on at least one mobility management scheme supported by the access network of the terminal or at least one mobility management scheme supported by the other party's end communicating with the terminal. How to.
A terminal device in a wireless communication system,

A transmitter for transmitting a first message for requesting mobility-related capability information of an access network;

And a receiver configured to receive a second message informing of the mobility related capability information of the access network.
The method of claim 11,

The apparatus of claim 2, further comprising a control unit for controlling the terminal apparatus to perform the method of any one of claims 2 to 8.
In a network entity device in a wireless communication system,

A receiving unit which receives a first message requesting mobility-related capability information from a terminal;

And a transmitter for transmitting a second message informing the mobility related capability information to the terminal.
The method of claim 13,

The mobility-related capability information includes information on at least one mobility management scheme supported by the access network of the terminal or at least one mobility management scheme supported by the other party's end communicating with the terminal. Device.