8. 	Media Independent Handover Protocol
8.1 	Introduction
The IEEE 802.21 standard specifies MIH Function that could be used in mobile nodes and also in entities located in the network. The MIH Functions in MN and network entities communicate with each other to using the MIH protocol messages specified in this section. The MIH protocol allows any peer MIH Function entities to communicate with each other. The MIH protocol defines message formats for exchanging these messages between peer MIH Function entities. These messages are based on the primitives which are part of the MIH Services. 
The peer MIH Function entities must complete service management procedures described in clause 6 before initiating MIH protocol procedures. The service management procedures include MIH Function discovery, MIH capability discovery and MIH registration. 
8.2 	MIH Protocol Description
The Media Independent Handover protocol provides the following services: 
1)		MIH Function discovery (Layer 2 only): The peer MIHF in a mobile node discovers which entity in the access network provides MIHF services. 
2)		MIH capability discovery: The MIHF entity in MN discovers the capabilities of a peer MIHF entity in the network. This includes a list of supported events, a list of supported commands and supported query types for the Information Service.
3)		MIH registration: Peer MIHFs may register with each other to establish a new MIHF pairing. 
4)		MIH event subscription: MIH Function may subscribe to a particular set of remote events.
5)		MIH message exchanges: Peer MIHFs may exchange MIH IS, ES and CS protocol messages over a suitable transport.
8.2.1 	MIH Protocol Acknowledgement Operation
MIH protocol messages require reliability to ensure the receipt of data by the intended destination. Reliability may be provisioned with the optional acknowledgement mechanism as part of the MIH protocol. The acknowledgement mechanism is particularly useful when the underlying transport used for remote communication does not provide reliable services. When the MIH transport is reliable, the acknowledgement mechanism may not be used. 
The source MIHF may optionally request for an acknowledgement message (MIH ACK) to ensure successful receipt of an MIH protocol message. The MIH ACK message is used to acknowledge the successful receipt of a MIH protocol message at the destination MIHF. The source MIHF, when requesting for acknowledgement service, receives the MIH ACK message when the MIH protocol message is reliably delivered to the destination MIHF. If the MIH protocol message or the MIH ACK message is lost, the ACK timer on the source MIHF shall expire and the source MIHF shall subsequently retransmit the same MIH protocol message.
The MIH acknowledgement capability is supported by the use of two bits of information that are defined exclusively for ACK usage in the MIH header. The ACK-Req bit is set by the source MIH node and the ACK-Rsp bit is set by the destination MIH node to utilize the acknowledgement service. It is expected that the underlying transport layer would take care of ensuring the integrity of the MIH protocol message during delivery.
When seeking acknowledgement service, the source MIH node shall start a timer at the time of sending an MIH protocol message with the ACK-Req bit set in the MIH header and shall save a copy of the MIH protocol message while the timer is active. The value of the timer should be configured to allow for reasonable delays for round trip transport between the two nodes and for message processing. If the acknowledgement message is not received before the expiration of the timer, the source MIH node may immediately retransmit the saved message with the same Message-ID and with the same Transaction-ID (with ACK-Req bit set). If the source MIH node receives the acknowledgement before the expiration of the timer on the first or any subsequent retransmitted attempt, then the source MIH node has ensured the receipt of the MIH packet and therefore, may reset the timer and release the saved copy of the MIH protocol message. During retransmission, if the source MIH node receives the ACK for any of the previous transmission attempts then the source MIH node may determine successful delivery of the message and may not have to wait for any further acknowledgements for the current message. The source MIH node may at most make two retransmission attempts in addition to the first attempt for an MIH protocol message with the same Message-ID and the same Transaction-ID. The source MIH node shall not attempt to retransmit a message with same Message-ID and Transaction-ID when the ACK-Req bit was not set in the first MIH message. 
When a destination MIH node receives an MIH protocol message with the ACK-Req bit set, then the destination MIH node returns an MIH ACK message with the ACK-Rsp bit set and copying the Message-ID and Transaction-ID from the received MIH protocol message. The MIH ACK message may,have only the MIH header and no other payload. In instances where the destination MIH node may immediately process the received MIH protocol message and a response is immediately available, then the ACK-Rsp bit may be set in the corresponding MIH protocol response message. The destination MIH node may choose to save the received MIH protocol message header to correlate with any other retransmitted message(s) containing the same Message-ID and Transaction-ID to avoid duplicate processing of the same MIH protocol message. The time duration of this buffer may depend on the delay estimate of the round trip transport between the two nodes. If a duplicate message is received, due to the source retransmitting the same message during this time period, the destination MIH node shall respond with an acknowledgement message even though an acknowledgement message may have been sent earlier for the same MIH message. This is to safeguard against the cases wherein the first acknowledgement message may have been lost and not received by the source MIH node. However, the destination MIH node shall not process this duplicate retransmitted message if it has already done so. If a destination MIH node receives an MIH protocol message with no ACK-Req bit set then no action is taken with respect to the acknowledgement functionality. As an alternative to a timer based window algorithm, the implementation could use a transaction count based window as well. In all cases, the MIH protocol message in a transaction shall be processed only once at the destination MIH node, irrespective of the number of ACK messages received. The destination MIH node may set the ACK-Rsp bit in an MIH protocol response message and may additionally request acknowledgement by setting the ACK-Req bit for the same MIH protocol response message.
8.2.2 	MIH protocol transaction state diagram
This clause describes the state diagram for an MIH transaction identified by a sequence of messages with the same Transaction-ID. For brevity, some events causing transitions from intermediate states to INIT state due to error conditions or time-out are omitted. Following conventions are used for the diagrams: 
•		Each state name represents the node's current state in an MIH transaction. State transitions from one state to another are labeled in the format “Event/Action”. The “Event” is a reason that triggered the state transition and the “Action” is performed in the current state before transitioning to the next state. 
•		The following abbreviations are used: Recv (Received), REQ (MIH Request Message), RSP (MIH Response Message), IND (MIH Indication), ACK (MIH Acknowledgement message), ACK-Req (Acknowledgement Request bit), and ACK-Rsp (Acknowledgement Response bit).
•		Retransmission timers are started when entering a state that has a retransmission loop and stops when transitioning to the next state. Transaction timer operation on the other hand, is implementation specific. It may start at the beginning of the transaction or at a later state.
8.2.2.1 	State machine for MIH request source node
 Figure 22 illustrates the MIH transaction on the source node that originates a MIH request related to MIH information or command services.

Figure 22—	State machine for MIH request source node
State INIT is the initial state. If an MIH Request is sent without the ACK-Req bit set, the request source node transits to SENT state. If an MIH request is sent with the ACK-Req bit set, the request source node transits to SENDING state and waits for an MIH ACK message. If an MIH ACK message is received, the request source node will transit to SENT state. Otherwise, the request source node may retransmit (maximum 2 times) the MIH Request when the retransmission time-out occurs.
When the source node is in either SENDING or SENT state, if an MIH Response is received, the source node transits to COMPLETED state. If the MIH Response has the ACK-Req bit set, the source node shall act also as a destination node and respond with an MIH ACK message. On the other hand, if the received response does not have the ACK-Req bit set, no action is taken. The source node may stay in COMPLETED state, when the ACK was requested for the MIH Response message, for a specific time to ensure that if a retransmitted MIH Response is received due to a lot MIH ACK; an MIH ACK message can be retrasnsmitted. Once the transaction time-out occurs, the source node transits to INIT state and resets the transaction.
8.2.2.2 	State machine for MIH request destination node
 Figure 23 illustrates the MIH transaction on the destination node that receives and processes the MIH request message
.
Figure 23—	State machine for MIH request destination node
When an MIH Request message is received, the destination node transits from the initial state INIT to the RECEIVED state. If the MIH Request message does not have an ACK-Req bit set, then no action is taken. If the MIH Request message has the ACK-Req bit set and the response is not immediately available, the destination node sends an ACK message with ACK-Rsp bit set. 
If the MIH Request message has the ACK-Req bit set and the response is immediately available, the destination node transits from the RECEIVING state to either RESPONDING or COMPLETED state by sending the appropriate MIH Response message with ACK-Rsp bit set.
In the RECEIVED state, if a retransmitted MIH Request with ACK-Req set is received, the request destination node shall respond with an ACK message. When response is already available, the destination node shall send the MIH Response message with Ack-Rsp bit set. If the MIH Response is sent with the ACK-Req bit set, the request destination node transits to the RESPONDING state and wait for an acknowledgement message. If an acknowledgement message is not received for a period of time, i.e., retransmission time-out occurs, the destination node may retransmit (maximum 2 times) the MIH Response message. Once an acknowledgement message is received, then the destination node transits to INIT state and resets the transaction. 
If the response is sent without the ACK-Req bit set, the destination node transits to the COMPLETED state and waits for a specific time to ensure that if a retransmitted request message is received; the response can be retransmitted. Once the transaction time-out occurs, it transits to INIT state and resets the transaction. 
8.2.2.3 	State machine for MIH indication source node
 Figure 24 illustrates the state transitions for an MIH indication source node originating MIH event service messages.
State INIT is the initial state. If an MIH Indication message is sent without the ACK-Req bit set, the indication source node stays in INIT state and resets the transaction.
 If an MIH Indication message is sent with the ACK-Req bit set, the indication source node transits to SENT state and waits for an MIH ACK message. If an MIH ACK message is received, the source node transits to INIT state and reset the transaction.

Figure 24—	State machine for MIH indication source node
If an acknowledgment message is not received after a specific amount of time, it may retransmit (maximum 2 times) the same MIH indication by remaining in the SENT state. If an acknowledgment message is received before the transaction time-out occurs, the source node transits to INIT state and resets the transaction.
8.2.2.4 	State machine for MIH indication destination node
 Figure 25 illustrates the state transitions for an MIH indication destination node receiving MIH event service messages.

Figure 25—	State machine for MIH indication destination node
State INIT is the initial state. If an MIH Indication without ACK-Req bit set is received, the destination node remains in INIT state and resets the transaction. 
If an MIH Indication is received with the ACK-Req bit set, the destination node sends an ACK message and transits to RECEIVED state. When the same indication is received due to retransmissions in the RECEIVED state, the destination node shall respond with another ACK message. Once transaction time-out occurs, the destination node transits to INIT state and resets the transaction. 
8.2.3 	Other considerations
8.2.3.1 	MIH protocol transport
 Table 14 shows the various transport options for different media types (see Annex J for requirements on L3 transport).
Table 14—	Transport options for MIH protocol	

Media type	
L2 Transport description	
L3 Transport description	

Ethernet	
Data Frames	
IP based	
IEEE 802.11	
Data Frames, Management Frames	
IP based	
IEEE 802.16	
Data Frames, Management Frames	
IP based	

3GPP	
Not Applicable. Requires protocol stack changes	
IP based	

3GPP2	
Not Applicable. Requires protocol stack changes	
IP based	

8.2.3.2 	MIH protocol congestion control considerations
Congestion and flow control within the MIH protocol layer is not needed if it is already provided by the underlying transport protocol.
When the underlying transport does not provide any congestion control, then MIH may implement these congestion control functions. One way to do this is by setting a retransmission timer for an MIH message based on the algorithm defined in IETF RFC 2988. Similarly when flow control is provided by the MIH due to lack such feature in the transport protocol, a single rate limiter applies to all traffic (for all interfaces and message types). It applies to retransmissions, as well as new messages, although an implementation may choose to prioritize one over the other. When the rate limiter is in effect, MIH messages are queued until transmission is re-enabled, or an error condition may be indicated back to local signaling applications. The rate limiting mechanism is implementation specific, but it is recommended that a token bucket limiter as described in IETF RFC 4443 be used. 
When an MIHF suffers from overload, it may drop requests from MIH requestors, and may differentiate between requestors to implement selective dropping. For example, messages could be dropped from a particular requestor if that requestor could be established as the origin of a DoS attack. An MIHF may not drop a message if it was delivered reliably by the transport (L2 or L3). Any reliable delivery function may be able to indicate a flow control back to the requestor, and an MIHF may invoke flow control towards a specific requestor when overloaded with reliably delivered messages.
8.2.3.3 	Reliability
MIH protocol messages are delivered via media-dependent transport. The MIH Function determines the transport reliability provided to the MIH user. However, the MIH user may provide its preference to the MIH Function. How the preference is communicated to the MIHF depends on the implementation and is outside the scope of this standard. If the MIHF uses unreliable transport and a reliable message delivery is required, the MIH protocol ACK operation shall be applied for transmitting the message. If the MIHF uses reliable transport, then the MIH protocol ACK operation should not be required for transmitting the message.
8.2.3.4 	Fragmentation
In all cases, the MIH protocol relies on the underlying transport mechanism to provide fragmentation and reassembly services. If the underlying transport mechanism in use does not provide these services, implementation specific procedures may be provided.
8.2.3.5 	Combined MIH function discovery and capability discovery at layer 2
As stated in 6.1.2, MIHF Discovery can be implicitly performed using the MIH Capability Discovery at layer 2 when both MIHFs are residing within the same broadcast domain. The following subclauses refer to the MIH Capability Discovery both as a means to discover the MIHF and its capabilities.
8.2.3.5.1 	Unsolicited MIH capability discovery
An MIHF may discover its peer entities and their capabilities either by listening to media-specific broadcast messages or media-independent MIH capability broadcast message, if available. 
For example, by listening to a media-specific broadcast message such as a beacon in IEEE 802.11 or a DCD in IEEE 802.16, an MIHF on an MN can discover whether an access network is MIH capable. 
8.2.3.5.2 	Solicited MIH capability discovery
An MIHF (the requestor) may choose to discover its peer MIH functions and their capability by broadcasting or unicasting an MIH_Capability_Discover request message to either its broadcast domain or a known PoA address, respectively. MN shall respond to capability discovery requests from Network MIHF only.
In this case, a layer 2 data frame with MIH ethertype shall be used for the broadcasting. When a peer MIH function (the responder) receives the MIH_Capability_Discover request message, it shall unicast an MIH_Capability_Discover response message back to the requestor. The response shall be sent using the same transport over which the request message was received. When the requestor receives the unicast MIH_Capability_Discover response message, it learns the responder’s address by checking the layer 2 source address.
For complete operation, the requestor may set a timer at the time of sending an MIH_Capability_Discover request during which time the requestor is in waiting state for a response from the responder. When the response message is received while the timer is running, the requestor stops the timer and finishes the MIH function and capability discovery procedure. When the timer expires without receiving a response message, the requestor may try the combined MIH function discovery and capability discovery procedure using a different transport than previous or terminate the MIH function and capability discovery procedure. 
8.3 	MIH protocol identifiers
Following identifiers are used in MIH protocol messages:
—		MIHF ID
—		Subscription ID
—		Transaction ID
8.3.1 	MIHF ID
MIHF Identifier (MIHF ID) is an identifier that is required to uniquely identify MIHF end points for delivering the MIH services. MIHF ID is used during MIH registration and in all messages that are required to identify the end points. Use of MIHF ID also enables the MIH protocol to be transport agnostic. MIHF ID may be assigned to the MIHF during its configuration process. 
As described in earlier clauses, MIH registration enables two MIH entities to create an MIH pairing based on the policies configured in the MN or based on the information acquired from the capability discovery. MIH network entities may not be able to provide any MIH services to the MN without prior MIH Registration. 
The MIHF ID is of type MIHF_ID (See Annex C.2.8).
8.3.2 	Subscription ID
Subscription Identifier (Subscription ID) is assigned during a remote event subscription. Each remote subscription needs to be associated with a Subscription ID that keeps the event subscription information mapping for particular event service.
The Subscription ID is of type SUBSCRIPTION_ID (See Annex C.2.9).
8.3.3 	Transaction ID
Transaction Identifier (Transaction ID) is an identifier that is used to match a request message with its corresponding response. This identifier is also required to match each request, response or indication message and its corresponding acknowledgment. This identifier shall be created at the node initiating the transaction and it is carried over within the fixed header part of the MIHF frame. In messages where Transaction ID is not used it is set to 0.
Transaction ID Value:
Transaction ID is a 16 bit long identifier that is unique among all the pending transactions between a given pair of the sender and receiver. For example, this could be an integer that starts from zero (0) and incremented by one (1)(modulo 2^16) every time a new Transaction ID is generated.
8.4 	MIH protocol frame format
8.4.1 	General frame format
In MIH protocol messages, all TLV definitions are always aligned on an octet boundary and hence no padding is required.
 Figure 26 shows the components of the MIH protocol frame.

Figure 26 —  	MIH protocol general frame format
8.4.1.1 	MIH protocol header fields
The MIH protocol header consists of two parts; one with fixed length and another with variable length. The fixed length part of the header carries the essential information which is present in every frame and is important for parsing and analyzing the MIH protocol frame. The variable length part of the header carries information which includes both mandatory and optional TLVs.
 
Figure 27 —  	MIH protocol header format
In the MIH protocol frame, the mandatory portion of TLVs in the MIH protocol header shall be present before any MIH payload TLVs.
8.4.1.1.1 	Fixed header fields
The fixed part of the header content is mandatory.  Table 15 shows the description of the fixed fields.
Table 15—	Description of the fixed fields in MIH protocol header	
Field name	Size (bits)	Description	
Version	4	This field is used to specify the version of MIH protocol used. 
0: Not to be used
1: The current version
2 - 15: (Reserved)	
ACK-Req	1	This field is used for requesting an acknowledgement for the message.	
ACK-Rsp	1	This field is used for responding to the request for an acknowledgement for the message.	
Unauthenticated Information Request (UIR)	1	This field is used to indicate if the protocol message is sent pre-authentication/pre-association so that the length of the response message can be limited.	
Reserved	9	This field is intentionally kept reserved. When not used, all the bits of this field are to be set to '0'.	
MIH Message ID (MID)

-- Service Identifier (SID)

-- Operation Code (Opcode)

-- Action Identifier (AID)	16

4

2

10	Combination of the following 3 fields.

Identifies the different MIH services, possible values are:
1: Service Management
2: Event Service
3: Command Service
4: Information Service

Type of operation to be performed with respect to the SID, possible values are:
1: Request
2: Response
3: Indication

This indicates the action to be taken w.r.t. the SID.	
Transaction ID	16	This field is used for matching Request and Response, as well as matching Request, Response and Indication to an ACK.	
Variable Load Length	16	Indicates the total length of the variable load embedded in this MIH protocol frame, including the length of any optional fields in the MIH protocol header and the length of the MIH protocol payload. The length of the fixed fields in the MIH protocol header is NOT included.	

