KR101084137B1 - Method of supporting handover in multi-mode mobile terminal - Google Patents

Abstract

The present invention relates to a method for supporting a mobile terminal consisting of multi-mode (eg, broadband wireless access network system and wireless LAN interface, wired LAN, cellular system interfaces) to efficiently perform handover between heterogeneous networks. will be. In the method for supporting handover of a mobile terminal according to the present invention, in the method for supporting handover of a mobile terminal configured in a multi-mode, the mobile terminal knows whether a point of attachment supports MIHF. Sending a request message to bet; Accessing the request message to the access point 3 based on the destination address of the request message received by the access point 1; And determining that the PoA3 does not support the MIHF when the mobile station does not receive a response from the PoA3 until a predetermined time elapses from the transmission of the request message. In addition, the MIH packet format and the MIH signal message format for transmitting and receiving MIH signal messages between the mobile station and the access point or between the access points, or between the access point and the access router or the access router are defined.

Multimode, Mobile Terminal, Heterogeneous Network, Handover, Link Search

Description

Method of supporting handover in multi-mode mobile terminal {Method of supporting handover in multi-mode mobile terminal}

1 is a diagram illustrating a protocol layer configuration of a mobile terminal configured in a multi-mode in the prior art.

2 is a view for explaining the functional entities and transmission protocol of the mobile terminal and the network including the MIH function in the prior art.

Fig. 3 shows the structure of a trigger model in the prior art.

Figure 4 is an exemplary view showing a trigger that occurs until the quality of the link to which the mobile terminal is currently connected in the prior art until a new link is established.

5 shows the structure of the 'Link Event' and 'MIH Event' models in the present invention.

Figure 6 illustrates the structure of a 'Remote Link Event' model in the present invention.

Figure 7 illustrates the structure of the 'Remote MIH Event' model in the present invention.

Figure 8 illustrates the structure of the 'MIH Command' and 'Link Command' model in the present invention.

9 illustrates the structure of a 'Remote MIH Command' model in the present invention.

10 illustrates the structure of a 'Remote Link Command' model in the present invention.

FIG. 11 is a diagram illustrating a message flow for a medium-independent information service of a mobile terminal. FIG.

Figure 12 illustrates the relationship between MIH functions and other protocol layers within a protocol stack in one preferred embodiment of the present invention.

Figure 13 illustrates the message format of a MIH packet in one preferred embodiment of the present invention.

Figure 14 illustrates a message format of a MIH packet in another preferred embodiment of the present invention.

Figure 15 is a procedure flow diagram of one preferred embodiment of the present invention.

Figure 16 is a procedure flow diagram of another preferred embodiment of the present invention.

Figure 17 is a procedure flow diagram of yet another preferred embodiment of the present invention.

18 is a process flow diagram of yet another preferred embodiment of the present invention.

Figure 19 is a procedure flow diagram of yet another preferred embodiment of the present invention.

The present invention relates to a multi-mode mobile terminal. More specifically, the present invention is a method for supporting a mobile terminal configured in a multi-mode (eg, broadband wireless access network system and wireless LAN, wired LAN, cellular system interface) to efficiently perform handover between heterogeneous network (heterogeneous network) It is about.

IEEE802.21, which is in the international standardization of Media Independent Handover (MIH) between heterogeneous networks, provides mobile handset by providing seamless handover and service continuity between heterogeneous networks. To improve the user convenience of the device, the basic requirements are defined MIH function (MIH function), Event Trigger (Event Trigger) and Information Service (IS).

A mobile subscriber station (MSS) is a multi-mode node that supports more than one interface type. The interface type may be a wire-line interface type such as Ethernet based on IEEE802.3, a wireless interface type based on IEEE802.XX such as IEEE802.11, IEEE802.15, IEEE802.16, or 3GPP. , May be any one of interface types defined by a cellular standardization organization such as 3GPP2. However, the present invention is not limited thereto.

1 is a diagram illustrating a protocol layer configuration of a mobile terminal configured in a multi-mode. Referring to FIG. 1, a multi-mode mobile terminal has a physical layer (PHY) and a medium access control layer (MAC) layer for each mode, and a MIH layer is located below the IP layer.

Media Independent Handover (MIH) must be defined between IEEE802 series interfaces or between non-802 series interfaces such as IEEE802 series interfaces and interface types defined by cellular standardization organizations such as 3GPP and 3GPP2. Higher-level mobility support protocols such as Mobile IP and Session Initiation Protocol (SIP) should be supported for handover and seamless service.

The MIH function is located below the IP layer and facilitates a handover process by using input values from Layer 2, such as a trigger event and information about another network. In addition, the MIH function may include user policy and configuration based inputs that may affect the handover process, and may include a layer 3 such as mobile IP or SIP. Generic interfaces are defined between the entity and the MIH function. These interfaces provide information about layer 1 (physical layer) and layer 2 (media access control layer) and mobility management. The MIH layer obtains information about lower layers and networks with the help of events and information services.

In the upper layer, a higher management entity for monitoring and controlling the status of various links in the mobile terminal is located to perform a handover control function and a device manager function. At this time, the handover control function and the device manager may be independently located, respectively, the two functions may be included together as a higher management entity. FIG. 2 illustrates functional entities and transmission protocols of a mobile terminal and a network including MIH functions, and a dotted line in FIG. 2 represents a primitive, an event trigger, and the like.

For fast handover, the network layer needs to use the information from the link layer so that the connection can be reestablished as soon as possible. Link layer events can help predict user movement and can help the mobile terminal and network to prepare for handover in advance.

Triggers for handover can be initiated from the physical layer (PHY), the media access control layer (MAC), and the source for these triggers can be a local stack or a remote stack. 3 shows a structure for a trigger model.

Event triggers provide a change in the state of the current signal and other network states, future predicted changes, and include changes in the physical and media access control layers or changes in the properties of a particular network.

The event type may be classified into a PHY layer event, a media access control layer event, a MAC layer event, a management event, an L3 event, an application event, and the like. .

The basic trigger events are as follows:

'Link_Up' occurs when a two-layer connection is established on a particular link interface and can transmit three-layer packets in the upper layer. At this time, it is determined that all two-layer configuration constituting the link is completed. At this time, event sources are 'Local MAC' and 'Remote MAC'. Table 1 shows the parameters of 'Link_Up'.

Name Type Description EventSource
EVENT_LAYER_TYPE Source where the event was generated EventDestination EVENT_LAYER_TYPE Destination to which event will be delivered MacMobileTerminal MAC Address MAC address of mobile terminal MacOldAccessRouter MAC Address MAC address of the previous access router MacNewAccessRouter MAC Address MAC address of new access router NetworkIdentifer Media Specific Network identifier that can be used to detect changes in subnet

'Link_Down' occurs when a layer 2 connection is released on a particular interface and no more layer 3 packets can be sent. The event source is 'Local MAC'. Table 2 shows the parameters of 'Link_Down'.

Name Type Description EventSource
EVENT_LAYER_TYPE Source where the event was generated EventDestination
EVENT_LAYER_TYPE Destination to which event will be delivered MacMobileTerminal MAC Address MAC address of mobile terminal MacOldAccessRouter MAC Address MAC address of the previous access router ReasonCode Reason for unlinking

'Link_Going_Down' occurs when a 2 layer connection is expected to be 'linked down' within a specific time, and may be a signal for initiating a handover procedure. Event sources are 'Local MAC' and 'Remote MAC'. Table 3 shows the parameters of 'Link_Going_Down'.

Name Type Description EventSource EVENT_LAYER_TYPE Source where the event was generated EventDestination EVENT_LAYER_TYPE Destination to which event will be delivered MacMobileTerminal MAC Address MAC address of mobile terminal MacOldAccessRouter MAC Address MAC address of the previous access router MacNewAccessRouter MAC Address MAC address of new access router Timeinterval Time in msecs The time when the link is expected to be Link_Down ConfidenceLevel % The level at which a link is expected to be Link_Down at a specific time. UniqueEventIdentifer Used when event rollback occurs

'Link_Going_Up' occurs when a layer 2 link is expected to be 'Link_Up' within a certain time and is used when the network takes a long time to initialize. Event sources are 'Local MAC' and 'Remote MAC'. Table 4 shows the parameters of 'Link_Going_Up'.

Name Type Description EventSource EVENT_LAYER_TYPE Source where the event was generated EventDestination EVENT_LAYER_TYPE Destination to which event will be delivered MacMobileTerminal MAC Address MAC address of mobile terminal MacNewAccessRouter MAC Address MAC address of new access router Timeinterval Time in msecs Estimated time to be Link_UP ConfidenceLevel % The level at which a link is expected to be Link_Up at a specific time UniqueEventIdentifer Used when event rollback occurs

'Link_Event_Rollback' is used in combination with 'Link_Going_Up' and 'Link_Going_Down'. Trigger that occurs when 'Link_Going_Up' or 'Link_Going_Down' is transmitted but it is predicted that 'Link_UP' or 'Link_Down' will no longer occur within a certain time. Event sources are 'Local MAC' and 'Remote MAC'. Table 5 shows the parameters of 'Link_Event_Rollback'.

Name Type Description EventSource EVENT_LAYER_TYPE Source where the event was generated EventDestination EVENT_LAYER_TYPE Destination to which event will be delivered MacMobileTerminal MAC Address MAC address of mobile terminal MacNewAccessRouter MAC Address MAC address of new access router UniqueEventIdentifer Used when event rollback occurs

'Link_Available' indicates that a new specific link is available and indicates that the new base station or access point may provide better link quality than the base station or access point (AP) to which the mobile station is currently connected. Indicates. Event sources are 'Local MAC' and 'Remote MAC'. Table 6 shows the parameters of 'Link_Available'.

