|
MIHF is a logical entity that allows the optimization and facilitates handover decisions. MIH-Users make handover decisions based on inputs from the MIHF. It provides abstracted services to higher layers. The MIHF communicates with the lower layers of the mobility-management protocol stack through technology-specific interfaces. In other words, the MIHF is a management entity that obtains link-layer information from lower layers of different protocol stacks and also from other remote nodes and it provides them to the upper layers. The MIHF coordinates handover decision with other peer MIHF in the network.
The MIH Protocol provides capability for transferring MIH Messages between peer MIHF entities at L2 or at L3. These messages transfer information about different available networks and also provide network switching and handover capability across different networks. All exchanges between the MIHF and other functional entities occur through service primitives, grouped in service access points (SAPs).
The MIHF can be configured based on a set of parameters, which can be configured either using an configuration file or passing them directly in the command line. The available configurable parameters are presented next:
MIHF Configuration Options: --help Display configuration options --conf.file arg (=odtone.conf) Configuration file --conf.recv_buff_len arg (=4096) Receive buffer length --mihf.id arg (=mihf) MIHF ID --mihf.ip arg (=127.0.0.1) MIHF IP --mihf.remote_port arg (=4551) Remote MIHF communication port --mihf.local_port arg (=1025) Local SAPs communication port --mihf.peers arg List of peer MIHFs --mihf.users arg List of local MIH-Users --mihf.links arg List of local Links SAPs --mihf.transport arg (=udp, tcp) List of supported transport protocols --mihf.link_response_time arg (=3000) Link SAP response time (milliseconds) --mihf.link_delete arg (=2) Link SAP response fails to forget --mihf.discover arg MIHF Discovery Mechanisms Order --enable_broadcast Allows broadcast messages --enable_unsolicited Allows unsolicited discovery --log arg (=1) Log level [0-4]
![[Note]](../../images/note.png) |
Note |
|---|---|
|
All configurable parameters are self-explained and, therefore, we will only mention those that are more complex to configure. List of peer MIHFs: Comma separated list of remote MIHF's. Usage: mihf.peers = <mihf id> <ip> <port> <list of supported transport protocols>, ... List of local MIH-Users: Comma separated list of local MIH User SAP. Usage: mihf.users = <user sap id> <port> [<supported commands> <supported queries>], ... List of local Link SAPs: Comma separated list of local MIH Link SAPs. Usage: mihf.links = <link sap id> <port> <techonoly type> <interface>, ... List of suppoted transport protocols: Comma separed list of the transport protocols available. For now UDP and TCP protocols are supported. Usage: mihf.transport = <udp/tcp>, ... |
The ODTONE-MIHF allows you to statically configure the peer MIHFs by providing some information such as MIHF's IP addresses, port and supported transport protocols. Edit the ODTONE-MIHF configuration file and add an entry to peers MIHFs in the form:
<mihf_id> <ip> <port> <list of supported transport protocols>
The ODTONE-MIHF configuration file can look like:
[mihf] id = mihf1 local_port = 1025 remote_port = 4551 peers = mihf2 192.168.0.1 4551 udp transport = udp
The ODTONE-MIHF must be executed passing directly, in command line, the location of the configuration file.
E.g.: ./odtone-mihf --conf.file=./src/mihf/odtone.conf
The ODTONE's MIHF implements the three core MIH services, each containing a set of logical components. The MIES module allows the MIHF to verify if the received event messages are formatted according to the standard, which MIH-Users have subscribed the events and, if applicable, to forward the message to the subscribed MIH-Users. These represent, respectively, the roles of the Event validator, Event subscriber and Event publisher modules. The MICS module also provides a way to validate the received message and to forward them to its destination, operations that are in charge of the Command validator and Command publisher modules. The definition of the IS is out of the scope of the standard. In ODTONE, the IS acts as a MIH-User and therefore, the MIIS module is responsible to forward the messages to the IS registered with the MIHF or, if is that the case, forward the response message to the requestor.
The previously mentioned modules allow the MIHF to provide the basic features of the MIH protocol. Additionally, the ODTONE's MIHF architecture has other components which allow not only to implement the remaining features of the MIH protocol but also to add robustness to the MIHF:
