KR20130045168A - Method and apparatus of network-based flow mobility management - Google Patents

Abstract

PURPOSE: A flow mobility supporting method based on a network, and a device thereof are provided to effectively use network resources by selectively connecting to a communication network according to service characteristics. CONSTITUTION: An MICS(Mobility Information Control Server) determines the mobility of a flow comprising predetermined static flow binding information or another HCA(Handover Control Agent) connected to an MN(Mobile Node) based on a network state(S1110). The MICS transmits a message including information related to the HCA to a random HCA(S1130). The HCA comprises the flow. The HCA is connected to a CN(Corresponding Node). The MICS transmits a location notification message including information related to the random HCA to the HCA. [Reference numerals] (S1110) Determine flow mobility(direction) based on flow binding information

Description

Method and apparatus for supporting network-based flow mobility {Method and apparatus of network-based flow mobility management}

The present invention relates to networking, and more particularly, to a method and apparatus for supporting location registration and mobility for each service flow for a multi-mode mobile node (MN) having a plurality of wired and wireless network interfaces in a wired / wireless converged network environment. It is about.

In addition to wired communication technologies such as Ethernet and fiber-to-the-home (FTTH), Wireless Local Area Network (WLAN), Wibro, 3G (e.g. CDMA), 3.5G ( For example, various radio access technologies, such as HSPA, have emerged and are being provided to users. Ubiquitous mobile networking service, which combines various wired and wireless technologies to form heterogeneous network interworking to provide users with various converged multimedia services with optimal quality anytime, anywhere. There is an active research on.

For multimedia services over multiple communication networks, the importance of communication technology for multimode MNs with multiple wired and wireless interfaces is emerging. Accordingly, in single-mode MNs equipped with conventional node interfaces. There is a need for supplements and modifications to the networking technologies considered. Existing MN mobility technology was developed mainly for the handover control function that handles the switching between network interfaces and thus the network connection path change, so that each service flow is maintained in a situation of maintaining multiple communication connections. There was no consideration of how to manage. In particular, since the quality of service (QoS) characteristics provided by each network are different, it is important to select an interface based on the nature of service data, and if any interface becomes incapable of communication due to MN movement or network quality, Data flows that used the interface must be redistributed to other interfaces. Therefore, it is necessary to consider mobility-based mobility support technology, that is, flow-based mobility support technology, to support services in an optimal network environment by reflecting the characteristics of specific services (flows) and subscriber preferences. There is a situation.

Currently, flow-based mobility support technology is mainly performed based on network-based IP mobility support technology (eg, IETF Proxy MIPv6) rather than node-based internet protocol (IP) mobility support technology (eg, IETE Mobile IPv6). PIMPv6 implements the Mobile Access Gateway (MAG) feature on the MN's Access Router, and places the Local Mobility Anchor (LMA) feature on the core network, allowing the MN to move to the area managed by the new MAG. The MAG describes a procedure of registering the MN's mobility binding information with the LMA. That is, according to PMIPv6, an MN not implementing a function for managing IP mobility (for example, Mobile IPv6) can manage IP mobility through signaling between the MAG and the LMA existing in the network. Here, the LMA operates as a kind of HA (Home Agent) for the MN in the access network, and the MAG supports the mobility of the MN on behalf of the MN.

In addition, research on supporting flow-based mobility by expanding and improving PMIPv6 (PMIPv6) centering on 'IETF NETEXT WG (Internet Engeeneering Task Force Network-based Mobility Extention Working Group)' Measures are being discussed.

(1) "Service Flow Identifier in Proxy Mobile IPv6 (draft-hui-netext-service-flow-identifier-00)" paper describes the service flow identifier option for informing specific service flow information to LMA in PMIPv6. ), And a method of including it in a control message transmitted and received by the MN during handover processing is proposed. The method proposed in this paper defines when the MN sends this service flow identifier option to the LMA when the MAG receives a packet belonging to a new service flow from an arbitrary interface of the MN. However, this method only requests the data flow of the new service flow, i.e., the required service flow binding, when an uplink packet is sent to the MAG from the MN, and the traffic is requested from the Corresponding Node (CN). The problem is that such a service flow binding cannot be requested when it is sent. Therefore, if downlink traffic arrives at the LMA after uplink traffic is absent for a while after the handover, the traffic arrives at an interface that the MN does not currently intend.