Name Type Description EventSource EVENT_LAYER_TYPE Source where the event was generated EventDestination EVENT_LAYER_TYPE Destination to which event will be delivered MacMobileTerminal MAC Address MAC address of mobile terminal MacNewAccessRouter MAC Address MAC address of the previous access router MacOldAccessRouter MAC Address MAC address of new access router

'Link_Parameters_Change' is an event that occurs when the change of a link parameter value exceeds a certain limit level. This may include link layer parameters such as link speed, quality of service (QoS), encryption values, and the like. Event sources are 'Local MAC' and 'Remote MAC'. Table 7 shows the parameters of 'Link_Parameters_Change'.

Name Type Description EventSource EVENT_LAYER_TYPE Source where the event was generated EventDestination EVENT_LAYER_TYPE Destination to which event will be delivered MacMobileTerminal MAC Address MAC address of mobile terminal MacAccessRouter MAC Address MAC address of current access router oldValueOfLinkParameter Previous value of link parameter newValueOfLinkParameter New value for the link parameter

4 is an exemplary diagram illustrating a trigger generated until a quality of a link to which a mobile terminal is currently connected is degraded and a new link is established.

The Information Service provides detailed information about the network needed for network discovery and selection, and must be accessible from any network. Information services include link access parameters, security mechanisms, neighbor maps, locations, service providers and other access information, and link costs. information elements such as link).

The prior art defines an event service, a command service, and an information service for handover-independent handover. There is a problem that the MIH protocol procedure, MIH header, message format, etc. are not defined.

The present invention has been made to solve the problems of the prior art as described above, an object of the present invention is to support the handover of the mobile terminal to efficiently support the handover between heterogeneous networks in a multi-mode mobile terminal To provide a way.

According to an aspect of the present invention, there is provided a method for supporting handover of a multi-mode mobile terminal, comprising: transmitting, by the mobile terminal, a request message for determining whether an access point 3 supports MIHF; Accessing the request message to the access point 3 based on the destination address of the request message received by the access point 1; And determining that the PoA3 does not support the MIHF when the mobile station does not receive a response from the PoA3 until a predetermined time elapses from the transmission of the request message.

In addition, the MIH packet format and the MIH signal message format for transmitting and receiving MIH signal messages between the mobile station and the access point or between the access points, or between the access point and the access router or the access router are defined.

FIG. 5 illustrates a structure of a link event and a MIH event model according to the present invention. The MIH event is an event transmitted from the MIH to a higher management entity or higher layer and corresponds to event triggers in the related art. . The link event is an event delivered from the lower layer (MAC or physical layer) to the MIH, and primitives used in each interface MAC layer or physical layer are used.

6 illustrates the structure of a remote link event model according to the present invention. When an event is generated from a lower layer in a local stack to an MIH in the same local stack, The MIH of the local stack delivers the event to the MIH of the remote stack. The same is true when an event is generated from a lower layer in the remote stack to the remote stack MIH, and the remote stack MIH forwards a trigger to the local stack MIH.

7 illustrates a structure of a Remote MIH Event model according to the present invention, in which a MIH in a local stack generates a remote MIH event and transmits it to a counterpart MIH in a remote stack. The MIH of the remote stack delivers the received event to a higher management entity or higher layer in the remote stack. The same is true when an event is generated from a MIH in the remote stack to a local stack MIH, and the local stack MIH delivers the event to an upper layer of the local stack.

FIG. 8 illustrates the structure of a MIH command and a link command model according to the present invention. The MIH command is generated from an upper management entity or higher layer and is transmitted to the MIH, and indicates an action to the MIH. The link command is generated from the MIH and transmitted to the lower layer, which instructs the lower layer to perform some action.

9 illustrates a structure of a remote MIH command model according to the present invention, in which a remote MIH command is generated from an upper management entity or higher layer in a local stack and transmitted to the MIH, and the MIH remotely stacks the received MIH command. Delivers to relative MIH in The same applies to a case where a command is generated from the upper layer in the remote stack to the MIH of the remote stack, and the remote stack MIH transfers the command to the MIH of the local stack.

FIG. 10 illustrates the structure of a remote link command model according to the present invention, in which a MIH in a local stack generates a remote link command and delivers it to a counterpart MIH in a remote stack. The MIH in the remote stack delivers the received remote link command to lower layers in the remote stack. The same is also true when a command is generated from a MIH in a remote stack to a local stack MIH, and the local stack MIH delivers a command to the local stack sublayer.

11 is a diagram illustrating a message flow for an intermediate service information service of a mobile terminal.

1) The MIH of the mobile station sends MIH_info.request to its MAC to request the information service.

2) The MAC of the mobile station transmits an information request frame to the base station.

3) The MAC of the base station transmits the information request of the mobile station to its MIH through MIH_Info.indication.

4) The MIH of the base station delivers the media irrelevant information service it owns to the MAC layer through MIH_Info.response.

5) The MAC of the base station responds to the mobile station with an Information Response frame.

6) The MAC of the mobile terminal transmits the information on the received information service to its MIH as MIH_Info.confirm.

The MIH protocol consists of three phases:

1) MIH Capability discovery: This is a procedure for discovering which entity on the network supports MIH by the MIH of the mobile station or the MIH of the base station / access router.

2) MIH Registration: The MIH between different entities performs a registration procedure with each other to initiate the MIH protocol.

3) MIH Message Exchange: Both MIHs can send and receive MIH messages using the MIH payload and the MIH protocol.

Figure 12 illustrates the relationship between MIH functions and other protocol layers within the protocol stack.

FIG. 13 shows an example of a message format of a MIH packet. Each field will be described below.

1) Message Type (1 octet): Depending on the type, messages can be classified as shown in Table 8 below.

MIH Message Type MIH Message Name MIH Message Type One MIH_Capability_Discover.request Capability discovery 2 MIH_Capability_Discover.response Capability discovery 3 MIH_Capability_Discover.advertisement Capability discovery 4 MIH_Registration.request Registration 5 MIH_Registration.response Registration 6 MIH_Deregistration.request Registration 7 MIH_Deregistration.confirm Registration 8 MIH_Event_Register.request Registration 9 MIH_Event_Register.confirm Registration 10 MIH_Event_Deregister.request Registration 11 MIH_Event_Deregister.confirm Registration 12 MIH_Link_Up.indication Event Service 13 MIH_Link_Down.indication Event Service 14 MIH_Link_Going_Down.indication Event Service 15 MIH_Link_Event_Rollback.indication Event Service 16 MIH_Link_Parameters_Change.indication Event Service 17 MIH_Link_Event_Discover.request Command Service 18 MIH_Link_Event_Discover.confirm Command Service 19 MIH_Network_Address_Information.request Command Service 20 MIH_Network_Address_Information.response Command Service 21 MIH_Handover_Pre-notification.request Command Service 22 MIH_Handover_Pre-notification.response Command Service ..... ..... 23+ Reserved Reserved

2) Length (1 octet): indicates the total length of the entire header including the MIH message.

3) Sequence Number (1 octet): Total count of messages sent

4) IP (1-bit): Indicates whether the IP address included in the header is IPv4 or IPv6. (E.g. 0: IPv4, 1: IPv6)

5) F (1 bit): Indicates whether the message is fragmented. (Eg 0: no fragmentation, 1: fragmentation)

6) Fragmentation Offset (1 octet): If a message is incomplete in one packet, fragmentation indicates how many packets remain before the complete message is constructed.

7) XID (Packet ID: 1 octet): Used to match each request and confirmation message.

8) Source Hardware Type (4-bit): Indicates the hardware type of the side sending this message. (E.g., 0000: IEEE802.3 interface, 0001: IEEE802.11 interface, 0010: IEEE802.16 interface, 0011: 3GPP interface, 0100: 3GPP2 interface, 0101-11111: Reserved)

9) Destination Hardware Type (4-bit): Indicates the hardware type of the receiving party. (E.g., 0000: IEEE802.3 interface, 0001: IEEE802.11 interface, 0010: IEEE802.16 interface, 0011: 3GPP interface, 0100: 3GPP2 interface, 0101-11111: Reserved)

10) Source Hardware Address: Indicates the hardware address (eg, Layer 2 address) of the party sending this message.

11) Source IP Address: indicates the IP address of the sender of this message.

12) Destination Hardware Address: indicates the hardware address (eg, Layer 2 address) of the party receiving this message.

13) Destination IP Address: indicates the IP address of the receiving party.

14) MIH message: This field contains the actual message of the remote event registration, event, service, and command service in the form of a TLV.

FIG. 14 illustrates a message format of a MIH packet according to another preferred embodiment of the present invention. Each field will be described below.

1) Protocol Version: Indicates the version of MIH protocol. The default value is 0x01.

2) MIH Service ID: Identifier of MIH service. (E.g. 1: Event Service, 2: Command Service, 3: Information Service)

3) MIH Opcode: Defines the operation to be executed. (E.g. 1: Request, 2: Response, 3: Indication)

4) Transaction ID: Transaction identifier used to match request message and response message.

5) Fr: Fragmentation Flag (eg 1: Current packet has more than one fragmentation. 0: Current packet is not fragmented.)

6) Fragment No: fragment number of packet

7) Message Length: Total length of all messages

8) MIH Function Identifier Length (MIHFL): Length of each Souce / Destination MIH Identifier field

9) Source MIH Function Identifier: This is an identifier of the sending MIH. It may be a two-layer hardware address or an IP-based three-layer address. It may also be a new MIH address identifier.

10) Destination MIH Function Identifier: This is an identifier of the destination MIH, which may be a two-layer hardware address or an IP-based three-layer address. It may also be a new MIH address identifier.

11) MIH Message ID: The actual MIH message identifier, the contents of which are shown in Table 9.

No MIH Message Identifier
MIH Opcode Category One MIH Event Discover Request, Response Capability discovery 2 MIH Event Register Request, Response Registration 3 MIH Event Deregister Request, Response Registration 4 MIH Link Event Configure Request, Response Event Configuration 5 MIH Link Up Indication Event Service 6 MIH Link Going Down Indication Event Service 7 MIH Link Event Rollback Indication Event Service 8 MIH Link Parameters Change Indication Event Service 9 MIH SDU Transmit Success Indication Event Service 10 MIH SDU Transmit Failure Indication Event Service 11 MIH Command Discover Request, Response Command Service 12 MIH Network Address Information Request, Response Command Service 13 MIH Handover Initiate Request, Response Command Service 14 MIH Handover Prepare Request, Response Command Service 15 MIH Handover Complete Request, Response Command Service 16 MIH Information Request Request Information Service 17 MIH Information Response Response Information Service 18 MIH Capability Discovery Request Request MIH Capability Discovery 19 MIH Capability Discovery Response Response MIH Capability Discovery 20+ Reserved Reserved

12) MIH Message Data: Specific data of MIH service

As described above, the MIH packet may have the form of FIG. 13 or 14.

Signaling messages between MIHs can be classified into 'MIH Capability Discovery', 'MIH Remote Event Registration', 'MIH Remote Event Service' and 'MIH Remote Command Service'.

The mobile terminal or access point (Wireless LAN AP, broadband wireless access network BS, cellular system BS) or network entity (router, foreign agent) is described above to discover the MIH Capability of the counterpart entity (mobile terminal, access point, network entity). The method is classified according to the type of the MIH packet. In the first method, when the MIH packet has the form of FIG. 13, the MIH_Capability_Discovery.request and MIH_Capability_Discovery.response messages are used as follows to discover the MIH capability of the counterpart.

(1) 'MIH Capability Discovery' related message

1) MIH_Capability_Discovery.request

This message does not include the MIH message payload, only the MIH header is sent with the message type set to 1. This message can be delivered through Layer 2 or Layer 3. If the entity sending this message does not know the exact counterpart's address and is trying to find out which entity in the network has MIH capability, it is sent in a broadcast message. In another case, when the object sending this message knows the address of the other object but wants to know whether the object has MIH capability, the message is unicast.

2) MIH_Capability_Discovery.response

The entity receiving the MIH_Capability_Discovery.request message responds to MIH_Capability_Discovery.response if it has MIH capability. This message also does not include the MIH message payload, only the MIH header is sent with the message type set to 1. This message can be delivered through layers 2 or 3. At this time, a destination address in the MIH header is copied and filled with a source address of MIH_Capability_Discover.request, and a source address is filled with its own address. In addition, the entity having the MIH function can periodically advertise its MIH function through the second or third layer.

In the second method, when the MIH packet has the MIH packet form of FIG. 14, only the MIH header may be transmitted to the counterpart entity except for the payload portion of FIG. 14 to discover the MIH Capability of the counterpart entity. At this time, the counterpart entity receiving the header responds by transmitting its own MIH header with reference to the source address field of the received header, if it has MIH Capability.

Thirdly, when the MIH packet has the MIH packet form of FIG. 14, another method may include a counterpart entity including only the MIH header and the MIH Message Identifier excluding the MIH Message Data of FIG. 14 to discover the MIH Capability of the counterpart. Can be sent to. At this time, the transmitted MIH_Capability_Discovery.request and MIH_Capability_Discovery.response are as follows.

1) MIH_Capability_Discovery.request

The MIH Message Identifer is set to MIH_Capability_Discovery.request and sent. This message can be delivered through Layer 2 or Layer 3. If the entity sending this message does not know the exact counterpart's address and is trying to find out which entity in the network has MIH capability, it is sent in a broadcast message. In another case, when the object sending this message knows the address of the other object but wants to know whether the object has MIH capability, the message is unicast.

2) MIH_Capability_Discovery.response

The entity receiving the MIH_Capability_Discovery.request message responds to MIH_Capability_Discovery.response if it has MIH capability. This message can be transmitted by including the parameters in the table below in the MIH message data if available. This message can be delivered through layers 2 or 3. At this time, a destination address in the MIH header is copied and filled with a source address of MIH_Capability_Discover.request, and a source address is filled with its own address. In addition, the entity having the MIH function can periodically advertise its MIH function through the second or third layer.

Name Length Value SupportedEventList 4 For each Bit location, a value of 1 indicates the link event is supported.

Bit # 0: Link Up
Bit # 1: Link Down
Bit # 2: Link Going Down
Bit # 3: Link Detected
Bit # 4: Link Parameters Change
Bit # 5: Link Event Rollback
Bit # 6: Link SDU Transmit Success
Bit # 7: Link SDU Transmit Failure
Bit # 8 ~ 31: Reserved SupportedCommandList 4 For each Bit location, a value of 1 indicates the link command is supported.

Bit # 0: Link Power Up
Bit # 1: Link Power Down
Bit # 2: Link Configure
Bit # 3: Link Connect
Bit # 4: Link Disconnect
Bit # 5: Link Sleep
Bit # 6: Link Scan
Bit # 7: Link Poll
Bit # 8 ~ 31: Reserved

(2) 'MIH Registration' related message

1) MIH_Event_Registration.request

This message is used by the MIH function that wants to register an event service with the remote stack for future delivery.

Name Type (1 byte) Length Value RequestedEventList One If it is set to 1 in the area of each bit, it is a request to register the service.

Bit # 0: Link Up
Bit # 1: Link Down
Bit # 2: Link Going Down
Bit # 3: Link Detected
Bit # 4: Link Parameters Change
Bit # 5: Link Event Rollback
6 ~ 7: Reserved

2) MIH_Event_Registration.confirm

This message returns the result of MIH_Evetn_Registration.request.

Name Type (1 byte) Length Value ResponseEventList One If it is set to 1 in each bit area, the corresponding service is registered successfully.

Bit # 0: Link Up
Bit # 1: Link Down
Bit # 2: Link Going Down
Bit # 3: Link Detected
Bit # 4: Link Parameters Change
Bit # 5: Link Event Rollback
Bit # 6 ~ 7: Reserved

3) MIH_Event_Deregistration.request

This message is sent to unregister the Event Service registered on the remote stack.

Name Type (1 byte) Length Value RequestedEventList One If it is set to 1 in the area of each bit, it is a request to unregister the service.

0: Link Up
1: Link Down
2: Link Going Down
3: Link Detected
4: Link Parameters Change
5: Link Event Rollback
6 ~ 7: Reserved

4) MIH_Event_Deregistration.confirm

This message returns the result of MIH_Event_Deregistration.request.

Name Type (1 byte) Length Value ResponseEventList One For each Bit location, a value of 1 indicates the requested link event is de-registered correctly.

Bit # 0: Link Up
Bit # 1: Link Down
Bit # 2: Link Going Down
Bit # 3: Link Detected
Bit # 4: Link Parameters Change
Bit # 5: Link Event Rollback
6 ~ 7: Reserved

(3) 'MIH Event Service' related message

1) MIH_Link_Up.indication

This message is used by the mobile station or access point to send Link_Up to the remote stack and informs the remote stack that a new link connection has been established. In addition to the mobile terminal or access point, this message can also be passed from any entity supporting the MIH function to any other entity supporting the MIH function.

Name Type (1 byte) Length Value MacMobileTerminal Variable MAC Address MacNewPoA Variable MAC Address of New PoA (AP) MacOldAccessRouter Variable MAC Address of old Access Router (if any) MacNewAccessRoute Variable MAC Address of new Access Router

2) MIH_Link_Down.indication

This message is used by the mobile station or access point to send a Link_Down to the remote stack, informing the remote stack that a new link has been released. In addition to the mobile terminal or access point, this message can also be passed from any entity supporting the MIH function to any other entity supporting the MIH function.

MacMobileTerminal Variable MAC Address MacNewPoA Variable MAC Address of New PoA (AP) MacOldAccessRouter Variable MAC Address of old Access Router (if any) ReasonCode One Reason for why the link went down
0: RC_EXPLICIT_DISCONNECT (
1: RC_PACKET_TIMEOUT
2: RC_FAIL_NORESOURCE
3: 127: Reserved
128-255: RC_VENDOR_SPECIFIC

'ReasonCode' in Table 16 is as follows.

-RC_EXPLICIT_DISCONNECT: The link is down because of explicit disconnect procedures initiated either by client or network

-RC_PACKET_TIMEOUT: The link is down because no acknowledgements were received for transmitted packets within the specified time limit.

-RC_FAIL_NORESOURCE: The link is down because there were no resources to maintain the connection

RC_VENDOR_SPECIFIC: Vendor Specific reason code.

(4) MIH Command Service related message

1) MIH_Network_Address_Information.request

This message is sent to request the IP address information for the new access point from the currently connected access point (AP or BS) before the mobile terminal attempts to handover to another interface network. After receiving this message, if the new access point has address information for Foreign Agent or Access Router, it responds to the current access point of mobile station and does not have address information. If so, forward this message to a new external agent or access router.

Name Type (1 byte) Length Value MacMobileTerminal Variable MAC Address of Mobile Terminal MacAccessRouter Variable MAC Address of Access Router MACNewPoA Variable MAC Address of New PoA Home Address 4 or 6 Home IP address of Mobile Terminal CoA 4 or 6 Care of Address of Mobile Terminal Old FA Address / Old Access Router Address 4 or 6 In case of Mobile IPv4, this parameter represents IP address of old Foreign Agent, and in case of Mobile IPv6, this parameter represents IP address of old Access Router.

2) MIH_Network_Address_Information.response

This message is sent to respond to the IP address information after a new external agent or access router of the mobile station receives MIH_Network_Address_Information.request.