Variable header fields
MIH protocol header may contain variable fields encoded in TLV format as shown in  Figure 28.
Figure 28 —  	MIH protocol header optional field format
8.5 	Message parameter TLV encoding
The following TLV encoding shall be used for parameters in MIH Protocol Messages. The Type field shall be one octet. The format of the Length field shall be per the “definite form” of ITU-T X.690 [31]. 
Specifically, if the actual length of the Value field is less than or equal to 127 octets, then:
—		The Length field shall occupy one octet
—		The MSB of the Length field shall be set to 0, and
—		The other 7 bits of the Length field shall be used to indicate the actual length of the Value field in octets.
If the length of the Value field is exactly 128 octets, then:
—		The Length field shall occupy one octet
—		The MSB of the Length field shall be set to the value '1', and
—		The other seven bits of the Length field shall all be set to the value '0'.
If the length of the Value field is more than 128 octets, then:
—		The Length field shall occupy more than one octet
—		The MSB of the first octet of the Length field shall be set to 1.
—		The other 7 bits of the first octet of the Length field shall be used to indicate the number of additional octets of the Length field (i.e., excluding the first octet), and
—		The value of the remaining octets (i.e., excluding the first octet) of the Length field, when added to 128, shall be used to indicate the actual length of the Value field in octets.
TLV Type values shall be unique. The TLV encoding starts at 1 and any subsequent values are assigned in ascending order. 
8.6 	MIH protocol messages
This subclause specifies different MIH protocol messages in TLV form. The shaded areas represent the MIH protocol header (including both fixed and optional header fields), while the unshaded areas represent the MIH protocol payload. The payload consists of a set of identifiers in TLV form. 
All MIH messages carry MIHF ID TLVs for the Source and Destination Identifiers in the MIHF Variable Header part of the message.
8.6.1 	MIH messages for service management
8.6.1.1 	MIH_Capability_Discover request
If a requesting MIHF entity does not know the destination MIHF entity’s address, the requesting MIHF entity fills its source address field only and may broadcast this message. If a requesting MIHF entity knows the address of the destination entity but if it does not know whether the destination entity is MIHF capable, this message is delivered to the destination entity in a unicast manner. 
This message may contain the SupportedMihEventList, SupportedMihCommandList, SupportedISQueryTypeList and SupportedTransportList TLVs to enable  the receiving MIHF to recognize the sending MIHF's capability. Therefore, peer MIHF entities can recognize each other's MIH capability by one MIH protocol message transaction.
MIH Header Fixed Fields (SID=1, Opcode=1, AID=1)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SupportedMihEventList
(MIH Event List TLV)	
SupportedMihCommandList
(MIH Command List TLV)	
SupportedISQueryTypeList
(MIIS Query Type List TLV)	
SupportedTransportList
(Transport Option List TLV)	

8.6.1.2 	MIH_Capability_Discover response
This message may contain SupportedMihEventList, SupportedMihCommandList, SupportedISQueryTypeList and SupportedTransportList in the MIH message data. Only an MIHF capable entity may receive the MIH_Capability_Discover response. Upon reception of an MIH_Capability_Discover request, the MIH_Capability_Discover response is transmitted. Destination addresses are copied from the MIH_Capability_Discover request and source addresses are filled with their addresses. An entity with an MIHF may also broadcast unsolicited MIH_Capability_Discover response message to advertise its MIH capability. 
MIH Header Fixed Fields (SID=1, Opcode=2, AID=1)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SupportedMihEventList
(List of Network Type and Events TLV)	
SupportedMihCommandList
(MIH Command List TLV)	
SupportedISQueryTypeList
(MIIS Query Type List TLV)	
SupportedTransportList
(Transport Option List TLV)	
LinkMACs
(Link MACs TLV)	
MBBHandoverSupport
(MBB Handover Support TLV)	
Status
(Status TLV)	

8.6.1.3 	MIH_Register request
This message is transmitted to the remote MIHF to perform a registration or re-registration.
MIH Header Fixed Fields (SID=1, Opcode=1, AID=2)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
RequestCode
(Register Request Code TLV)	

8.6.1.4 	MIH_Register response
This message is sent in response to a registration or re-registration request.
MIH Header Fixed Fields (SID=1, Opcode=2, AID=2)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
ValidTimeInterval
(Valid Time Interval TLV)	
Status
(Status TLV)	

8.6.1.5 	MIH_DeRegister request
This message is transmitted to the remote MIHF to request a de-registration. There is no parameter for this message.
MIH Header Fixed Fields (SID=1, Opcode=1, AID=3)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	

8.6.1.6 	MIH_DeRegister response
This message is sent in response to a de-registration request.
MIH Header Fixed Fields (SID=1, Opcode=2, AID=3)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
Status
(Status TLV)	

8.6.1.7 	MIH_Event_Subscribe request
This message is sent by a remote MIHF (the subscriber) to subscribe to one or more event types from a particular event origination point.
MIH Header Fixed Fields (SID=1, Opcode=1, AID=4)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
RequestedMihEventList
(MIH Event List TLV)	

8.6.1.8 	
8.6.1.8 	MIH_Event_Subscribe response
The response indicates which of the event types were successfully subscribed.
MIH Header Fixed Fields (SID=1, Opcode=2, AID=4)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
ResponseMihEventList
(MIH Event List TLV)	
Status
(Status TLV)	

8.6.1.9 	
8.6.1.9 	MIH_Event_Unsubscribe request
This message is sent by a remote MIHF (the subscriber) to unsubscribe from a set of link layer events.
MIH Header Fixed Fields (SID=1, Opcode=1, AID=5)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
RequestedMihEventList
(MIH Event List TLV)	

8.6.1.10 	MIH_Event_Unsubscribe response
The response indicates which of the event types were successfully unsubscribed.
MIH Header Fixed Fields (SID=1, Opcode=2, AID=5)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
ResponseMihEventList
(MIH Event List TLV)	
Status
(Status TLV)	

8.6.2 	MIH messages for event service 
8.6.2.1 	MIH_Link_Up indication
This notification is delivered from an MIHF, when present in the PoA, to an MIHF in the network when a layer 2 connection is successfully established with a mobile node.
MIH Header Fixed Fields (SID=2, Opcode=3, AID=1)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
MacOldAccessRouter (optional)
(MAC Old Access Router TLV)	
MacNewAccessRouter (optional)
(MAC New Access Router TLV)	
IPRenewalFlag (optional)
(IP Renewal Flag TLV)	
MobilityManagementSupport (optional)
(Mobility Management Support TLV)	

8.6.2.2 	MIH_Link_Down indication 
This notification is delivered from an MIHF, when present in the PoA, to an MIHF in the network when a layer 2 connection with a mobile node is disconnected due to a certain reason. 
MIH Header Fixed Fields (SID=2, Opcode=3, AID=2)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
MacOldAccessRouter (optional)
(MAC Old Access Router TLV)	
ReasonCode
(Link Down Reason Code TLV)	

8.6.2.3 	MIH_Link_Going_Down indication
This message is transmitted to the remote MIHF when a layer 2 connectivity is expected (predicted) to go down within a certain time interval.
MIH Header Fixed Fields (SID=2, Opcode=3, AID=3)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
TimeInterval
(Time Interval TLV)	
ConfidenceLevel
(Confidence Level TLV)	
LinkGoingDownReason
(Link Going Down Reason TLV)	
UniqueEventIdentifier
(Unique Event Identifier TLV)	

8.6.2.4 	MIH_Link_Event_Rollback indication
This message is used in conjunction with Link_Going_Down. If the link is no longer expected to go down in the specified time interval, a Link_Event_Rollback message is sent to the remote Event destination.
MIH Header Fixed Fields (SID=2, Opcode=3, AID=6)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
UniqueEventIdentifier
(Unique Event Identifier TLV)	

8.6.2.5 	MIH_Link_Detected indication
This message is transmitted to the remote MIHF when a new link has been detected.
MIH Header Fixed Fields (SID=2, Opcode=3, AID=4)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
MIHCapability
(MIH Capability Flag TLV)	

8.6.2.6 	MIH_Link_Parameters_Report indication
This message indicates changes in link parameters that have crossed pre-configured threshold levels.
MIH Header Fixed Fields (SID=2, Opcode=3, AID=5)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
LinkParametersStatusList
(Link Parameter Report ListTLV)	

8.6.2.7 	MIH_Link_Handover_Imminent indication
This message indicates that a link layer handover decision has been made and its execution is imminent.
MIH Header Fixed Fields (SID=2, Opcode=3, AID=7)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
OldLinkIdentifier
(Link Identifier TLV)	
NewLinkIdentifier
(New Link Identifier TLV)	
HandoverType
(Handover Type TLV)	
MacOldAccessRouter (optional)
(MAC Old Access Router TLV)	
MacNewAccessRouter (optional)
(MAC New Access Router TLV)	

8.6.2.8 	MIH_Link_Handover_Complete indication
This message indicates that a link layer handover has been completed.
MIH Header Fixed Fields (SID=2, Opcode=3, AID=8)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SubscriptionIdentifier
(Subscription ID TLV)	
OldLinkIdentifier
(Link Identifier TLV)	
NewLinkIdentifier
(New Link Identifier TLV)	
MacOldAccessRouter
(MAC Old Access Router TLV)	
MacNewAccessRouter
(MAC New Access Router TLV)	

8.6.3 	MIH messages for command service 
8.6.3.1 	MIH_Get_Link_Parameters request 
This message is used to discover the status of currently available links.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=1)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
DeviceStatesRequest (optional)
(Device Status Request TLV)	
LinkIdentifierList (optional)
(Link Identifier List TLV)	

GetStatusRequestSet
(Get Status Request Set TLV)	

8.6.3.2 	MIH_Get_Link_Parameters response 
This message is used by an MIHF to report the status of currently available links.
MIH Header Fixed Fields (SID=3, Opcode=2, AID=1)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
DeviceStatesResponseList
(Device States Response TLV)	

GetStatusResponseList
(Get Status Response List TLV)	
Status
(Status TLV)	

8.6.3.3 	MIH_Configure_Link request
This message is used to configure the link and control the link behavior.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=2)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
OperationMode
(Operation Mode TLV)	

ConfigureRequestList
(Configure Request List TLV)	

8.6.3.4 	MIH_Configure_Link response
This message returns the status of a configuration request.
MIH Header Fixed Fields (SID=3, Opcode=2, AID=2)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
OperationModStatus
(Operation Mode Status TLV)	
ConfigureResponseList
(Configure Response List TLV)	
Status
(Status TLV)	

8.6.3.5 	MIH_Scan request 
This message is used to scan a list of PoAs for a specific link type. 
MIH Header Fixed Fields (SID=3, Opcode=1, AID=3)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
ScanLinkIdentifier
(Scan Link Identifier TLV)	

8.6.3.6 	MIH_Scan response
This message returns the list of PoAs and their respective signal strength for a specific link type after a scan operation. 
MIH Header Fixed Fields (SID=3, Opcode=2, AID=3)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
ScanLinkIdentifier
(Scan Link Identifier TLV)	
ScanResponseSet
(Scan Response Set TLV)	
Status
(Status TLV)	

8.6.3.7 	MIH_Net_HO_Candidate_Query request
This message is used for communication between the MIHF on an MN and the MIHF on a network. The function is used to communicate an intent of network initiated handover. 
MIH Header Fixed Fields (SID=3, Opcode=1, AID=4)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
SuggestedNewLinkList
(List of Link PoA List TLV)	
QueryResourceList
(Handover Resource Query List TLV)	

8.6.3.8 	MIH_Net_HO_Candidate_Query response
This message is used for communication between the MIHF on an MN and the MIHF on network. The function is used to respond to an intent of network initiated handover.
MIH Header Fixed Fields (SID=3, Opcode=2, AID=4)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
CurrentLinkIdentifier
(Link Identifier TLV)	
PreferredLinkList
(List of Link PoA List TLV)	
RequestedResourceSet
(Handover Resource Response Set TLV)	
HandoverStatus
(Handover Status TLV)	
Status
(Status TLV)	

8.6.3.9 	MIH_MN_HO_Candidate_Query request
This message is used for communication between the MIHF on a MN and the MIHF on a network. The function is used to communicate an intent of MN initiated handover.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=5)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
CurrentLinkIdentifier
(Link Identifier TLV)	
CandidateLinkList
(List of Link PoA List TLV)	

QueryResourceList
(Handover Resource Query List TLV)	
IPConfigurationMethods
(IP Address Configuration Methods TLV)	
DHCPServerAddress
(DHCP Server Address TLV)	
FAAddress
(FA Address TLV)	
AccessRouterAddress
(Access Router Address TLV)	
 
8.6.3.10 	MIH_MN_HO_Candidate_Query response 
This message is used for communication between the MIHF on a MN and the MIHF on network. The function is used to respond to an intent of MN initiated handover.

MIH Header Fixed Fields (SID=3, Opcode=2, AID=5)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
CurrentLinkIdentifier
(Link Identifier TLV)	
PreferredCandidateLinkList
(List of Link PoA List TLV)	
AvailableResourceSet
(Available Resource Set TLV)	
IPConfigurationMethods
(IP Address Configuration Methods TLV)	
DHCPServerAddress
(DHCP Server Address TLV)	
FAAddress
(FA Address TLV)	
AccessRouterAddress
(Access Router Address TLV)	
IPAddressInformationStatus
(IP Address Information Status TLV)	
Status
(Status TLV)	

8.6.3.11 	MIH_N2N_HO_Query_Resources request 
This message is used by the MIHF on the serving network to communicate with its peer MIHF on the candidate network. This is used to prepare the new link resource for impending handover and to query the available link resource of the candidate network. This message is also used to achieve IP address related information on the candidate network.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=6)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
QueryResourceList
(Handover Resource Query List TLV)	
IPConfigurationMethods
(IP Address Configuration Methods TLV)	
DHCPServerAddress (Optional)
(DHCP Server Address TLV)	
FAAddress (Optional)
(FA Address TLV)	
AccessRouterAddress (Optional)
(Access Router Address TLV)	

8.6.3.12 	MIH_N2N_HO_Query_Resources response
This message is used by an MIHF on the candidate network to communicate with its peer MIHF on the serving network. This is used to return the result of resource preparation of the impending handover and to notify the MIHF on the serving network of the link resource status and IP address related information of the candidate network.
MIH Header Fixed Fields (SID=3, Opcode=2, AID=6)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
ResourceStatus
(Resource Status TLV)
((Editor’s note: can this be merged into Status?)	
AvailableResourceSet
(Available Resource Set TLV)	
IPConfigurationMethods
(IP Address Configuration Methods TLV)	
DHCPServerAddress
(DHCP Server Address TLV)	
FAAddress
(FA Address TLV)	
AccessRouterAddress
(AR Address TLV)	
IPAddressInformationStatus
(IP Address Information Status TLV)	
Status
(Status TLV)	

8.6.3.13 	MIH_Net_HO_Commit request
This message is used by the MIHF to communicate the intent to commit to a handover request to a specific link and PoA.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=7)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
LinkActionSetList
(Link Action Set List TLV)	

