Architecture & Design
The application architecture follows Android development structure written in Java. The main components/classes for GrandUnion application are listed below and their interconnection depicted below:
- Connectivity Manager Activity o Boot Broadcast
- Set Preference Activity
- Network Performance Activity o Detail Rate Result
- About Activity
- Metadata Service o Data Rate Service
Passive Metrics
Passive metrics are used to monitor the status of a user’s connection within the Meta Data Service.
Changes in the status of the connection are monitored using the Android broadcast receiver framework. Similarly, broadcast receivers are used to update the received signal strength for wireless and mobile connections.
GrandUnion app saves metadata to two files (csv format) on the local driver and updates the information on the files on connection updates.
Active Metrics
Active metrics represent the speed tests performed from the GrandUnion application on dedicated webservers.
Three types of tests are performed: (a) HTTP GET, (b) HTTP POST and (c) PING. The HTTP GET test measures the maximum downlink data rate, while the HTTP POST measures the corresponding uplink data rate for that connection. On the other hand, with PING tests, GrandUnion application gets the average round trip time (delay), its variation (jitter) and the packet loss ratio.
The user is able to select different hosts to perform HTTP operations and PING. The default webserver used for HTTP operations is located in University of Surrey domain and for PING is Google Public DNS server (IPv4 address 8.8.8.8).
Classification
GrandUnion application implements a classification algorithm using an open source Java Fuzzy Logic library.
The algorithm uses the five QoS metrics collected from during the speed tests as inputs and classifies the connection using three levels of service: “good”, “medium”, “unusable”.
This is represented with “green”, “amber” and “red” in the main GUI screen.
Policy-based connectivity management
For the purposes of GrandUnion project, we believe that ANDSF can assist in the selection of the best connection by enforcing policies from the network provider. The network provider, using aggregated data collected by the GrandUnion application and other sources, is able to provide appropriate policies for each location and user.
Therefore, we have built an ANDSF client component to be integrated with the GrandUnion application.
The flow chart above shows the processes run at the ANDSF client for the selection and validation of a policy. The algorithm starts when ANDSF information is obtained from the server. The ANDSF information may, for example, be provided (by the ANDSF server) on request from the mobile communication device (in a "pull" mode).
The ANDSF server provides a number of policies for connecting the mobile communication device to networks.
Priorities are assigned to the various policies and, at the next step of the algorithm, the highest priority valid policy is applied by the mobile communication device. A policy is considered to be “valid” if it meets a number of validity conditions. Such conditions may, for example, relate to location or the time of day.
The policy selected will have a number of access network options associated with it. The access network options will be prioritized within the policy. The highest priority access network option of the selected policy is selected at the mobile communication device.
In addition to providing network selection policies, ANDSF allows mobile operators to provide access network discovery information to assist user equipment (UE) in detecting access networks specified in the ANDSF policy rules.