Name Type (1 byte) Length Value MacMobileTerminal Variable MAC Address of Mobile Terminal MacAccessRouter Variable MAC Address of Access Router MACNewPoA Variable MAC Address of New PoA Home Address 4 or 6 Home IP address of Mobile Terminal FA Address / Access Router Address 4 or 6 In case of Mobile IPv4, this parameter represents IP address of Foreign Agent, and in case of Mobile IPv6, this parameter represents IP address of Access Router. Network Address Information Variable In case of Mobile IPv4, Agent Advertisement is encapsulated and in case of Mobile IPv6, Router Advertisement is encapsulated.

FIG. 15 is a flowchart illustrating an exemplary embodiment of the present invention, in which a mobile station discovers an object supporting a media independent handover function (MIHF) among objects in a network by broadcasting a MIH_Capability_Discover, request / response message. Yes.

(1) The mobile terminal broadcasts MIH_Capability_Discover.request to find an entity supporting MIHF among the entities of the network using the L2 layer. The broadcast method may be divided into two methods: a method through a second layer and a method using a third layer. In the method using the second layer, 'Destination Hardware Address' of the packet format of FIG. 13 is transmitted as 'broadcast', and 'Destination Address' of the second layer is also transmitted as 'broadcast'. At this time, a new 'Ethertype', which is a separator for distinguishing the MIH, is included in the second layer message header to distinguish the MIH message. In the method using the third layer, 'Destination IP Address' of the packet format of FIG. 13 is transmitted as 'broadcast'. In this case, in order to distinguish the MIH message from the third layer, for example, the IP layer, the protocol layer is newly defined as the MIH type to distinguish the MIH message.

(2) The mobile terminal sets a timer while delivering MIH_Capability_Discover.request. When the timer does not receive a MIH_Capability_Discover.response response to the MIH_Capability_Discover.request delivered during the timer operation period, the unicast object transmits the message, and the entity that supports MIHF to the broadcast area. It is used to judge that there is no. When the message delivered by the mobile terminal is delivered through broadcast on the second layer, the PoA broadcasts on the second layer link of the PoA.

(3) When a message delivered by a mobile terminal is broadcast through the third layer, the PoA receives the message and broadcasts the message to a specific layer (broadcast to a specific subnet, broadcast to the entire area, etc.). And broadcast by the third layer. PoA3 does not receive MIH message because it does not have MIHF function. Therefore, the MIH_Capability_Discover.request is not received and the response cannot be received (4). On the other hand, the PoA2 with the MIHF and the access router / external agent receive it and respond with the MIH_Capability_Discover.response (5). The terminal sees the address of this response and finds it by the entity supporting MIHF. It can inform the upper management entity, and the MIHF saves it for future handover.

FIG. 16 is a flowchart illustrating another exemplary embodiment of the present invention, in which an object supporting Media Independent Handover Function (MIHF) is found among objects in a network initialized by Point of Attachment 1 (FIG. 1). FIG. .

FIG. 17 is a flowchart illustrating another exemplary embodiment of the present invention, showing a case in which the 'MIHF capability' discovery method fails.

(1) The mobile station transmits MIH_Capability_Discover.request to find out whether PoA3 supports MIHF with the address of PoA3 already known. (2) The mobile terminal drives the timer while sending this message. (3) PoA1 sees the destination address of received MIH_Capability_Discover.request and delivers this message to PoA3. (4) This message is sent to PoA3. For the MIH message used in the transfer of the above (1) and (4), the MIH packet format of is used. (5) PoA3 does not receive this MIH packet because it does not have MIHF and cannot respond to it. (6) The timer driven by the mobile terminal sending MIH_Capability_Discover.request expires and the mobile terminal finds that PoA3 does not support MIHF.

FIG. 18 is a flowchart illustrating still another preferred embodiment of the present invention, showing an example of a successful 'MIHF capability' discovery method.

Procedures (1) to (4) are similar to FIG. Since PoA2 supports MIHF, it can receive MIH_Capability_Discover.request transmitted by the mobile terminal (4) and transmit MIH_Capability_Discover.response (5). Since the mobile terminal receives a response before the timer driven while transmitting the message expires, it can find that the PoA2 supports MIHF.

Fig. 19 is a flowchart of another preferred embodiment of the present invention, showing a procedure of discovering whether a counterpart node of communication supports MIHF through the third layer (e.g., IP layer).

The mobile terminal transmits MIH_Capability_Discover.request to the IP address found when establishing the communication connection with the counterpart node (1). The mobile terminal starts a timer when sending a message (2). The receiving node can receive this message because it supports MIHF and transmits MIH_Capability_Discover.response (3). Since the response message arrived before the timer expired, the mobile terminal can find out that the other node supports MIHF.

It will be apparent to those skilled in the art that the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

In the multi-mode mobile terminal to perform the medium handover through the present invention,

First, for MIH communication between the mobile station's MIH and the base station or the AP's MIH and the network entity (base station, AP, or access router) having the MIH function, the MIH protocol and the MIH message format proposed by the present invention are used. More clear and clear communication between MIHs can be achieved.