8.6.3.14 	MIH_Net_HO_Commit response
This message is used by the MIHF to respond to a request to commit to a handover request to a specific link and PoA.
MIH Header Fixed Fields (SID=3, Opcode=2, AID=7)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
LinkActionResultList
(Link Action Result List TLV)	
Status
(Status TLV)	

8.6.3.15 	MIH_MN_HO_Commit request 
This message is used by the MIHF on the MN to communicate the intent to commit to a handover request to a specific link and PoA.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=8)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
LinkActionSetList
(Link Action Set List TLV	

8.6.3.16 	MIH_MN_HO_Commit response 
This message is used by the MIHF to respond to a request to commit to a handover request to a specific link and PoA.
MIH Header Fixed Fields (SID=3, Opcode=2, AID=8)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
CurrentLinkIdentifier
(Link Identifier TLV)	
Status
(Status TLV)	

8.6.3.17 	MIH_N2N_HO_Commit request
This message is used by the MIHF on the serving network to communicate with its peer MIHF on the candidate network. This message is used to inform the candidate network of the intent to commit to a handover request to a specific link and PoA, which the candidate network provides.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=9)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
ReserveResourceList????
(????? TLV)	

8.6.3.18 	MIH_N2N_HO_Commit response
This message is used by the MIHF on the candidate network to communicate with its peer MIHF on the serving network. This message is used to respond to the request to commit to a handover request to a specific link and PoA, which the candidate network provides.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=9)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
Status
(Status TLV)	

8.6.3.19 	MIH_MN_HO_Complete request 
This message is used by the MIHF on the MN to communicate the status of handover operation to the MIHF on the target network.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=10)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
HandoverResult
(Handover Result TLV)	

8.6.3.20 	MIH_MN_HO_Complete response
This message is used by the MIHF on the target network to communicate the response following the completion of handover operation to the MN.
MIH Header Fixed Fields (SID=3, Opcode=2, AID=10)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
LinkIdentifier
(Link Identifier TLV)	
Status
(Status TLV)	

8.6.3.21 	MIH_N2N_HO_Complete request
This message is used by the MIHF to communicate the status of handover operation.
MIH Header Fixed Fields (SID=3, Opcode=1, AID=11)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
CurrentLinkIdentifier
(Link Identifier TLV)	
HandoverResult
(Handover Result TLV)	

8.6.3.22 	MIH_N2N_HO_Complete response 
This message is used by the MIHF to communicate the response following the completion of the handover operation. The message is used to communicate the preferred action to be taken w.r.t resources associated with the previous connection. If the handover is successful, the resources may be released. 
MIH Header Fixed Fields (SID=3, Opcode=2, AID=11)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
CurrentLinkIdentifier
(Link Identifier TLV)	

ResourceStatus
(Resource Retention Status TLV)	
Status
(Status TLV)	

8.6.4 	MIH messages for information service 
MIH Information service uses only two messages - MIH_Get_Information request and MIH_Get_Information response. Due to the need to support different query types and the need for flexibility to customize the query and response, the parameters and their usage in these two messages are substantially different from other MIH message parameters, and are therefore separately defined in the following subclauses.
8.6.4.1 	MIH_Get_Information request
This message is used by an MIHF to retrieve a set of Information Elements provided by the information service. A single MIH_Get_Information request message can carry multiple queries of a combination of Binary, RDF_Data, RDF_Schema_URL and RDF_Schema types. However, there should be at least one query specified. The order of the queries identifies the priority of the query. The first query has the highest priority to be processed by MIIS.
MIH Header Fixed Fields (SID=4, Opcode=1, AID=1)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
InfoQueryBinaryDataList
(Info Query Binary Data List TLV)	
InfoQueryRDFDataList
(Info Query RDF Data List TLV)	
InfoQueryRDFSchemaURL
(Info Query RDF Schema URL TLV)	
InfoQueryRDFSchemaList
(Info Query RDF Schema List TLV)	
MaxResponseSize (optional)
(Max Response Size TLV)	

8.6.4.2 	MIH_Get_Information response
This is used as a response to the MIH_Get_Information request message. In one response message, one or more results can be returned. The order of the returned results corresponds to the order of the multiple queries provided in the MIH_Get_Information request message. When the result in MIH_Get_Information response message size exceeds the maximum size specified in the Max Response Size TLV from MIH_Get_Information request message, one or more of the lower order response TLVs may be omitted.
MIH Header Fixed Fields (SID=4, Opcode=2, AID=1)	
Source Identifier = sending MIHF ID
(Source MIHF ID TLV)	
Destination Identifier = receiving MIHF ID
(Destination MIHF ID TLV)	
InfoResponseBinaryDataList
(Info Response Binary List TLV)	
InfoResponseRDFDataList
(Info Response RDF Data List TLV)	
InfoResponseRDFSchemaURLList
(Info Response RDF Schema URL List TLV)	
InfoResponseRDFSchemaList
(Info Response RDF Schema List TLV)	
Status
(Status TLV)