In this research, we propose a structured D2D infrastructure-less communication platform by off-the-shelf smartphones (which is hereafter referred to as ICOS) for Android devices. Focusing on features related to the fact that Wi-Fi Direct and Wi-Fi use different logical NICs described in Section 2.1
, ICOS uses the P2P-side NIC for intra-group connection and the Wi-Fi-side NIC for inter-group connection. The result is a tree-type topology that does not require reconstruction after every message transfer. In addition, by introducing a relay node (RN
) to provide a new function alongside the GO
roles, multi-hop communication between groups can be realized.
4.1. Topology Construction Mechanism
This mechanism is used to establish connectivity with unknown peripheral devices in ad hoc environments by using Wi-Fi and Wi-Fi Direct in combination. At this time, each GO autonomously controls the connection interface with the CLs in the group so that it is structured as a tree-type topology with a certain GO as the root. Control by GO can be performed using only the information exchanged by the original Wi-Fi Direct settings, which means that users do not need to input setting information or information on other devices into their devices in advance. With this feature, a tree-type topology capable of multi-hop communication is established without the need for prior setting, and achieves (R1).
Here, an RN
is newly introduced as a device role, and one or more RN
s are elected from CL
s of each group. Note that connection with GO
using only the P2P-side NIC is permitted. This corresponds to the
that always exists on CL
side in the six adopted topologies selected based on the considerations discussed in Section 3
, and plays in relaying messages from the GO
to other CL
s in the (A-4) and (B-4) topologies. For a CL
, there is no limitation on the NIC connection.
The topology is constructed by the following procedure.
A user who wishes to construct a D2D network makes its device a GO and invites peripheral devices to its group as CLs.
The role of RN is given to the first connected CL and only P2P connection is allowed.
The information necessary for Wi-Fi connection is given to CLs that connect after that, and any connection is allowed.
A CL that has switched to a Wi-Fi connection becomes the GO of a new group and waits for connections from other devices.
The GO periodically advertises its group information to all devices connected to itself.
shows the topology construction procedure. In Steps (1) and (2), both devices establish a connection using the Wi-Fi Direct function. At this time, by setting one of them as the GO
in advance, the time required for group construction is shortened. Additionally, in Step (3), when there is a connection of the second and subsequent CL
provides its AP information (service set identifiers (SSIDs) and Passphrases) necessary for Wi-Fi connection. Based on this information, CL
s decide whether to continue the P2P connection or switch to a Wi-Fi connection, and the device that has switched to a Wi-Fi connection becomes the GO
of a new group and waits for connections from other devices in Step (4). Thereafter, in the step (5) the GO
periodically exchanges its group information (GO
list, and routing table) with the surrounding devices and always shares the latest topology information. However, the periodical exchange of information in this step is not essential. Since GO
can detect an event that changes in CL
s being connected to the GO
by the function of Wi-Fi Direct, thus it will suffice to share information at that time. The periodical information exchange is useful for obtaining the latest information on devices not directly connected, but it is a trade-off with increase in network traffic.
shows a topology construction example. At this time, Nodes A, C, and D are GO
s, and Nodes B, E, and G are the RN
s of each group, respectively. From that point, Nodes A, C, and D accept connections from new devices, or Nodes F and H become new GO
s, thereby expanding the topology.
shows the detailed diagram of the topology construction mechanism. The behaviors of each device in the figure are listed below.
Each node transitions to the “device discovery” state using ICOS in order to discover peripheral devices.
Node A executes “group creation” as the GO and starts constructing a D2D network.
Node B and Node C discover Node A (“GO discovery”) and authenticate that it is a GO that is using ICOS (“GO authentication”).
Node B and Node C attempt a P2P connection to Node A using Wi-Fi Direct (“P2P request”).
Node A establishes P2P connections with the requesting devices (“P2P completion”).
Node A sends the Wi-Fi connection information that was established during the second connection to Node C.
Node C disconnects the P2P connection to Node A and attempts a Wi-Fi connection (“Wi-Fi request”).
Node A establishes a Wi-Fi connection with the requesting device (“Wi-Fi completion”).
Node C becomes the new group’s GO and waits for connection requests from other devices (“group creation”).
The specific processing performed in each state is as follows. However, exchanging messages using Bluetooth is performed only on Android 5.0 or higher devices.
- device discovery
starts searching neighboring devices and Local Services in Wi-Fi Direct and begins scanning Advertise message in Bluetooth. Searching for devices and services is accomplished with standard functions of Wi-Fi Direct. Advertise message, including device name and status (GO or not), is distributed by advertise/scan functions of Bluetooth. Note that since the search function in Wi-Fi Direct is particularly unstable, the system will retry the search every 10 s. However, the retry is not performed during either the P2P or Wi-Fi connection requests.
- group creation
creates a new group as the GO, registers Local Services in Wi-Fi Direct, and then sends an Advertise message in Bluetooth. At this time, by including the ICOS-specific character string in the Local Service service name and the Advertise message payload, the new GO advertises that it is a device currently using ICOS to connect with peripheral devices.
- GO discovery
obtains device information in Wi-Fi Direct. At this time, only the GO devices identified from the acquired device information are held. At this point, it is not possible to determine whether the discovered devices are currently using ICOS.
- GO authentication
obtains Local Service information in Wi-Fi Direct or the Advertise message in Bluetooth. At this time, it determines whether ICOS-specific character string is included in the service name of the Local Service or the Advertise message payload, and only retains information on devices having information satisfying that requirement. Next, by comparing it with the information obtained by “GO discovery”, it authenticates that it is a GO that is using ICOS.
- P2P request
requests a connection to the discovered GO in Wi-Fi Direct. However, since the Wi-Fi Direct connection request may fail, the system retries the connection request every 10 to 20 s. The time between reconnection requests is determined based on the Wi-Fi Direct state of the device requesting the connection. More specifically, when the state is WifiP2pDevice.INVITED, a retry is executed 10 s after the first request is sent, but if it is WifiP2pDevice.CONNECTED, then the waiting time is extended by 10 s.
- P2P completion
holds group information sent from the GO. At this time, if the device is registered in the group information as a CL instead of an RN, it may continue to “Wi-Fi request”.
- Wi-Fi request
leaves the group in Wi-Fi Direct and attempts to connect to the GO by Wi-Fi. Since the Wi-Fi connection request may fail in the same way as the “P2P request”, the system retries the connection request every 10 s.
- Wi-Fi completion
immediately transits to the “group creation” state.
4.2. Multi-Hop Communication Mechanism
This mechanism constructs a routing table based on the relationship with the other devices in the structured topology and transfers the message. At this time, since each GO holds the topology information shared when the topology construction, connectivity with an arbitrary device is established without requiring user input and setting pre-sharing. In addition, it is possible to send messages to other devices by unicast, and it is unnecessary to reconstruct the topology accompanying the message transfers. This feature realizes flexible routing according to circumstances and uses, and achieves (R2).
As already mentioned, it is not possible to communicate using the IP address due to multiple Wi-Fi Direct groups connected. Therefore, the platform uses device ID-based routing overlaid on IP address-based routing. Devices can use any information (phone number, MAC address, etc.) that can uniquely identify a device, as its own device ID. IP address is only used for single-hop communication with directly connected devices.
Considering the connectivity between devices in the topologies selected in Section 3
, each device updates its routing table in the following procedure based on its own role.
When a message arrives from devices of its group, the GO updates both the group information and routing table to ensure that group members can always communicate with each other via the RN. When messages arrive from other groups, only their information is updated.
When a message arrives from devices of its group, the CL updates the information about both the group and the routing table to ensure that they can always communicate with each other directly. When messages arrive from other groups, only their information is updated.
Same as CL.
Additionally, the message transmission form is determined based on the following rules.
The reason the GO
always forwards messages via its RN
is because there is no means to communicate from the GO
side when a CL
(see (A-4) and (B-4) in Figure 1
). Since the only valid message transfer model at this time is unicast, a unicast communication to the RN
is always adopted for communication from the GO
. On the other hand, since direct broadcast communication can be performed to any neighbor device from CL
s and the RN
, they always use direct broadcast communication. Although all neighboring devices will receive the same message when broadcast communication is used, the destination device ID is confirmed during implementation by referring to the independently set message header and any messages that are not headed with their device ID are discarded.
shows an example of routing table construction in Figure 3
. As shown in Figure 5
a, the communication model between devices is only unicast communication to the RN
at the time of transmission from the GO
to the device in its group, and all other communications between group members are direct broadcasts.
The routing table of Node C at this time is shown in Figure 5
b. For communication to Nodes A, B, and D, direct communication by broadcast is applied since they belong to the same group that Node C belongs to as a CL
. Additionally, as for communication to Nodes E and F, because they belong to the same group that Node C belongs as a GO
, the route via Node E, which is the RN
, is applied by unicast. Furthermore, even though there is no direct connection relationship with Nodes G and H, since its route information is obtainable when the routing table is shared with Node D, that node is registered as the next hop destination. It is to be noted that the number of hops is aimed at preventing duplication of routes generated when exchanging routing tables with neighboring devices, and the route having the minimum hop count is always adopted. Since the shortest route is uniquely determined from the topology structure, the routing table held by each device always converges after a certain period of time elapses unless devices move. Note that relationship between devices and communication model are just referred to at the time of message transmission, and are not included in the routing table information shared with others.
shows flowcharts of routing table construction and message transfer. During routing table construction, each time a device receives a message, it executes the flow shown in Figure 6
a. More specifically, when receiving a message directly, the information for both the sender and devices included in the payload is added as a new entry. At this time, if the device is a GO
and the sender is a CL
or an RN
, then the next hop is overwritten as an RN
. Otherwise, next hop is overwritten as the sender or a null (direct communication). Additionally, when the message is received via one or more relays, new entries are not added and the only the timestamp of corresponding entries is updated. The timestamp is used to determine whether a device has left the network for reasons such as movement. In this implementation, HELLO messages are periodically sent to entries that do not update for more than 10 s in order to confirm their existence, and entries that have not been updated for more than 60 s are deemed to have left the network and are deleted from the routing table.
In message transfers, when each device transmits a message, it executes the flow shown in Figure 6
b and determines the next hop device. More specifically, when the destination device information exists in its routing table, the next hop described in the entry is designated as the forwarding destination. Additionally, even if the destination device information does not exist in its routing table, if the device itself participates in ICOS network as a CL
or an RN
, it designates the GO
as the forwarding destination and transmits the message. In other cases, no message is sent.