Proposed software architecture

3.3.1. Overview

The system's architecture is basically composed of two components: the central Mobidot system and the AP. There's one central Mobidot system and there are one or more hotspots containing one or more APs.

3.3.2. Subsystem decomposition

The subsystem decomposition is aimed at a split in three parts of the functionality of the manage- ment system. The first part, StorageSubsystem, takes care of storing information. The second and third parts, the UserManagementSubsystem and HotspotManagementSubsystem, take care of the core functionality of the system: dealing with user related tasks respectively dealing with hotspot re- lated tasks. The remaining subsystems aren't modeled in UML since they are either external from the system (but important enough to mentioned), or they cannot be modeled in UML (due to the nature of the subsystem; i.e. the chosen programming language). They will be discussed in the hard- ware/software mapping section.

Figure 3.1. Subsystem class diagram

StorageSubsystem The StorageSubsystem is responsible for all stor- age related tasks. It stores all information that needs to be stored, to be retrieved, or both: activ- ation codes, configurations, firmwares, hotspot and access points, roaming partners and users.

UserManagementSubsystem The UserManagementSubsystem is responsible for user-oriented tasks: logging users in and out, automatic re-authentication when a user roams, sending network announcements to users, usage administration for both Mobidot users and ex- ternal users, management of accounts by the ad- ministrator, creation of new accounts by the user, increments of the account balance by the user and finally checking whether the user is logged in, in the case of normal system use.

HotspotManagementSubsystem The HotspotSubsystem is responsible for bring- ing the hotspots up and down on demand, providing status overviews to the MobidotNet- workManager and performing configuration up- dates and firmware upgrades.

3.3.3. Hardware/software mapping

All subsystems defined above will be part of the central management system, and as such will be mapped to the central Mobidot system. There are some remaining subsystems, which will be dis- cussed below:

FirmwareSubsystem This subsystem is the base subsystem of the APs. It is the OS that runs on the APs. It takes care of all of the AP's activities (such as routing traffic, authenticating users, letting users roam, logging off users). To perform Mobidot specific tasks it depends on the SNATCircumventionSubsystem, the AutoConfigurationSubsystem, and the AutoInstallationSubsystem.

SNATCircumventionSubsystem This subsystem takes care of the SNAT circum- vention problem, by setting up everything that is necessary for it.

AutoConfigurationSubsystem This subsystem is responsible for the configura- tion of the AP. This includes firewall configura- tions, traffic shaping configurations and some general configuration settings. To achieve a zero configuration setup, these configurations are per- formed automatically in coordination with the central Mobidot system.

AutoInstallationSubsystem This subsystem is responsible for installing the needed software packages on the AP in order to support the other subsystems on the AP. It also responsible for keeping these software packages up to date.

cilities for the user to identify himself to the sys- tem.

ExternalCommSubsystem The ExternalCommSubsystem is responsible for communication with external systems, such as an external payment system which generates activa- tion codes. This subsystem will be used both by the subsystems of the central management sys- tem and of the AP. It will be part of the central Mobidot system, as that eases the implementa- tion of the system.

Figure 3.2. Deployment diagram

Note: subsystems denoted with square brackets ('[' and ']') will be implemented in this project, but cannot be modeled in UML. Subsystems denoted with angle brackets ('<' and '>') will be implemen- ted using existing software packages.

3.3.4. Persistent data management

For the persistent data management it was necessary to choose an appropriate storage back end for storing several types of information. For most types of information the MySQL database is found to be the best choice, mainly due to its speed, its ease of implementation (no custom storage structure has to be defined, only a set of attributes per information type has to be defined), its ability to easily execute complex queries and finally its ability to easily support concurrent accesses.

UserStoreSubsystem The UserStoreSubsystem is responsible for stor- ing user related data (i.e. the list of UserAc- counts which are collected in the UserAccount- Collection).

RoamingPartnerStoreSubsystem The RoamingPartnerStoreSubsystem is respons- ible for storing the list of ExternalWifiProviders (RoamingPartnersCollection) with which Mo- bidot has a roaming agreement.

HotspotStoreSubsystem The HotspotStoreSubsystem is responsible for storing hotspot related data (the list of Hotspots and APs in HotspotCollection).

ConfigurationStoreSubsystem The ConfigurationStoreSubsystem is responsible for storing configuration data which is used by hotspots. The configuration data is composed of general configuration data, firewall configuration data and traffic shaping configuration data (the list of HotspotConfigurations in HotspotConfig- urationCollection, the list of FirewallConfigura- tions in FirewallConfigurationCollection, and the list of TrafficShapingConfigurations in Traffic- ShapingConfigurationCollection).

ActivationCodeStoreSubsystem The ActivationCodeStoreSubsystem is respons- ible for retrieving activation codes which were generated by some external payment system. It deals with ActivationCodeInfos which are part of the ActivationCodeCollection.

FirmwareStoreSubsystem The FirmwareStoreSubsystem is responsible for storing new firmware, which will be retrieved by the access points by means of some file transfer protocol. Due to the fact we are dealing here with mostly files and no structural information, it was chosen to store the firmware in a plain file system, using the file names of the firmware for storing any extra information (such as version numbers, etc). The subsystem deals with AP- Firmwares which are part of the APFirmware- Collection.

3.3.5. Global software control

The server software for the Mobidot infrastructure will be implemented as a web service provider, meaning that each request for information instantiates a new instance of the server software. This means that two distinct requests are serviced by two separate processes which cannot (at least at this moment) share anything (such as memory, control flow, etc).