Second, in order to discover MIH Capability of counterpart node and network entities, or to discover 'MIH Capability' of counterpart between network entities, the multimode mobile terminal can recognize it using the message and header proposed in the present invention. have.

Claims (17)

A method of discovering the capability of at least one network entity that supports Intermediate Independent Handover Function (MIHF) in a wireless mobile communication network, A mobile station (MS) discovers whether the at least one network entity supports the MIHF and among the at least one or more network entities supports at least one intermediary independent handover (MIH) supported by the network entity supporting the MIHF. Sending a MIH request message from the mobile station to the at least one or more network entities including a source identifier field and a destination identifier field to discover a service; And The mobile station receiving at least one MIH response message responsive to the MIH request message from only the network entity supporting the MIHF among the at least one network entity receiving the MIH request message; Discovering whether the at least one network entity supports the MIHF and discovering at least one intermediary independent handover (MIH) service supported by the network entity supporting the MIHF among the at least one or more network entities; Carried out by the same MIH request message, wherein the destination identifier field of the MIH request message includes a destination MIHF identifier, The at least one MIH response message includes a source identifier field having an identifier of a network entity supporting the MIHF, a destination identifier field, and at least one service list field representing a list of services supported by the network entity supporting the MIHF. Include, The MIHF is interfaced with an upper layer above the third layer and a lower layer below the third layer, and the mobile station supports two or more network interface types for each of the lower layers. Wherein the MIHF is configured to provide the MIH service to the mobile station using the MIH request message and the MIH response message, wherein the MIH includes a handover between two network entities independent of a network interface type. To discover the capabilities of a MIHF-enabled network object. The method of claim 1, The at least one network entity comprises at least one or more of a base station (BS), an access point or a point of access. The method of claim 1, And the MIHF provides the mediator independent handover using information from at least one or more network interfaces for at least one of homogeneous and heterogeneous network entities. The method of claim 1, Wherein the at least one service list field indicates at least one MIH service list supported by a network entity supporting the MIH. The method of claim 1, And the MIH request message and the MIH response message are one of a second layer message or a third layer message. The method of claim 1, And the at least one network entity comprises at least one or more of a wired broadband interface, a wireless broadband interface, and a cellular interface. The method of claim 1, The destination MIHF identifier together finds an identifier of a network entity supporting the MIHF among the at least one or more network entities and the at least one MIH service supported by the network entity supporting the MIHF among the at least one or more network entities. A method for discovering the capabilities of a MIHF-supported network object, which is an identifier used to make a request. The method of claim 1, Using the source identifier and the at least one service list field of the MIH response message, an identifier of the at least one MIHF supporting network entity and at least one MIH service supported by the at least one MIHF supporting network entity, respectively. The method of claim 1, further comprising the step of discovering. delete The method of claim 1, The network entity supporting the MIHF among the at least one network entity includes at least one or more of a base station, an access point, or a point of access. The method of claim 1, Driving a timer when the MIH request message is transmitted, And the MIHF is configured to determine whether the MIH response message is received before expiration of the timer. The method of claim 4, wherein Wherein the at least one MIH service list comprises a command service (CS) list, an event service (ES) list, and an information service (IS) list. The method of claim 5, And wherein the second layer message is an Ethernet message. The method of claim 5, And said third layer message is an Internet Protocol (IP) message. A device for discovering the capability of at least one network entity that supports Intermediate Independent Handover Function (MIHF) in a wireless mobile communication network. An upper management entity controlling the upper layer of the third layer or more; A multi-mode node supporting at least two network interface types for each lower layer below the third layer; And And a MIHF entity interfaced with the upper layer and the lower layer and configured to provide a medium independent handover (MIH) service using a medium independent handover (MIH) message, The apparatus comprises: To discover whether the at least one network entity supports the MIHF and to discover at least one intermediary independent handover (MIH) service supported by the network entity supporting the MIHF among the at least one or more network entities, Send a MIH request message comprising a source identifier field and a destination identifier field to the at least one network entity; Is configured to receive at least one MIH response message responsive to the MIH request message from only the network entity supporting the MIHF among the at least one network entity receiving the MIH request message, Discovering whether the at least one network entity supports the MIHF and discovering at least one intermediary independent handover (MIH) service supported by the network entity supporting the MIHF among the at least one or more network entities; Carried out by the same MIH request message, wherein the destination identifier field of the MIH request message includes a destination MIHF identifier, The at least one MIH response message includes a source identifier field having an identifier of a network entity supporting the MIHF, a destination identifier field, and at least one service list field representing a list of services supported by the network entity supporting the MIHF. Include, And the MIH comprises a handover between two network entities irrespective of the network interface type. The method of claim 15, And the apparatus is one of a mobile station (MS), a mobile terminal, a mobile subscriber station (MSS), a mobile node, or a terminal. The method of claim 15, The MIHF entity controls a timer, the timer is driven when the MIH request message is sent, and the MIHF entity determines whether the MIH response message is received before expiration of the timer. Ability discovery device.

Images