(2) "Flow Binding in Proxy Mobile IPv6 (draft-xia-netext-flow-binding-00)" paper does not newly define the format of the service flow identifier option, and the flow label used for flow management in Mobile IPv6 ( It suggests how to reuse flow labels. However, the binding policy for each service to induce service flow handover depends on the profile or operator policy of the MN. That is, the binding method for a specific flow is stored in a database managing various information of the MN, and the service flow binding is started based on the stored information. Regardless of the desired preference at that moment, there is a problem that the management for each flow is performed based on only static information stored in advance. For example, even if the pre-stored profile specifies that the VoIP service traffic should be exchanged through the WLAN interface, the user may wish to use the VoIP service using the 3GPP interface in some cases. It is not supported by the proposed method.

(3) "Flow Handover for Proxy Mobile IPv6 (draft-koodli-netext-flow-handover-00)" paper defines separate signaling messages for flow handover, and puts IP address and port number in each flow label. Suggesting how to give. However, this method also has a problem in that it cannot reflect dynamic user preferences because it causes handover of the service flow depending on the static profile of the MN or the operator's policy as in the method (2).

The technical problem of the present invention is to solve the above-mentioned problems, and is based on a multi-mode MN having a plurality of wired and wireless network interfaces based on an AIMS technology. A location registration procedure, a flow registration procedure for each flow, a flow-based data transmission procedure, and a flow-specific handover procedure are provided.

 Another technical problem of the present invention is to provide a binding information management structure and method, a control message transmission flow, and a system operation method for applying a flow-based mobility control technology to an actual network environment.

According to an aspect of the present invention, there is provided a method for supporting flow mobility based on an access independent mobility service (AIMS) by a mobility information control server (MIC). The method includes receiving a location registration message from any HCA (Handover Control Agent) connected to a mobile node (MN), and the other MN is connected based on preset static flow binding information or network status. Determining a movement of a flow configured in the HCA, wherein the flow is configured, and the location registration Ack including information on the HCA connected to the CN (Corresponding Node). Sending a message to the HCA, and sending a location notification message to the HCA in which the flow is configured and associated with the CN, the location notification message comprising information about the HCA to which the flow is to be moved. Characterized by including.

According to another aspect of the present invention, an AIMS-based flow mobility support method by HCA is provided. The method includes receiving, from a MN, a Flow Mobility Indicate message including flow selector information indicative of moving a flow to a different interface from a physical interface based on static flow information for the packet, wherein the flow selector information Transmitting a location registration message including a location information to MICS, the location registration Ack including movement information of the flow. Receiving a message from the MICS, and flow mobility Ack. And sending a message to the MN.

According to another aspect of the present invention, there is provided an AIMS-based flow mobility support method by MN. The method includes determining a movement of a flow to a different interface from the physical interface based on the static flow information for the packet, and a flow indicating to move the flow to a different interface from the physical interface based on the static flow information with respect to the packet. Sending a flow mobility indication message including selector information to the HCA, flow mobility indication Ack. Receiving a message from the HCA.

According to the present invention, since the multi-mode MN can efficiently support location registration and mobility for each service flow, select and connect an optimal communication network suitable for each service characteristic of the MN in an environment in which various wired and wireless networks overlap. Network resources can be used efficiently.

1 shows a network configuration supporting multiple access in an AIMS system according to the present invention.
2 illustrates a virtual interface layer of an MN according to the present invention.
3 shows an example of HoA allocation to a virtual interface according to the present invention.
4 illustrates a process in which an MN having two interfaces according to an embodiment of the present invention registers with the HCA and the MICS through each interface.
5 illustrates a process in which an MN reconnects to another HCA through a specific interface among multiple connections according to an embodiment of the present invention.
6 shows an example of a protocol stack structure of an MN according to the present invention.
7 shows an example of flow distribution of MN1 according to the present invention.
8 shows an example of flow distribution of MN2 according to the present invention.
9 is an example of a GBT managed by MICS and a flow binding table linked to the GBT according to the present invention.
10 shows a schematic example of a flow mobility processing method according to the present invention.
11 is a flowchart illustrating an initial data flow delivery process according to an embodiment of the present invention.
12 illustrates a flow movement procedure by a new connection of a mobile terminal according to the present invention.
13 is a flowchart illustrating a flow mobility control procedure by a new connection of MN according to an embodiment of the present invention.
14 schematically illustrates a flow movement situation due to a new connection of an MN.
15 is a flowchart illustrating a procedure of moving a flow under the determination of MICS according to an embodiment of the present invention.
16 is a flowchart illustrating a procedure of moving a flow under determination of MN and determination of suitability of MICS according to an embodiment of the present invention.
17 is an operation flowchart of MICS supporting network-based flow mobility according to an embodiment of the present invention.
18 is an operation flowchart of an HCA supporting network-based flow mobility according to an embodiment of the present invention.
19 is an operation flowchart of an MN supporting network-based flow mobility according to an embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are used to refer to the same components as much as possible even if displayed on different drawings. In the following description of the embodiments of the present invention, a detailed description of known configurations or functions will be omitted if it is determined that the gist of the present specification may be obscured.

In addition, in describing the components of the present specification, terms such as first, second, (1), (2), (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. If a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected or connected to that other component, but there is another component between each component. It will be understood that may be "connected", "coupled" or "connected".

The network-based mobility support scheme according to the present invention may provide flow-based location registration and mobility for a multimode MN having a plurality of wired and wireless interfaces. To this end, in the present invention, 1. AIMS system and registration procedure for Care-of-Address (CoA) registration, 2. Stack architecture and flow management scheme of Mobile Node (MN), 3 We propose a flow management scheme of a mobility information server (MICS) and a handover control agent (HCA), a process of delivering an initial data flow, and a process of a flow movement.

1. AIMS system and registration procedure for CoA registration

1 shows a network configuration supporting multiple access in an AIMS system according to the present invention.

Referring to FIG. 1, the AIMS system is a handover control located in a mobility control server (MICS) 10 located in a core network 14 and each access network 15a, 15b, 15c, and 15d. Point of Attachment (PoA: 12a, 12b, 12c, 12d) to provide wireless link connectivity to agents (HCA: Handover Control Agents (11a, 11b, 11c, 11d) and Mobile Nodes (13a, 13b). And MNs 13a and 13b moving between access networks. In addition, the AIMS system may further include a converged user profile server (CUPS) 16 that manages a subscriber profile for the access network.

The MNs 13a and 13b may simultaneously connect to at least one or more access networks through one or more interfaces. The MICS 10 may register information (for example, CoA) for the HCAs 11a, 11b, 11c, and 11d in the access networks 15a, 15b, 15c, and 15d to which the MNs 13a and 13b are connected. . Here, CoA represents a secondary address for encapsulating by providing information about the current connection point of the MN in the mobile IP network. In addition, when the MN 13a communicates with the MN 13b, the information about the HCAs 11a and 11b in the access networks 15a and 15b to which the MN 13a is connected is displayed in the access network to which the MN 13b is connected. It should be known to HCAs (11c, 11d) at (15c, 15d), and vice versa. That is, the HCAs 11a and 11b must hold the information on the HCAs 11c and 11d as the positional information on the MN 13b, and the HCAs 11c and 11d are the HCAs as the positional information on the MN 13a. Must have information about (11a, 11b), signaling for this is supported.

(1) Using Virtual Interfaces (VIs) and Assigning HoAs

2 illustrates a virtual interface layer of an MN according to the present invention. The virtual interface layer is configured at the top of the data link layer configured in the MN's protocol stack and at the bottom of the network layer.

Referring to FIG. 2, the virtual interface layer 20 includes a virtual interface 200 and a flow binding manager 250.

All static IP addresses (eg, HoA (Home Address)) assigned from the HCA constituting the AIMS system are assigned to the virtual interface 200.

The flow binding manager 250 determines to which physical interface (PI) to actually forward the packet down to the virtual interface from the upper layer. In the following description, an interface (IF) may mean a physical interface. The detailed operation of the flow binding manager 250 will be described later.

3 shows an example of HoA allocation to a virtual interface according to the present invention.

Referring to FIG. 3, the MN 30 first registers with the MICS 35 through one of a plurality of physical interfaces (PIs), for example, PI1 32a, and the HCA1 33a. HoA (38) is obtained and managed in VI (Virtual Interface, 31). If the MN 30 then registers with the MICS 35 via another physical interface, for example PI2 32b, the MN 30 has already been assigned the HoA 38 that the MICS 35 has assigned to the MN 30. Since it is known that the HoA 38 can be informed to the HCA2 33b. That is, it can be seen that the MN 30 is assigned the same HoA 38 to the VI 31 from a plurality of physical interfaces.

(2) Identifier of MN

The ID of an MN in an AIMS system is defined as a list of data link layer (L2) layers that the MN has. Accordingly, the L2 address is used as a terminal identifier when managing binding information of the terminal in MICS and HCA. However, in an environment supporting multiple interfaces, these L2 addresses may be used for various purposes, and more differentiated MN-IDs may be used for terminal identification. For example, as an ID of the MN, a network access identifier (NAI), which is widely used in existing Internet protocols, may be used. The network access identifier is a standard method for identifying a user requesting access to a network in communication. The standard syntax is in the form of "user @ realm". Standards include RFC 2486 and RFC 4282.

(3) Binding Information Management Techniques in MICS

MICS manages a global binding table (GBT) and a session information table (GBS).

Table 1 shows an example of an extended global binding table (GBT) structure managed in MICS. Referring to Table 1, MN-ID represents the ID of the MN and NAI is used. HoAv4 and HoAv6 indicate whether HoA is assigned to IPv4 and IPv6. HoA may exist with different values for the IPv4 and IPv6 versions. HoA may be assigned to at least one of IPv4 and IPv6 for each MN-ID. The binding list includes a B-ID, a type, an L2 address, an CoA (HCA address), a default, and a lifetime. The B-ID is the binding ID assigned by the MN after completing the registration process for each interface it owns. The type represents an access type for each B-ID of the MN. The L2 address is the address of the data link layer of the MN. CoA (HCA address) may represent the HCA address as a secondary address for the current connection point of the MN in the mobile IP network. And, the default indicates whether or not it is set to send an arbitrary flow with specific binding information predefined to the MN. In other words, if it is not set to send an arbitrary flow with specific binding information predefined toward the MN, the default value of the binding information sending such a flow indicates O. For example, if there is no predefined specific binding information for any flow for the MN whose MN-ID is mn1@kt.com, the default value is O, in which case the MN receives the flow through the 3G interface. Lifetime represents the time when each piece of information in the binding list is valid.

Table 2 shows an example of a session information table. Referring to Table 2, ID information about two MNs participating in a session is represented by X-ID and Y-ID, and HoA information about each MN is represented by X-HoAv4 and Y-HoAv4. In session information, information on two bidirectional flows participating in a session is shown in the form of a 5-tuple pair. X-HCA (CoA) and Y-HCA (CoA) represent two pieces of HCA information serving as a tunneling role for each flow session. Lifetime represents the time when the session information is valid. The information configured in Table 2 is a record of all sessions being serviced through the AIMS system. Table 2 shows a case in which two MNs are opening an IPv4 session. For example, when two MNs are opening an IPv6 session, the session information table may configure a HoA for the IPv6 session. In this case, in Table 2, item X-HoAv4 may be replaced with X-HoAv6, item Y-HoAv4 may be replaced with Y-HoAv6, and the values of the item may also be changed.

(4) Binding Management Techniques in HCA

Table 3 shows an example of an MBT (MN Binding TABLE) according to the present invention. Referring to Table 3, MN-ID represents the ID of the MN and NAI is used. MN HoA represents HoA of MN. The type of "L2 ID" indicates the connection type of the MN, and the address of the "L2 ID" indicates the address of the data link layer of the MN. "HCA's NIC ID" represents the ID of a network interface card which is a communication module of the HCA. Lifetime represents the time when the information is valid. Compared with the MBT used in the existing AIMS system, the MBT according to the present invention is characterized by using NAI as the MN-ID.

Table 4 shows an example of a packet forwarding table (PFT) managed by the HCA according to the present invention. Referring to Table 4, the (corresponding) MN-ID indicates the ID of the MN that receives the signal. In other words, the (corresponding) MN-ID may mean, for example, the ID of the MN2 communicating with the MN1 based on MN1 (the MN transmitting the signal) and uses the NAI. In this case, MN2 may be called CN (Corresponding Node). MN HoA (Destination) represents the HoA of the MN that receives the signal. For example, MN HoA (Destination) may mean HoA of MN2 in the above example. The HCA makes a decision for packet forwarding based on a flow selector. In other words, when there is a flow to be forwarded by the HCA, the flow is compared with the flow selector list registered in the PFT, and packet forwarding is performed to a specific HCA associated with a matching flow selector.

(5) Registration process through multiple interfaces

4 illustrates a process in which an MN having two interfaces according to an embodiment of the present invention registers with the HCA and the MICS through each interface.

Referring to FIG. 4, the MN establishes an L2 association (L2 association) with an access network to connect through IF1 (Interface 1) (specifically, PoA # 1, which is a point of attachment to the access network to be accessed). set up) (S400). The process of establishing an L2 connection through the IF1 by the MN includes a user authentication procedure of authenticating a user subscribed to each provider network to confirm access authority. The user authentication procedure is performed through the exchange of authentication information between the MN and the converged user profile server (CUPS) that manages the subscriber profile for the access network. CUPS is an extension of the AAA server, and the identifier of the MN used in CUPS is NAI. The NAI of the MN is registered in advance in CUPS for user identity. After the user authentication procedure, PoA # 1 can know the NAI of the MN.

When the L2 connection process including the user authentication procedure is completed through the IF1 of the MN, an L2 link up trigger (L2 link up trigger) indicating a new link establishment occurs in the L2 layer of PoA # 1 (S405). The L2 link up trigger is converted into a MIH link up trigger by a Media Independent Handover (MIH) layer of PoA # 1.

PoA # 1 transmits a location report message for initiating a network-based registration procedure based on the MIH link-up trigger to HCA # 1, which is the HCA of the corresponding access network (S410). The location report message includes the ID of the MN and L2 ID # 1, which is an L2 ID for IF1. After transmitting the location report message to HCA # 1 or concurrently with transmission (in some cases before transmission), PoA # 1 transmits at least one of an IPv4 Router Advertisement (RA) message and an IPv6 RA message to the MN. . The IPv4 RA message and the IPv6 RA message are messages that PoA # 1 receives from HCA # 1 and stores them in a Router Advertisement Cache. The MN sets at least one of an IPv4 default gateway address (IPv4, MAC) and an IPv6 default gateway address (IPv6, MAC) according to the protocol stack currently activated by the MN based on the received RA message. The configured default gateway address is used as a default gateway address for packets going out through the IF1 in the MN.

The HCA # 1, which has received the location report message, responds to a location report Ack. Message to PoA # 1 (S415). Thereafter, HCA # 1 extracts L2 ID # 1, which is L2 ID information about IF1 of the MN, and searches whether there is an entry in the MBN (MN Binding Table) managed by the HN # 1. In the case of initial registration, since there is no binding entry for the MN, a new entry is created and L2 ID # 1, which is L2 ID information for the MN's ID and IF1, and the type and lifetime of the access network. Record lifetime and network interface card (NIC) ID of HCA # 1.

When the new entry generation is completed, HCA # 1 transmits a location registration message to perform the initial registration procedure of the MN for MICS (S420). The location registration message includes ID of MN, L2 ID # 1, which is L2 ID of IF1, and CoA # 1 information, which is an IP address of HCA # 1 itself. If the core network where HCA # 1 and MICS is located is IPv4, CoA # 1, the address of HCA # 1, is an IPv4 address. If the core network is IPv6, CoA # 1 is an IPv6 address.

The MICS receiving the location registration message extracts the ID of the MN, the L2 ID # 1 which is the L2 ID of the IF1, and the CoA # 1 information, and corresponds to the ID of the MN in the Global Binding Table (GBT) managed by the MICS. Checks for the existence of a binding entry. If the corresponding binding entry does not exist, the MICS determines that the initial registration is performed and transmits an information query message to the CUPS (S425).

CUPS transmits an information query Ack. (Information Query Ack.) Message to the MICS in response to the information query message transmitted by the MICS (S430). At this time, CUPS provides information on the ID of the MN and whether the MN requires IPv4 home address mobility service, IPv6 home address mobility service, or both services, namely IPv4 / IPv6 home address mobility. It also transmits service information (IPv4 / IPv6 home address mobility service info.). CUPS also sends static flow binding information preset for the MN. The static flow binding information may mean a static distribution rule preset for a specific flow, and the static flow binding information may be preset according to a terminal / user's own standard or a rule determined by an ISP (Internet Service Provider).

MICS then creates a new binding entry in the GBT for the MN to register, the information provided from CUPS in S430 (for example, a list of all information in the MN, IPv4 / IPv6 home address mobility information, etc.) and HCA # 1 in S420. The L2 ID # 1 and CoA # 1 information provided from the CD is recorded in the binding entry.

MICS transmits a Location Registration Ack. Message to HCA # 1 (S435). In this case, HoA information is also transmitted. At the initial registration, since MICS does not have HoA information, the HoA value is set to 'NULL' and transmitted. In addition, it also transmits IPv4 / IPv6 home address mobility service information provided from CUPS.

Location registration with HoA information set to 'NULL' Ack. Upon receipt of the message, HCA # 1 recognizes that the MN is performing the initial registration procedure. Therefore, in this case, HCA # 1 requests the DHCP server managing the access network, receives an IPv4 and / or IPv6 address to be used as the HoA of the MN, and then records the address in a binding entry for the MN in the MBT. For example, when HCA # 1 needs IPv4 home address mobility service, after receiving an IPv4 address from DHCPv4, the HCA # 1 records the IPv4 address as IPv4 HoA information in a binding entry for an MN in MBT. As another example, when HCA # 1 needs IPv6 home address mobility service, after IPv6 address is allocated from DHCPv6, the HCA # 1 records the IPv6 address as IPv6 HoA information in a binding entry for an MN in MBT.

HCA # 1 transmits a HoA update message to the MN in order to notify the HoA information allocated from the DHCP server (S440). The HoA update message includes at least one of IPv4 HoA information and IPv6 HoA information.

In addition, the HCA # 1 transmits a HoA update message to MICS in order to notify the HoA information allocated from the DHCP server (S445). The HoA update message includes at least one of IPv4 HoA information and IPv6 HoA information.

Although S440 is shown as being performed before S445 in the drawing, this is only an example, and S445 may be performed before S440 or simultaneously.

The MN sets at least one of an IPv4 HoA address and an IPv6 HoA address based on the HoA update message received from HCA # 1 through S440, and sets HoA update Ack. The message is transmitted to HCA # 1 (S450).

The MICS records at least one of IPv4 HoA information and IPv6 HoA information in the binding entry of the MN in the GBT based on the HoA update message received from the HCA # 1 through S445, and checks the HoA update Ack. The message is transmitted to HAC # 1 (S455).

Although S450 is shown as being performed before S455 in the drawing, this is only an example, and S455 may be performed before S450 or simultaneously.

The MN establishes an L2 association (L2 Association) with an access network to access through IF2 (Interface 2) (specifically, PoA # 2, which is a point of attachment to the access network to be accessed) (S460). ). The process of establishing an L2 connection through the IF2 of the MN includes a user authentication procedure of authenticating a user subscribed to each provider network to confirm access authority. In this case, the user authentication procedure is performed through the exchange of authentication information between the MN and the CUPS managing the subscriber profile for the access network. The identifier of the MN used in CUPS is NAI. After the user authentication procedure, PoA # 2 can know the NAI of the MN.

When the L2 connection process including the user authentication procedure is completed through the IF2 of the MN, an L2 link up trigger (L2 link up trigger) indicating a new link establishment in the L2 layer of PoA # 2 occurs (S465). The L2 link up trigger is converted into a MIH link up trigger by a Media Independent Handover (MIH) layer of PoA # 2.

PoA # 2 transmits a location report message for initiating a network-based registration procedure based on the MIH link-up trigger to HCA # 2 which is the HCA of the corresponding access network (S470). The location report message includes the ID of the MN and L2 ID # 2 which is the L2 ID for IF2. After transmitting the location report message to HCA # 2 or concurrently with transmission (in some cases, before transmission), PoA # 2 transmits at least one of an IPv4 Router Advertisement (RA) message and an IPv6 RA message to the MN. . The IPv4 RA message and the IPv6 RA message are messages that PoA # 2 receives from HCA # 2 and stores them in a Router Advertisement Cache. The MN sets at least one of an IPv4 default gateway address (IPv4, MAC) and an IPv6 default gateway address (IPv6, MAC) according to the protocol stack currently activated by the MN based on the received RA message. The set default gateway address is used as a default gateway address for packets going out of the MN through IF2.

The HCA # 2, which has received the location report message, responds to a location report Ack. Message to PoA # 2 (S475). Thereafter, HCA # 2 extracts the L2 ID of the MN and searches whether there is a corresponding entry in the MN Binding Table (MBT) that it manages. Since there is a binding entry for the MN here, HCA # 2 is the L2 ID # 2, which is the MN ID and L2 ID information for IF2, and the type, lifetime and HCA of the access network. Record the Network Interface Card (NIC) ID of # 2.

HCA # 2 transmits a location registration message to perform the registration procedure of the MN for MICS (S480). The location registration message includes ID of MN, L2 ID # 2 which is L2 ID of IF2, and CoA # 2 information which is its own IP address. If the core network where HCA # 2 and MICS are located is IPv4, CoA # 2, the address of HCA # 2, is an IPv4 address. If the core network is IPv6, CoA # 2 is an IPv6 address.

The MICS receiving the location registration message extracts the ID of the MN, the L2 ID # 2 which is the L2 ID of the IF2, and the CoA # 2 information, and corresponds to the ID of the MN in the Global Binding Table (GBT) managed by the MICS. Checks for the existence of a binding entry. If the corresponding binding entry exists, the L2 ID # 2 and CoA # 2 information provided from the HCA # 2 is recorded in the binding entry in S480. In this case, MICS may not transmit the information query message to CUPS.

MICS transmits a Location Registration Ack. Message to HCA # 2 (S485). In this case, MICS also sends the HoA information it has to HCA # 2. Therefore, in this case, HCA # 2 may not request an IPv4 and / or IPv6 address to be used as a HoA of the MN by the DHCP server, and may not perform HoA update of the MN and MICS.

(6) Reconnection process to different HCA of specific interface in multi-connected state

When the MN reconnects from an already connected HCA to another HCA through an arbitrary interface, the MN performs a location information update procedure, which is generally similar to the initial registration procedure of the MN. However, since the reconnection is a control procedure for the situation where the MN which has already completed the initial registration procedure enters a new access network, the HoA allocation and notification procedure using DHCP is not performed. In addition, since MICS receives and manages all information list and IPv4 / IPv6 home address mobility service information of MN from CUPS, it does not perform the information query procedure. In addition, a localized or proactive authentication technique may be applied for user authentication. In addition, during the initial registration process, MICS registers its location with the HCA. When the message is delivered, the IPv4 / IPv6 home address mobility service information is transmitted. However, in the reconnection (or handover) process, only at least one of IPv4 and IPv6 may be transmitted as HoA information. In addition, during the reconnection (handover) process, the connected interface other than the interface to which the MN is currently reconnecting (or handover) is still maintained. It will be described in detail with the drawings as follows.

5 illustrates a process in which an MN reconnects to another HCA through a specific interface among multiple connections according to an embodiment of the present invention. 5 shows an example in which the MN reconnects to HCA # 3 through IF1. Interfaces other than IF1 (ie IF2) that the MN attempts to reconnect can still maintain connectivity.

Referring to FIG. 5, the MN establishes an L2 association (L2 association) with an access network to connect through IF1 (Interface 1) (specifically, PoA # 3, which is a point of attachment to the access network to be accessed). set up) (S500). The process of establishing an L2 connection through the IF1 by the MN includes a user authentication procedure of authenticating a user subscribed to each provider network to confirm access authority. In this case, the user authentication procedure is performed through the exchange of authentication information between the MN and the CUPS managing the subscriber profile for the access network. Here, when authenticating the user, an authentication technique of a local or preceding method may be applied. The identifier of the MN used in CUPS is NAI. After the user authentication procedure, PoA # 3 can know the NAI of the MN.

When the L2 connection process including the user authentication procedure is completed through the IF2 of the MN, an L2 link up trigger (L2 link up trigger) indicating a new link establishment in the L2 layer of PoA # 3 occurs (S505). The L2 link up trigger is converted into a MIH link up trigger by a Media Independent Handover (MIH) layer of PoA # 3.

PoA # 3 transmits a location report message for initiating a network-based registration procedure based on the MIH link up trigger to HCA # 3, which is the HCA of the corresponding access network (S510). The location report message includes the ID of the MN and L2 ID # 1, which is an L2 ID for IF1. After transmitting the location report message to HCA # 3 or concurrently with transmission (in some cases before transmission), PoA # 3 transmits at least one of an IPv4 Router Advertisement (RA) message and an IPv6 RA message to the MN. . The IPv4 RA message and the IPv6 RA message are messages that PoA # 3 receives from HCA # 3 and stores them in a Router Advertisement Cache. The MN sets at least one of an IPv4 default gateway address (IPv4, MAC) and an IPv6 default gateway address (IPv6, MAC) according to the protocol stack currently activated by the MN based on the received RA message. The configured default gateway address is used as a default gateway address for packets going out through the IF1 in the MN.

The HCA # 3 that has received the location report message responds to the PoA # 3 with a location report Ack. Message (S515). Thereafter, HCA # 3 extracts the L2 ID of the MN, and searches whether there is a corresponding entry in the MN Binding Table (MBT) that it manages. Since there is a binding entry for the MN here, HCA # 2 is the L2 ID # 1, which is the MN ID and L2 ID information for IF1, and the type, lifetime and HCA of the access network. Record the Network Interface Card (NIC) ID of # 3.

HCA # 3 transmits a location registration message to perform the registration procedure of the MN for MICS (S520). The location registration message includes ID of MN, L2 ID # 1 which is L2 ID of IF2, and CoA # 3 information which is IP address of HCA # 3 itself. If the core network where HCA # 3 and MICS is located is IPv4, CoA # 3, the address of HCA # 3, is an IPv4 address. If the core network is IPv6, CoA # 3 is an IPv6 address.

The MICS receiving the location registration message extracts the ID of the MN, the L2 ID # 1 which is the L2 ID of IF2, and the CoA # 3 information, and corresponds to the ID of the MN in the GBT (Global Binding Table) managed by the MICS. Retrieve the binding entry. When the binding entry is found, MICS records the L2 ID # 1 and CoA # 3 information provided from the HCA # 3 in the binding entry in S520. In this case, MICS may not transmit the information query message to CUPS.

MICS transmits a Location Registration Ack. Message to HCA # 3 (S525). In this case, MICS also sends the HoA information it has to HCA # 3. Therefore, in this case, HCA # 3 may not request an IPv4 and / or IPv6 address to be used as a HoA of the MN by the DHCP server, and may not perform HoA update of the MN and MICS.

2. Protocol stack structure and flow management method of MN

6 shows an example of a protocol stack structure of an MN according to the present invention.

Referring to FIG. 6, the protocol stack 60 of the MN includes an application layer 600, a transport layer 610, a network layer 620, a virtual interface layer 630. ), A Data Link Layer (640), and Physical Interface Layers (650). The physical interface layers 650 may be divided such as PI1, PI2, PI3, and the like.

In the present invention, the newly added virtual interface layer 630 is implemented between the network layer 620 and the data link layer 640, and a virtual interface 631 and a flow binding manager 632 are provided. Include.

The virtual interface 631 is a virtual network interface through which packets descending from the upper layer and packets coming from the lower layer pass. Therefore, the upper layer eventually looks as one interface of the MN, and in this case, the MN can solve various problems that occur during handover between heterogeneous access networks, for example, the same address is assigned to several interfaces. .

The flow binding manager 632 plays a role of determining which physical interface to actually forward the packet descended from the upper layer to the virtual interface 631. In order to efficiently perform such a determination, the flow binding manager 632 manages a flow binding list as follows.

Table 5 shows an example of a flow binding list of MN1. Here, MN1 is a notation for distinguishing from MN2 which will be described later. Substantially, both MN1 and MN2 are a kind of MN. The same is applied hereinafter. Referring to Table 5, the flow binding list includes entry information on which physical interface to send filtered packets based on each flow selector, and each entry has a flow ID and priority. (Priority), Flow Selector, Outbound Interfaces, Type, and Lifetime. When there is a packet that MN1 needs to send to the outside, it first refers to the flow binding list, first referring to the highest priority information on the flow binding list, and refers to outbound interfaces to determine which physical interface to send the packet to. In Table 5, there are currently four flow binding information. The lowest two entries are basically information that the terminal has when the terminal is driven. Physical interface information and IPv6 for unfiltered packets for high-priority flow selectors are shown. Contains processing information for packets sent to an IPv6 Link Local Broadcast address. On the other hand, the top two are entries determined from the terminal's own criteria. The following flow distribution may occur based on the upper two flow binding information.

7 shows an example of flow distribution of MN1 according to the present invention.

Referring to FIG. 7, the MN1 70 includes a virtual interface 700, a physical interface # 1, 710-1, and a physical interface # 2, 710-2. Two flows 720-1 and 720-2 from VI 700 of MN1 70 are distributed through PI1 710-1 and PI2 710-2 and HCA # 1 730-1 and Transmitted to HCA # 2 730-2. In the present example, based on Table 5, the flow 720-1 indicates a flow ID of 4 and the flow 720-2 indicates a flow ID of 3. As shown in the outbound interfaces of Table 5 above, the communication between the MN1 70 and the HCA # 1 730-1 through which the flow 720-1 is transmitted is based on the WLAN, and the flow 720-2 is transmitted. The communication between the MN1 70 and the HCA # 2 730-2 is performed based on 3G.

Meanwhile, when the counterpart MN communicating with MN1 70 is MN2, the flow binding list of MN2 may be as shown in Table 6 below, and the flow distribution of MN2 may be as shown in FIG. 8. MN2 may be referred to as CN (Corresponding Node) based on MN1.

Table 6 is an example of a flow binding list of MN2.

Referring to Table 6, the flow binding list includes entry information on which physical interface to send filtered packets based on each flow selector, and each entry has a flow ID and priority. (Priority), Flow Selector, Outbound Interfaces, Type, and Lifetime. Except for changing MN1 to MN2, the detailed description is shown in Table 5.

8 shows an example of flow distribution of MN2 according to the present invention.

Referring to FIG. 8, the MN2 80 includes a virtual interface 800, a physical interface # 1, 810-1, and a physical interface # 2, 810-2. Two flows 820-1 and 820-2 from VI 800 of MN2 80 are distributed through PI1 810-1 and PI2 810-2 and HCA # 3 830-1 and Transmitted to HCA # 4 830-2. In the present example, based on Table 6, the flow 820-1 represents a case in which the flow ID is 4, and the flow 820-2 represents a case in which the flow ID is 3. As shown in the outbound interfaces of Table 6 above, the communication between the MN2 80 and the HCA # 3 830-1 through which the flow 820-1 is transmitted is based on the WLAN, and the flow 820-2 transmits. The communication between the MN2 80 and the HCA # 4 830-2 is performed based on 3G.

3. Flow management method of MICS and HCA

MICS manages its own flow binding table similarly to MN. However, the MN manages the flow information for the outbound flow, while the MICS manages the flow information for the inbound flow of each MN.

9 is an example of a GBT managed by MICS and a flow binding table linked to the GBT according to the present invention. 9 illustrates a flow binding table corresponding to the flow binding lists for MN1 and MN2 described in Tables 5 and 6 as an example.

Referring to FIG. 9, the GBT 900 managed by MICS includes information on all MNs currently registered in MICS. In addition, MICS has a flow binding table (950) for each of the MNs. The flow binding table 950 is associated with the GBT 900. The flow binding table 950 is similar to the flow binding list managed by the MN, but the flow binding table 950 managed by MICS includes an Access Tech item, not an Outbound Interfaces item. do. That is, the flow binding table 950 managed by MICS retains information about which access technology (ie, access network type) to use after being filtered by the flow selector for inbound flows directed to each MN. . MICS may also determine which HCA to send for packets destined for the MN according to the access technology (ie, access network type).

The flow binding table 950 for any MN and the flow binding table 950 for the MN in MICS should be symmetrically congruent. As such, necessary information may be updated by transmitting and receiving signals between the MN and the MICS in order to achieve a symmetrical matching of information, which may be variously implemented according to the policy of the network operators and the users' preferences.

In addition, MICS manages the following information on a per session basis for flows currently exchanged in the entire system.

Table 7 shows an example of a session information table managed in MICS.

Referring to Table 7, X-ID represents an ID of MN1. NAI is used for the ID of MN1. X-HoAv4 represents HoA of MN1. In this example, IPv4 is used. Y-ID represents the ID of MN2. MN2 is a counterpart MN that communicates with MN1, and NAI is used for ID of MN2. Y-ID represents HoA of MN2. In this example, IPv4 is used. In session information, information on a bidirectional flow participating in a session is represented in the form of a 5-tuple pair. X-HCA (CoA) and Y-HCA (CoA) represent two HCAs that serve as tunneling roles for the flow session. Lifetime represents the time when the session information is valid. Referring to Table 7, it can be seen that one session is established and communicated between MN1 and MN2, and flows in the session are transmitted and received through HCA # 1 and HCA # 4.

Meanwhile, the HCA manages a packet forwarding table (PFT). When any MN starts to send a packet, the HCAs between the MICS and both ends exchange a Location Query / Response and Location Notification / Notification Ack message. Based on the HCA may manage (or create or update) the PFT.

Tables 8 and 9 below show information included in the PFT of HCA # 1 for each MN1 and the PFT of HCA # 4 for MN2 when exchanging sessions between MN1 and MN2.

Table 8 shows the PFT of HCA # 1 to which MN1 is connected when exchanging sessions between MN1 and MN2.

Table 9 shows the PFT of HCA # 4 to which MN2 is connected when exchanging sessions between MN1 and MN2.

Referring to Tables 8 and 9, the MN-ID indicates the ID of the MN that receives the signal. In other words, the MN-ID means, for example, the ID of the MN2 communicating with the MN1 based on the MN1 (the MN transmitting the signal) and uses the NAI. Based on MN2, this means the ID of MN1 communicating with MN2 and uses NAI. Destination represents the HoA of another MN that communicates with the MN. The HCA makes a decision for packet forwarding based on a flow selector. HCA (CoA) represents CoA of an HCA to which another MN communicating with the MN is connected.

Referring to Table 8 and Table 9, one session is established between MN1 and MN2, and communication is performed between MN1 and MN2, and a flow transmitted from MN1 to MN2 in the session is packet forwarded from HCA # 1 to HCA # 4. This is performed, and the flow transmitted from MN2 to MN1 can be seen that packet forwarding is performed from HCA # 4 to HCA # 1.

An overview of the overall data flow processing method is as follows.

10 shows a schematic example of a flow mobility processing method according to the present invention.

Referring to FIG. 10, when MN1 wants to transmit an arbitrary data flow to MN2, MN1 selects one of HCA # 1 and HCA # 2 connected thereto. When MN1 selects HCA # 1, when HCA # 1 receives a packet from MN1, HCA # 1 obtains information on which access technology MN2 wants to receive data flow through a location response message from MCIS. Forward the flow to HCA # 4. In this case, HCA # 4 obtains the location information of HCA # 1 through a location notification message from MCIS. When the data flow constitutes an interactive session, the MN2 may send the data flow to the MN1 in the reverse direction of the path from which the MN1 sent the data flow.

4. Delivery process of initial data flow

The packet forwarding procedure is based on the HCA to which the MN (for example, NN1) is connected, and the location inquiry / response message and the location notification / notification ack. The CoA address (ie, the address of the HCA) of the counterpart node (CN, for example, MN2) included in the message may be an IPv4 or IPv6 address. In addition, the type of tunnel made according to the type of CoA may be as follows.

IPv4 Core Network IPv6 Core Network IPv4 in IPv4 IPv4 in IPv6 IPv6 in IPv4 IPv6 in IPv6

Table 10 shows the types of tunnels that can be created depending on whether the core network is IPv4 or IPv6. The internal data transmitted by the tunnel may generate an IPv4 session or an IPv6 session according to the type of data session that the current MN and CN communicating with the MN exchange.

11 is a flowchart illustrating an initial data flow delivery process according to an embodiment of the present invention. 11 shows an initial data flow transfer process between MN1 and MN2.

Referring to FIG. 11, in a situation in which MN1 and MN2 are registered in MICS, data packets transmitted from MN1 to MN2 are delivered to different HCAs according to a physical interface through which the packet is transmitted in MN1. In the example of FIG. 11, the data packets are delivered to HCA # 1 through IF1 of MN1. The data packets may create an IPv4 session or may create an IPv6 session. If an IPv4 session is created, the addresses of MN1 and MN2 are IPv4 addresses, and if an IPv6 session is created, the addresses of MN1 and MN2 are IPv6 addresses. Similarly, data packets transmitted from MN2 to MN1 are delivered to different HCAs according to the physical interface through which the packet is transmitted from MN2. In the example of FIG. 11, the data packets are delivered to HCA # 4 through IF2 of MN2. At this time, the addresses of the HCAs may be IPv4 or IPv6 addresses according to the address policy of the core network.

After HCA # 1 recognizes 5-tuple information of the packet for transmission of the packet received from MN1, the HCA # 1 determines a next hop with reference to a packet forwarding table (PFT). In this case, the packet forwarding table may be configured as shown in Table 4, Table 8, or Table 9. If there is no destination address information for the corresponding 5-tuple flow information in the PFT, the HCA # 1 transmits a location query message to the MICS (S1100). HCA # 1 may query MICS for the location of the current CN (ie MN2 here) using the location query message. At this time, the location query message includes MN1-ID, HCA # 1 address (IPv4 or IPv6), and 5-tuple information of the flow.

Packets received during the location query delay for the CN (here MN2) are stored in an internal buffer of HCA # 1. If the number of packets stored exceeds a predetermined threshold, the HCA (here, HCA # 1) sends an MN (here MN1) to send an Internet Control Message Protocol (ICMP) Source Quench message to reduce packet throughput. Can be.

Receiving the location query message transmitted from HCA # 1, MICS searches its GBT and flow binding table to obtain information on which HCA should be sent to the HCA where the CN (here MN2) is located. That is, MICS determines the flow mobility (direction) based on the flow binding information (S1110). In the example of FIG. 11, MICS selected (or determined) HCA # 4 among HCA # 3 and HCA # 4 where MN2 is located. In this case, the GBT may be configured as shown in Table 1 or the GBT of FIG. 10. In addition, the flow binding table may be configured like the flow binding table of FIG. 10.

Thereafter, MICS transmits a location response message to HCA # 1 (S1120). MICS informs HCA # 1 of the address of HCA # 4 using the location response message. The location response message includes MN-ID, CoA information of MN2 (ie, HCA # 4), and flow selector information for the current flow.

HCA # 1 packet forwards tunnel interface information between HCA # 1 and HCA # 4 for a flow selector that creates a tunnel to HCA # 4, is included in the location response message received from MICS, and allows the current flow to be filtered. Add to table (PFT). At this point, buffering stops, and HCA # 1 forwards the packet through tunneling. The type of tunnel created at this time depends on the type of address policy of the core network and the session type between the MN (MN1 in this case) and the CN (MN2 here), as shown in Table 10 above.

MICS reverses the source address and the destination address in reverse with respect to the 5-tuple information of the flow received from the HCA # 1, and configures the 5-tuple information which reverses the transmission port and the reception port. The 5-tuple information is reverse flow information of an existing flow transmitted from HCA # 1 to HCA # 4. The reason for configuring the reverse flow information as described above is that the flow selector information to be transmitted to the MN2 (or the HCA to which the MN2 is connected) may be the flow selector information for the reverse direction of the flow currently transmitted from the MN1. Based on the reverse flow information, MICS searches for an appropriate entry in its flow binding table and transmits a location notification message to HCA # 4 (S1130). The MICS may transfer information of HCA # 1, which is CoA of MN1, to HCA # 4 using the location notification message. At this time, the location notification message includes MN-ID, CoA information of MN1 (that is, HCA # 1), and flow selector information for the backward flow of the current flow.

When HCA # 4 receives the location notification message, HCA # 4 is included in the location notification message, and the tunnel interface information between HCA # 1 and HCA # 4 for the flow selector, which enables the filtering of reverse flows, to its PFT. Add. In addition, HCA # 4 transmits a Location Notification Ack. Message to MICS (S1140). The type of tunnel generated at this time depends on the type of address policy of the core network and the session type between MN2 and MN1 as shown in Table 10 above.

Control messages may be used in the above procedures, and the control messages may be delivered through a Label Switched Path (LSP) tunnel.

On the other hand, S1130 may be performed before S1120, or S1120 may be performed before S1130, or may be performed simultaneously.

5. Flow Movement Procedure

The flow mobility control proposed in the present invention is based on the network. However, even in this case, the MN can connect a new interface by itself. In addition, MICS may attempt to move any service flow from the currently serviced interface to another interface, and may try to move the service flow to another interface according to the MN's decision and MICS 'permission. Therefore, the "network-based flow mobility technology" defined in the present invention and the time point at which the flow mobility control is started according to the present invention include the following contents.

(1) Flow movement by new connection of MN

Flow mobility control may be initiated when the MN connects to any network via a new interface. At this time, redistribution of the flow is automatically started by flow binding information of MICS and MN.

(2) Flow movement by judgment of MICS

The network side where the MICS is installed may determine the state of the wired / wireless link (for example, whether the link is in operation, a congestion state, the number of terminals in service and the number of flows). Therefore, MICS may initiate the flow mobility control vehicle at any time at its discretion.

(3) Flow movement by MN judgment and MICS permission

Sometimes the MN may try to move any flow from one interface to another. The network should then be able to allow such flow movement. Therefore, the MN may move the flow after requesting information about the flow movement from MICS and receiving the permission.

Hereinafter, the case (1) to (3) may be described as follows, for example.

Case 1: flow movement procedure by new connection of mobile terminal

12 illustrates a flow movement procedure by a new connection of a mobile terminal according to the present invention.

Referring to FIG. 12, in (a), the MN transmits and receives Flow 1 and Flow 2 through HCA # 1 using a WLAN PI1 interface among its physical interfaces. It is assumed here that the flow ID of flow 1 is 4 and the flow ID of flow 2 is 3. At this time, the flow binding table and session information table managed by MICS may be as follows.

Table 11 shows an initial flow binding table for an MN (eg MN1), Table 12 shows an initial flow binding table for a CN (eg MN2) communicating with the MN, and Table 13 shows session information. Represents a table.

As shown in Tables 11-13, flow 2 corresponds to a 5-tuple of (*, *, 150, *, UDP) or (*, *, *, 150, UDP), and the flow is 3G in priority. Is higher, but the MN has not yet connected to the network through the 3G interface, and thus cannot connect through the 3G interface. In this case, the MN is in a state of transmitting and receiving flow 2 through the WLAN on the second priority. However, when the MN makes a network connection through the 3G interface, since the binding information of the flow 2 is 3G higher, as shown in FIG. 12 (b), the MN uses the 3G interface PI2 to perform the flow 2 through the HCA # 2. Can send and receive The flow mobility control procedure for this can be specifically described as follows.

13 is a flowchart illustrating a flow mobility control procedure by a new connection of MN according to an embodiment of the present invention.

Referring to FIG. 13, initially, the MN is connected to a network through only the interface IF1, and the XN, Y1, X2, and Y2 flows are exchanged with the CN through the IF1. Thereafter, when the MN is connected to the new network through IF2, and the network priority for X2 and Y2 is higher than that of the new network, flow movement for X2 and Y2 occurs.

In more detail, the MN establishes an L2 association (L2 Association) to PoA # 2, which is a point of attachment (PoA) for a new network, through IF2 (Interface 2) (S1300). The process of establishing an L2 connection through the IF2 of the MN includes a user authentication procedure of authenticating a user subscribed to each provider network to confirm access authority. In this case, the user authentication procedure is performed through the exchange of authentication information between the MN and the CUPS managing the subscriber profile for the access network. The identifier of the MN used in CUPS is NAI.

When the L2 connection process including the user authentication procedure is completed through the IF2 of the MN, an L2 link up trigger (L2 link up trigger) indicating a new link establishment occurs in the L2 layer of PoA # 2 (S1305). The L2 link up trigger is converted into a MIH link up trigger by a Media Independent Handover (MIH) layer of PoA # 2.

PoA # 2 transmits a location report message to HCA # 2 for initiating a network-based registration procedure based on the MIH link up trigger (S1310). The location report message includes the ID of the MN and L2 ID # 2 which is the L2 ID for IF2.

The HCA # 2 that has received the location report message responds to the PoA # 2 with a location report Ack. Message (S1315). Thereafter, HCA # 2 extracts the L2 ID of the MN, and searches for a corresponding binding entry in the MN Binding Table (MBT) that it manages. HCA # 2 includes L2 ID # 2, which is the MN ID and L2 ID information for IF2, and an access network type, lifetime, and NIC (Network Interface Card) ID of HCA # 2. Record it.

HCA # 2 transmits a location registration message to MICS (S1320). The location registration message includes ID of MN, L2 ID # 2 which is L2 ID of IF2, and CoA # 2 information which is its own IP address.

The MICS determines flow mobility (direction) for X2 and Y2 when the network priority for the X2 and Y2 is higher based on the flow binding information, when the new network to which the IF2 is connected is higher (S1325).

MICS transmits a location notification message to HCA # 4 (S1330). In this case, the MICS may transfer the MN's HCA # 2 information (CoA information) and flow selector information managed by the session information to the MN based on the session information that the MICS has.

Meanwhile, MICS transmits a Location Registration Ack. Message to HCA # 2 (S1335). In this case, the MICS may transmit CN HCA # 4 information (CoA information) and flow selector information managed by the session information to the MN based on the session information it has.

HCA # 4 transmits a location notification Ack. (Location Notifiaction Ack.) Message to the MICS (S1340). Thereafter, MN may exchange flow X2 and flow Y2 with CN through HCA # 4 through newly connected HCA # 2 using IF2. The flow movement situation is as follows.

14 schematically illustrates a flow movement situation due to a new connection of an MN.

Referring to FIG. 14, initially, the MN is connected to a network through only the interface IF1, and the XN, Y1, X2, and Y2 flows are exchanged with the CN through the IF1. In this case, for example, the 5-tuple of the X1 flow is (IP1, IP2,212,80, TCP), the 5-tuple of the X2 flow is (IP1, IP2,399,150, UDP), and the 5-tuple of the Y1 flow is ( Suppose that the 5-tuples of IP2, IP1, 80, 212, TCP), and the Y2 flow are (IP2, IP1, 150, 399, UDP). All the flows are currently transmitted and received between the MN and the CN through the HCA # 1 and HCA # 4. Thereafter, when the MN is connected to the new network through IF2, and the network priority for X2 and Y2 is higher than that of the new network, flow movement for X2 and Y2 occurs. At this time, MN performs Location Registration and Location Registration Ack. With MICS through HCA # 2 of new network, and MICS performs HCA # 4 of CN currently communicating with MN. Send and receive a Location Notification and a Location Notification Ack. In this process, MICS transfers each of the CoA information (that is, HCA information between each other) and flow selector information managed by session information to HCA # 4 of CN and new HCA # 2 of MN1 based on the session information thereof. . As a result, flow X2 and flow Y2 are transmitted and received through HCA # 2 of the new network through IF2 of the MN. That is, the flows X2 and Y2 are transmitted and received between the MN and the CN through the HCA # 2 and the HCA # 4. After the flow mobility control is performed as described above, the packet forwarding table in HCA # 2 and HCA # 4 and the session information table in MICS may be as follows.

Table 14 shows a packet forwarding table of HCA # 2, Table 15 shows a packet forwarding table of HCA # 4, and Table 16 shows a session information table of MICS. Referring to Table 15, as shown in FIG. 14, it can be seen that the forwarding address of flow Y2 having a 5-tuple value of (IP2, IP1, 150, 399, UDP) has been changed from HCA # 1 to HCA # 2. Referring also to Table 16, flow X2 having a 5-tuple value of (IP1, IP2,399,150, UDP) and flow Y2 having a 5-tuple value of (IP2, IP1,150,399, UDP) as described in FIG. It can be seen that a session between the HCA # 2 and the HCA # 4 is configured and transmitted and received.

Case 2: flow movement procedure based on MICS 'own judgment

As described above, the network side on which the MICS is operated may determine the state of the wired / wireless link (for example, whether the link is in operation, a congestion state, the number of terminals in service and the number of flows, etc.). Therefore, the flow may be performed at any point of time under the judgment of MICS. In this case, the following characteristics are present.

In view of a receiver node (for example, MN2 or CN) receiving an inbound flow, MICS can move only the inbound flow received by the receiver. That is, the MN determines which interface an MN (for example, MN1) that transmits an outbound flow transmits a transmission flow through, and the MICS determines only the inbound flow from the receiver's perspective of receiving the inbound flow. Can be changed to receive via another interface (or other network). However, even in this case, if the outbound flow emitted by the receiver node is also present in the same session as the moved inbound flow, the outbound flow can control the inbound flow to be transmitted through the same interface where the flow is received.

In addition, the MICS may insert a dynamic entry managed as a soft state in the flow binding table on the basis that it is temporary to move the flow at its own discretion.

Hereinafter, a procedure of moving a flow under the determination of MICS may be specifically described as follows.

15 is a flowchart illustrating a procedure of moving a flow under the determination of MICS according to an embodiment of the present invention. FIG. 15 illustrates a case in which MN1 and MN2 connect two interfaces (eg, 3G and WLAN) to a network, respectively, and exchange flows related to session X and session Y. As described above, the MN2 that communicates with the MN1 based on the MN1 may be referred to as CN, and vice versa.

Referring to FIG. 15, session X is composed of HCA # 1 of MN1 and HCA # 4 of MN2, and session Y is composed of HCA # 2 of MN1 and HCA # 4 of MN2. MICS determines the flow movement based on the network state (S1500). For example, MICS may decide to move the flow of session Y from MN1 to MN2 (which constitutes outbound flow for MN1 and inbound flow for MN2) from MN2's existing network to the new network. . In this case, MICS may insert a dynamic entry managed as a soft state in the flow binding table based on the criterion that moving the flow is temporary at its discretion. In this case, the flow binding table in which MICS manages for MN2 and newly added dynamic entries may be as follows.

Referring to Table 17, MN2 was previously receiving an inbound flow of 5-tuple values (IP1, IP2, 399, 150, UDP) through a 3G network managed by HCA # 3 of flow ID 3, and under HICS 'judgment, HCA. To move to WLAN managed by # 4, MICS added a dynamic entry such as Flow ID 101. The dynamic entry is a flow selector with very specific information about the flow, with a lifetime set for maintaining a temporary state. Therefore, if the flow is not received for more than a certain time, the entry is deleted and the MN2 receives the inbound flow that is subsequently received using the original static entry, here flow ID 3 again.

On the other hand, after adding the dynamic entry, MICS transmits a location notification message to the HCA # 4 (S1510). The HCA # 4 is a newly selected HCA for sending the flow (inbound flow in the view of MN2) to MN2. The location notification message includes MN1-ID, MN1 HoA, MN1 CoA (HCA # 2), and flow selector information for the flow transmitted from MN2 to MN1 among the flows of session Y. Through the location notification message, MICS notifies in advance that a new flow is transmitted to HCA # 4, and HCA # 4 may perform a tunneling operation based on this.

In addition, MICS transmits a location notification message to HCA # 2 (S1520). Herein, the HCA # 2 is an HCA from which the corresponding flow (outbound flow in the view of MN1) rises from MN1. The location notification message includes MN2-ID, MN2 HoA, MN2 CoA (HCA # 4), and flow selector information for the flow transmitted from MN1 to MN2 among the flows of session Y. Through the location notification message, MICS may inform HCA # 2 that the counterpart of the tunneling is HCA # 4, not HCA # 3.

HCA # 4 and HCA # 2 are the location notification Ack. The message is transmitted to the MICS (S1530, S1540).

Thereafter, HCA # 2 and HCA # 4 may transmit a corresponding flow through a new path between HCA # 2 and HCA # 4. In this case, MN2 may receive a flow through HCA # 4 that does not match the flow binding list information that it originally managed. In such a situation, MN2 manually accepts such a flow and generates a dynamic entry as follows. Can be added to the MN2's flow binding list.

Referring to Table 18, MN2 was previously transmitting an outbound flow of 5-tuple values (IP2, IP1, 150, 399, UDP) through a 3G network managed by HCA # 3 of flow ID 3. We added a dynamic entry, such as flow ID 101, to move the to the WLAN managed by HCA # 4.

Case 3: flow movement procedure by MN judgment and MICS permission

When the terminal itself attempts to move some of the flows currently being sent and received from the current interface to another interface, the terminal may send the intention of the terminal to the MICS via the HCA, and may be judged suitability for such flow movement from the MICS. In this case, if MICS determines that it is appropriate, the flow can be moved similarly to the general Location Registration procedure. In this case, it has the following characteristics.

In case 3, only the transmission flow can move from the perspective of the sender node transmitting the transmission flow. That is, the MN transmitting the transmission flow must determine which interface to send the flow through and then inform MICS of the intention. If the MICS determines that it is appropriate, the MN sends the transmission flow to the desired interface. If the receiving flow also exists in the same session as the sending flow, it enters the MN through the same interface. In this case, MICS also changes the flow binding table for the MN requesting the flow movement to process the reception flow.

In addition, in the MN and MICS, it may be possible to insert a dynamic entry managed in a soft state into the flow binding list of the MN and the flow binding table managed by the MICS for the MN in the MN and the MICS. have.

Hereinafter, a procedure of moving a flow under determination of MN and suitability of MICS may be described in detail as follows.

16 is a flowchart illustrating a procedure of moving a flow under determination of MN and determination of suitability of MICS according to an embodiment of the present invention. 16 illustrates a case in which MN1 and MN2 connect two interfaces (eg, 3G and WLAN) to a network, respectively, and exchange flows related to session X and session Y. As described above, the MN2 that communicates with the MN1 based on the MN1 may be referred to as CN, and vice versa.

Referring to FIG. 16, session X is composed of HCA # 1 of MN1 and HCA # 4 of MN2, and session Y is composed of HCA # 2 of MN1 and HCA # 4 of MN2. The MN determines flow movement (S1600). For example, the flow of MN1 from MN1 to MN2 in session Y flow (which constitutes outbound flow for MN1 and inbound flow for MN2) is not WLAN of MN2's existing 3G network (HCA # 2). It may be decided to move to the network HCA # 1.

The MN1 transmits a flow mobility indication message to the HCA # 1 (S1610). In this case, the MN1 transmits a flow selector for the flow to be moved to the HCA # 1 through the flow mobility indication message. In other words, the flow mobility indication message includes a flow selector for a flow to which MN1 intends to move.

In response to the flow mobility indication message, HCA # 1 transmits a location registration message including the flow selector to MICS (S1620).

The MICS is included in the location registration message including the flow selector, and determines suitability for flow movement requested by MN1 (S1630). MICS may determine the suitability on the basis of network status (status) and the like. If the determination result is positive, MICS inserts a dynamic entry managed in a temporary state into the flow binding table managed for MN1. In this case, the MICS manages the MN1, and the flow binding table in which the dynamic entry is newly added may be as follows.

Referring to Table 19, MN1 was previously receiving an inbound flow of 5-tuple values (IP2, IP1, 150, 399, UDP) through a 3G network managed by HCA # 2 of flow ID 3, and under the determination of MN1, HCA To move to WLAN managed by # 1, MICS added a dynamic entry such as flow ID 101. The dynamic entry is a flow selector having specific information on the flow, and a lifetime for maintaining a temporary state is set. Therefore, if the flow is not received for more than a certain time, the entry is deleted and the MN2 receives the inbound flow that is subsequently received using the original static entry, here flow ID 3 again.

On the other hand, after adding the dynamic entry, MICS transmits a location notification message to the HCA # 3 (S1640). The location notification message includes MN1-ID, MN1 HoA, MN1 CoA (HCA # 1), and flow selector information for the flow transmitted from MN2 to MN1 among the flows of session Y. The location notification message may allow MICS to tunnel to HCA # 3. That is, HCA # 3 can change the opposite point of the tunnel for session Y.

MICS also registers its location with HCA # 1. The message is transmitted (S1650). Register Location Ack. The message includes MN2-ID, MN2 HoA, MN2 CoA (HCA # 3), and flow selector information for the flow sent from flow increase MN1 to MN2 of session Y. In addition, the location registration Ack. The message may further include suitability for flow movement requested by MN1.

HCA # 1 is the location registration Ack. If the message is received, and whether the MN1 conforms to the requested flow movement, the MN1 generates a tunnel for the flow as HCA # 3.

On the other hand, HCA # 3 informs MICS of the location notification Ack. The message is transmitted (S1660).

HCA # 1 is the flow mobility Ack. A message is generated and transmitted to MN1 (S1670). The flow mobility Ack. The message includes the suitability for the flow movement requested by MN1. If the MN1 is positive about the requested flow movement, the MN1 may add a dynamic entry to the flow binding list managed by the MN1 as follows.

Referring to Table 20, MN1 was previously transmitting outbound flows of (IP1, IP2, 399, 150, UDP) through a 3G network managed by HCA # 2 of flow ID 3. MN1 added a dynamic entry such as flow ID 101 to move the flow to the WLAN managed by HCA # 1.

17 is an operation flowchart of MICS supporting network-based flow mobility according to an embodiment of the present invention.

Referring to FIG. 17, MICS receives a location registration message from any HCA connected to an MN (S1700). The location registration message may include an ID of the MN, an L2 ID of the physical interface of the MN, and CoA information of the HCA. The location registration message may further include flow selector information.

The MICS determines movement of a flow configured in another HCA to which an MN is connected based on preset static flow binding information or a network state (S1710). The MICS controls the packet transmitted by the MN to the HCA indicated by the static flow binding information based on preset static flow binding information.

For example, the MN transmits and receives Flow 1 and Flow 2 through HCA # 1 using PI1 among its physical interfaces. Thereafter, the MN uses PI2 to connect to the network through HCA # 2. According to the static flow binding information, in the case of the flow 2, if the priority is PI2 higher than PI1, MICS may determine the movement of the flow. .

As another example, MICS can determine the network status. For example, the MICS may determine whether the wired / wireless link is in operation, a congestion state, the number of UEs in service and the number of flows, and may determine the movement of the flow based on this.

Meanwhile, when MICS makes a movement determination on a flow based on the network state, the dynamic flow binding information may be configured and managed in a flow binding table based on the criterion that moving the flow under its own determination is temporary. . In this case, the dynamic flow binding information is managed in a temporary state and a life time indicating a valid time of the information is set.

MICS registered location Ack. The message is transmitted to the arbitrary HCA (for example, HCA # 1) connected with the MN (S1720). Register Location Ack. The message includes movement information of the flow. The movement information is information about an HCA configured with the flow and connected with a CN (Corresponding Node), the ID of the CN, HoA of the CN, and the HCA configured with the flow and connected with the CN (for example, HCA # 4). CoA, and flow selector information. In addition, the location registration Ack. The message may further include the dynamic flow binding information.

The MICS transmits a location notification message to the HCA (for example, HCA # 4) in which the flow is configured and connected to the CN (S1730). The location notification message includes movement information of the flow. The movement information is information about the arbitrary HCA to which the flow is to be moved, and includes an ID of an MN, a HoA of an MN, a CoA of an arbitrary HCA (eg, HCA # 1) connected to the MN, and flow selector information. Include. The location notification message may further include the dynamic flow binding information.

In addition, the MICS may independently determine the flow movement based on the network state and then transmit a location notification message to the HCA (eg, HCA # 1) connected to the MN. In this case, the location notification message includes an ID of a CN, a HoA of a CN, a CoA of an HCA (for example, HCA # 4) in which the flow is configured and connected to the CN, and flow selector information. In addition, the location notification Ack. The message may further include the dynamic flow binding information.

18 is an operation flowchart of an HCA supporting network-based flow mobility according to an embodiment of the present invention.

The HCA receives the flow mobility indication message from the MN (S1800). The flow mobility indication message includes flow selector information indicating that the MN moves a flow to an interface different from a physical interface based on static flow information with respect to a data packet received from an upper layer.

The HCA transmits a location registration message to MICS (S1810). The location registration message includes the flow selector information.

HCA Registered Ack. A message is received from MICS (S1820). Register Location Ack. The message contains movement information of the flow. Register Location Ack. The message may further include suitability for flow movement. The movement information includes an ID of a CN, a HoA of the CN, a CoA of an HCA (eg, HCA # 4) in which the flow is configured and connected to the CN, and the flow selector information. The ID of the CN uses NAI.

HCA manages the packet forwarding table. The HCA updates the packet forwarding table based on the flow selector information and tunnels to the HCA (eg, HCA # 4) connected to the CN.

The location registration Ack message may further include dynamic flow binding information configured by MICS.

HCA Flow Flow Ack. A message is transmitted to the MN (S1830). Register Location Ack. The message may further include suitability for flow movement. The flow mobility Ack. The message may further include dynamic flow binding information configured by the MICS.

19 is an operation flowchart of an MN supporting network-based flow mobility according to an embodiment of the present invention.

The MN determines the flow movement (S1900). The MN has a number of physical interfaces. The MN may determine the flow of flows to a different interface from the physical interface based on the static flow information with respect to the packet from the upper layer.

The MN transmits a flow mobility indication message to the HCA of the MN (S1910). The flow mobility indication message includes flow selector information indicating that the flow is to be moved to an interface different from a physical interface based on static flow information with respect to the packet.

MN indicates flow mobility indication Ack. A message is received from the HCA (S1920). The flow mobility indication Ack. The message may include whether flow movement is appropriate. The flow mobility indication Ack. The message may include dynamic flow binding information configured by MICS. The MN may manage a flow binding list and add the dynamic flow binding information to the flow binding list.

As described above, the present invention provides a method for supporting location registration and mobility for each service flow for a multi-mode MN having a plurality of wired and wireless network interfaces. Through this, it is possible to efficiently use the resources of the network by selecting and accessing the optimum communication network suitable for each service characteristic that the MN is using in an environment where various wired and wireless networks overlap.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

Claims (16)

As a method of supporting flow mobility based on Access Independent Mobility Service (AIMS) by Mobility Information Control Server (MICs),
Receiving a location registration message from any Handover Control Agent (HCA) associated with a Mobile Node (MN);
Determining a movement of a flow configured in another HCA to which an MN is connected based on preset static flow binding information or network state;
The flow registration is configured, the location registration Ack containing information about the HCA associated with the CN (Corresponding Node). Sending a message to the any HCA; And
And sending a location notification message including information about the HCA to which the flow is to be moved to the HCA in which the flow is configured and associated with the CN. . The method of claim 1,
And determining the movement of the flow based on the static flow binding information is based on a priority of the static flow binding information. The method of claim 1,
The movement determination for the flow based on the network state is characterized in that based on at least one of the presence or absence of operation of the wired or wireless link, the congestion state, the number of the MN in service, and the number of flows. The method of claim 1,
Configuring dynamic flow binding information when determining the movement of the flow based on the network state;
Register Location Ack. And the location notification message includes the dynamic flow binding information. The method of claim 1,
The flow is configured, and information about an HCA connected to a CN (Corresponding Node) includes the ID of the CN, a home address (HoA) of the CN, a care-of-address (CoA) of the HCA connected to the CN, and a flow selector ( flow selector), wherein the ID of the CN uses a network access identifier (NAI). The method of claim 1,
The information about the arbitrary HCA to which the flow is to be moved includes the ID of the MN, the HoA of the MN, the CoA of the arbitrary HCA, and flow selector information, wherein the ID of the MN uses NAI. , How to support flow mobility. AIMS-based flow mobility support method by HCA,
Receiving, from the MN, a Flow Mobility Indicate message including flow selector information indicative of moving the flow to a different interface from the physical interface based on the static flow information for the packet;
Transmitting a location registration message including the flow selector information to MICS;
Location registration Ack including movement information of the flow. Receiving a message from the MICS; And
Flow Mobility Ack. Sending a message to the MN. 8. The method of claim 7,
The flow mobility Ack. The message includes flow mobility suitability, characterized in that the flow mobility support method. 8. The method of claim 7,
The mobility information includes an ID of a CN, a HoA of the CN, a CoA of an HCA in which the flow is configured and connected to the CN, and the flow selector information, wherein the ID of the CN uses NAI. How to apply. The method of claim 9,
And updating a packet forwarding table based on the CoA of the HCA connected to the CN and the flow selector information. The method of claim 9,
And performing tunneling with the HCA associated with the CN. 8. The method of claim 7,
Register Location Ack. Message and the flow mobility Ack. The message comprises dynamic flow binding information. AIMS-based flow mobility support method by MN,
Determining a movement of a flow to a different interface from the physical interface based on the static flow information for the packet;
Sending a flow mobility indication message to the HCA, the flow mobility indication message including flow selector information indicating to move the flow to an interface different from a physical interface based on static flow information for the packet;
Flow Mobility Instruction Ack. Receiving a message from the HCA. The method of claim 13,
The flow mobility indication Ack. The message includes flow mobility suitability, characterized in that the flow mobility support method. The method of claim 13,
The flow mobility Ack. The method of supporting flow mobility, wherein the message includes dynamic flow binding information. 16. The method of claim 15,
And adding the dynamic flow binding information to a flow binding list.

Images