Design hotspot With Opensource Tools

Design and implementation of a
hotspot network
independent of Wi-Fi service providers
E.E.J. Vonk
<E.E.J.Vonk@EWI.TUDelft.NL>

Design and implementation of a hotspot network: inde-pendent
of Wi-Fi service providers
E.E.J. Vonk
Copyright © 2005-2006 E.E.J. Vonk

Table of Contents
1. Introduction ...................................................................................................... 1
1.1. The assignment ....................................................................................... 1
1.1.1. Problem Description ...................................................................... 1
1.1.2. Project Description ........................................................................ 2
1.2. The problem domain ................................................................................ 2
1.2.1. What is Wireless-Fidelity? .............................................................. 2
1.2.2. History of Wi-Fi ........................................................................... 4
1.2.3. The problems that we are trying to solve ........................................... 6
1.3. Project goal ............................................................................................ 8
1.4. Project approach ..................................................................................... 9
1.5. Social and scientific relevance ..................................................................10
1.5.1. Social relevance ..........................................................................10
1.5.2. Scientific relevance ......................................................................10
1.6. Used terminology and conventions ............................................................10
1.6.1. Terminology ...............................................................................10
1.6.2. Conventions ...............................................................................11
1.7. Document outline ...................................................................................11
2. Analysis ..........................................................................................................13
2.1. Requirements elicitation ..........................................................................13
2.1.1. Purpose of the system ...................................................................13
2.1.2. Scope of the system ......................................................................13
2.1.3. Objectives and success criteria of the project .....................................13
2.1.4. Current System ............................................................................13
2.1.5. Proposed System .........................................................................14
2.2. Further analysis .....................................................................................16
2.2.1. Network topologies ......................................................................17
2.2.2. Defining the actors .......................................................................27
2.2.3. Defining the various uses of the system ............................................29
2.2.4. Defining the data model ................................................................42
3. Design ............................................................................................................45
3.1. Defining the design goals .........................................................................45
3.1.1. Design goals ...............................................................................45
3.2. Design problems ....................................................................................46
3.2.1. Where to put the functionality ........................................................46
3.2.2. Network of multiple access points ...................................................47
3.2.3. Security .....................................................................................47
3.2.4. Hardware and firmware ................................................................47
3.2.5. Configuration deployment .............................................................48
3.2.6. Maintenance and monitoring ..........................................................48
3.2.7. Interoperability ............................................................................48
3.3. Proposed software architecture ..................................................................49
3.3.1. Overview ...................................................................................49
3.3.2. Subsystem decomposition .............................................................49
3.3.3. Hardware/software mapping ..........................................................50
v

3.3.4. Persistent data management ...........................................................51
3.3.5. Global software control .................................................................52
3.4. Designing the subsystems ........................................................................52
3.4.1. UserManagement subsystem ..........................................................52
3.4.2. Storage subsystem .......................................................................56
4. Implementation ................................................................................................59
4.1. Solutions for the design problems ..............................................................59
4.1.1. Where to put the functionality ........................................................59
4.1.2. Network of multiple access points ...................................................59
4.1.3. Security .....................................................................................60
4.1.4. Hardware and firmware ................................................................67
4.1.5. Configuration deployment .............................................................74
4.1.6. Maintenance and monitoring ..........................................................74
4.1.7. Interoperability ............................................................................79
4.2. Implementation ......................................................................................82
4.2.1. Implementing the management system .............................................82
4.2.2. Implementing the firmware ............................................................84
5. Evaluation .......................................................................................................87
5.1. Test setup .............................................................................................87
5.2. Test procedure and approach ....................................................................87
5.2.1. Development tests ........................................................................87
5.2.2. Pilot tests ...................................................................................88
5.3. Test results ............................................................................................88
5.3.1. The firmware ..............................................................................88
5.3.2. The management system ...............................................................89
5.3.3. Results of system testing ...............................................................89
6. Conclusions .....................................................................................................91
6.1. Project specific conclusions ......................................................................91
6.2. General conclusions ................................................................................92
A. References ......................................................................................................95
A.1. Books ..................................................................................................95
A.2. Articles and other documents ...................................................................95
A.3. Various references ............................................................................... 102
B. Used acronyms .............................................................................................. 105
C. Extra project information ................................................................................. 111
C.1. Used tools .......................................................................................... 111
C.2. Needed preliminary knowledge .............................................................. 112
C.2.1. Networking concepts ................................................................. 112
C.2.2. Cryptographic concepts .............................................................. 115
D. Project supporting documentation ..................................................................... 121
D.1. Globalplan for Mobidot thesis project ...................................................... 121
D.2. Risk analysis for Mobidot thesis project ................................................... 122
vi

List of Figures
1.1. WLAN with one access point ............................................................................ 3
1.2. Mobidot network with a centralized management system ........................................ 9
2.1. Centralized architecture [Webopedia1] ...............................................................17
2.2. Star architecture [Webopedia1] .........................................................................18
2.3. Bus architecture [Webopedia1] .........................................................................18
2.4. Decentralized architecture [Minar2002] ..............................................................18
2.5. Mesh architecture [Webopedia1] .......................................................................19
2.6. Hierarchical architecture [Minar2002] ................................................................19
2.7. Ring architecture [Minar2002] ..........................................................................19
2.8. Centralized+Ring architecture [Minar2002] .........................................................20
2.9. Centralized+Centralized architecture [Minar2002] ................................................20
2.10. Centralized+Decentralized architecture [Minar2002] ...........................................21
2.11. Tree architecture [Webopedia1] .......................................................................21
2.12. Mobidot Infrastructure Situation 1 ...................................................................25
2.15. Involved systems, their dependencies and responsible actors .................................28
2.16. Use case diagram group 1 ...............................................................................29
2.17. Use case diagram group 2 ...............................................................................30
2.18. Sequence diagram for use case: CreateNewAccount ............................................31
2.19. Sequence diagram for use case: CreateNewAccount (part 2) .................................32
2.20. Sequence diagram for use case: ManageFirmware (add) .......................................34
2.21. Sequence diagram for use case: ManageFirmware (add, part 2) .............................35
2.22. Sequence diagram for use case: ManageHotspotsAndAPs (view) ...........................36
2.23. Sequence diagram for use case: ManageHotspotsAndAPs (view, part 2) ..................36
2.24. Sequence diagram for use case: ManageConfigurations (edit) ................................37
2.25. Sequence diagram for use case: ManageConfigurations (edit, part 2) ......................37
2.26. Sequence diagram for use case: ManageAccounts (delete) ....................................38
2.27. Sequence diagram for use case: ManageAccounts (delete, part 2) ...........................39
2.28. The data model ............................................................................................43
3.1. Subsystem class diagram .................................................................................49
3.2. Deployment diagram .......................................................................................51
3.3. UserManagementModels class diagram ..............................................................53
3.4. UserManagementGUI class diagram ..................................................................55
3.5. UserManagementControllers class diagram .........................................................56
3.6. ConfigurationStoreSubsystem class diagram ........................................................56
4.1. 802.1X authentication process [Open1X1] ..........................................................65
4.2. Netgear WG602 access point [SeattleWireless1] ..................................................68
4.3. Netgear WG602 access point (internal view) [SeattleWireless1] ..............................68
4.4. Linksys WRT54G access point + router [SeattleWireless2] ....................................69
4.5. Linksys WRT54G access point + router (internal view) [SeattleWireless2] ................70
4.6. Soekris net4801 [Soekris3] ...............................................................................71
4.7. Soekris net4801 (internal view) [Soekris3] ..........................................................71
4.8. SSH tunneling ...............................................................................................79
C.1. OSI reference model [Tanenbaum1996] ........................................................... 112
vii

C.2. TCP/IP and OSI network stacks [Tanenbaum1996] ............................................ 114
viii

List of Tables
2.1. Evaluation properties for several network topologies .............................................24
2.2. Use case CreateNewAccount ............................................................................31
2.3. Use case Login ..............................................................................................32
2.4. Use case UseSystem .......................................................................................33
2.5. Use case ManageFirmware (add) .......................................................................34
2.6. Use case ManageHotspotsAndAPs (view) ...........................................................35
2.7. Use case ManageConfigurations (edit) ...............................................................37
2.8. Use case ManageAccounts (delete) ....................................................................38
2.9. Use case PutHotspotDownForMaintenance .........................................................39
2.10. Use case SendNetworkAnnouncement ..............................................................40
2.11. Use case SetupAP .........................................................................................41
2.12. Use case RetrieveUsageStatistics .....................................................................42
ix

Chapter 1. Introduction
This project is called 'Design and implementation of a hotspot network' and forms the second part of
the thesis project. It started with a research assignment named 'How to deploy a Wi-Fi service pro-vider
independent hotspot network?'. This document will describe the second part of this thesis
project.
1.1. The assignment
Since a couple of years a lot of new developments have taken place in the field of IT. Two of these
(relevant to this thesis assignment) are:
• The rise of Open Source Software (OSS).
• The rise of wireless Internet access at so-called 'hotspots'.
The first development, the rise of OSS, causes the increase of usage of OSS in commercial products.
Due to the licensing conditions of OSS, the source code of the commercial software needs to be
freely available. This offers interesting opportunities.
The second development (the development on which this assignment is based), is the introduction of
wireless Internet access. A so-called 'hotspot' is a location that offers wireless Internet access to any-one
using a laptop, PDA, etc. The wireless Internet access is based on the 802.11 Wi-Fi standard.
Devices conforming to this standard are used more and more in mobile devices such as laptops and
PDAs. Public institutions are getting equipped with Wi-Fi (are being transformed to hotspots), such
as hotels, restaurants, airports, train stations, trains, but the technology is also available within com-panies.
At these locations quick and easy access to the Internet is assured by Wi-Fi technology.
A few companies put up and maintain hotspots, such as T-Mobile, KPN and Swisscom. In general
these hotspots are composed of a local network and a remote central server. The largest problem is
the fact that such systems differ for each Wi-Fi provider and thus are hard to interconnect. Each pro-vider
uses its own methods of logging in and has different rules when it comes to the usage of the
hotspots. The one might require downloading software in order to use the wireless network, the oth-er
might only use readily available hardware and software and is insecure because of that.
Mobidot is a company which is run by Joost Hietbrink en Michele Nijhuis, the suppliers of this as-signment.
The development of software which manages wireless networks is the core business of
Mobidot. It is Mobidot's intention to put up a network of Wi-Fi hotspots, on which Wi-Fi providers
can offer Internet access to their customers.
1.1.1. Problem Description
Providing a continuous, fast and low cost Internet connection is what competitors are trying to
achieve with the deployment of hotspots. To achieve this goal, several problems have to be solved: a
user should be able to make use of the hotspot in the same way at each hotspot of each provider. To
deploy as much hotspots as possible, the costs for deployment and maintenance of hotspots should
be reduced.
1

1.1.2. Project Description
Design an appropriate model for the network architecture of a hotspot. All problems described
above should be solved with this model. In more detail this means using OSS and budget hardware
to achieve compatibility and cost reduction. Develop a prototype of the network architecture and of
a management system that will monitor and manage this architecture.
1.2. The problem domain
Around 1995, connectivity (with connectivity in this document is meant: having the possibility to
connect to some public computing network such as the Internet) wasn't part of common life. People
used to communicate with one another by means of letters, telegraphy and telephone. With the intro-duction
of computers this gradually changed. First some computers were connected to create a net-work
called ArpaNet, initiated by American military and educational institutions. Later on, in the
nineties, the Internet was formed out of the former ArpaNet, connecting computers to each other
worldwide, creating a huge network of computers. The Internet introduced connectivity to the home.
Anyone with a desktop computer at home was able to connect to anyone else by the Internet, in a
matter of minutes. Nowadays, there is again a shift in the field of connectivity. It's not just possible
for anyone to connect to the worldwide network, it is possible for anyone to do this from anywhere,
and at any time. With the introduction of technologies such as GPRS, UMTS, and Wi-Fi
(Wireless-Fidelity), mobile access to the Internet has become possible. The last of these technolo-gies,
Wi-Fi (also known as WLAN), will form the basis for this project.
1.2.1. What is Wireless-Fidelity?
"How many times have you needed network or Internet access at home and
wished you could work in a different room, or even outside, without having to run
a long Ethernet cable? How many times have you been in a public spot, such as an
airport or hotel, and realized you needed to send a quick e-mail? How many hours
have you wasted sitting in conference rooms between meetings while your e-mails
pile up?" [Roshan2003]
Wireless Fidelity is a relatively new technology which enables people to connect to IP networks
(such as the Internet) without any network wires connected to their computer. Wireless digital com-munication
is not new, other wireless technologies such as HAM-radio and Aloha have been around
for a long period. There were several reasons why these technologies didn't become popular: they
were expensive, they were not easy to use (mainly used by specialized individuals and enthusiasts)
and they offered a much lower bandwidth compared to wired networks. This all changed with the
introduction of Wireless Fidelity (or Wi-Fi).
Wi-Fi can operate in two modes: infrastructure mode and ad hoc mode. Ad hoc mode (referred to as
IBSS, or Independent Basic Service Set) refers to direct connections between exactly two com-puters,
with the same possibilities as a serial cable. Infrastructure mode is the more interesting mode
of Wi-Fi: it basically works the same as an ethernet, without using network wires. This mode is
what the name WLAN (Wireless Local Area Network) refers to.
2

Figure 1.1. WLAN with one access point
In this mode, several computers can be interconnected, in order to exchange information and data,
just like you would on a wired network. One computer in the network could even be designated to
be a gateway machine, enabling any computer on the network to access an outside network such as
the Internet. In the infrastructure mode, there is a central component, called the access point. Infra-structure
mode is also referred to as BSS (Basic Service Set). When multiple access points are used
to create one WLAN, this mode is called ESS (Extended Service Set). All computers that wish to
have a wireless network connection (from now on called wireless clients), associate (make a con-nection
and authenticate) with this access point. This can only be done when the device with Wi-Fi
capable hardware is in the range of the access point, which is limited to 300 meters outdoors, and at
most 100 meters indoors (depending on the amount of walls that are in between the wireless client
and the access point). Once a connection with the access point is established, the wireless client can
begin performing network operations, just like in a wired network. And just like on a wired network,
clients of wireless networks will have to share the available bandwidth. Wi-Fi introduces advant-ages,
some of which include the fact that wires are no longer needed to interconnect all computers of
a network. Furthermore, anyone with a portable computer with Wi-Fi capable hardware can connect
be part anywhere in the coverage area of the access point and access the local network and possibly
also external networks.
Wi-Fi is defined in one of IEEE's standards: 802.11.
"802.11 refers to a family of specifications developed by the IEEE for wireless
LAN technology. 802.11 specifies an over-the-air interface between a wireless cli-ent
and a base station or between two wireless clients. The IEEE accepted the spe-cification
in 1997." [Webopedia2]
3

Wi-Fi is known by many different names. Each of the following names refer to the same base tech-nology,
without referring to any particular implementation or specification: Wireless-Fidelity, Wi-
Fi, 802.11, WLAN. Further, there are specifications under 802.11 whose names are usually used in
order to denote any implementation of such a specification. At this moment there are the following
specifications:
• 802.11: The original specification of 1997. This specification defines a transmission speed of 1
or 2 MBps and an operation frequency of 2.4 GHz. In most cases, when 802.11 is referred to
nowadays, any of the specifications discussed below is meant instead of this original specifica-tion.
• 802.11b: This specification was approved by the IEEE in 1999 and defines a transmission speed
of 11 MBps and the same operation frequency as 802.11, 2.4 GHz. Originally the term Wireless-
Fidelity (or Wi-Fi) denoted this specification, but with the introduction of even newer specifica-tions,
this changed. Wi-Fi now refers to the implementation of any of the specifications of the
802.11 standard.
• 802.11a: This specification was added in order to achieve a much higher speed than 802.11b: 54
MBps. But in order to achieve this speed, it was chosen to use another frequency band: 5 GHz.
This decision meant that existing hardware would be incompatible, and couldn't be used to
achieve this speed.
• 802.11g: Finally, this specification was added as it was realized that 802.11a wasn't gaining pop-ularity,
mainly due to the fact that new hardware was needed. Especially access points offering
public access were equipped with hardware implementing the 802.11b standard, and as such
weren't able to handle client hardware that implemented the 802.11a standard. To overcome this,
the 802.11g standard was devised. This specification defined a speed of 54 MBps in the 2.4 GHz
band, which made this standard backward compatible with 802.11b. With hardware implement-ing
this specification people were able to both connect to newer access points implementing the
802.11g standards (supporting the 54 MBps transmission speed) and to older access points
which only supported 802.11b.
1.2.2. History of Wi-Fi
When Wi-Fi was first introduced, it wasn't foreseen it could gain such a popularity it has now. Prob-ably
one of the main reasons why Wi-Fi was introduced was its ease of installation and use. It could
act as a replacement for wired networks, making it a lot easier to install home networks and
(probably even more important) corporate networks. Not having to lay down wires in order to con-nect
all computers in a home or office together would mean the installation and maintenance of such
a network is much easier, a new network could be installed in a matter of minutes.
Sharing an existing Internet connection with several people was an advantage that initiated the pop-ularity
of Wi-Fi. People would have the ability, for example, to share their Internet connection with
their neighbors. Since the Wi-Fi radio signal has a range of 100 meters and sometimes even up to
300 meters, this could easily be done. The only thing needed is an access point that covers all neigh-bors
that want to participate, and having those neighbors acquire a wireless network card for their
computer. This setup would give the involved parties one great advantage: since there is one Internet
connection used by several parties, the costs for that connection would also be divided among the
parties.
4

This way of Internet connection sharing more or less lead to another new approach, which was im-plemented
mostly by students in some student cities, including Leiden in the Netherlands (see
[WirelessLeiden1]) and Seattle in the United States (see [SeattleWireless3]). In this case, access to a
certain access point would be freely and publicly available. To denote an area which had coverage
of a publicly accessible access point, the term hotspot was introduced (in most cases, a spot is con-sidered
to be an infinitely small dot, or at least too small to be a circle or oval. In this case, a hotspot
refers to the coverage area of an access point which has a radius of 100 up to 300 meters. Normally
this would be called a circle, but in comparison to the size of the already existing Internet, this cov-erage
area is indeed very small, and thus called a spot). But this wasn't all, all these hotspots would
be interconnected using the same air-to-air interface or possibly some using wires. This would cre-ate
a giant LAN (Local Area Network) which introduced the possibility of creating a socialist-type
of network: sharing data (music, movies, games, etc) free of charge. This would be very interesting,
as it wouldn't be needed to connect to the Internet to find any music or movies. And it would lead to
some advantages, such as not incurring high bandwidth costs of normal Internet connections and
having a smaller possibility of the file sharing connections being tapped by authorities, risking pen-alties
for copyright infringement, etc. Anyone with a laptop would be able to make sure he would be
in the coverage area of a hotspot, connect to the network and start sharing data.
Like with all good ideas, it didn't take long before a commercial implementation was given birth. It
was soon realized that there was a need for Internet access (for business people, students, etc) out-side
home, business or university. Some time after a failed start up by Mobistar in the 90's (using the
original 802.11 standard), some small parties, called WISPs (Wireless Internet Service Providers),
started installing access points (using the 802.11b standard) at public meeting places, such as cafes,
restaurants, hotels, libraries, etc. The term hotspot would from then on refer to a public place that
implemented a publicly accessible wireless network. The access point would be connected to the In-ternet
using either an existing Internet connection, or a new Internet connection would be acquired.
Furthermore, the access to the wireless network wouldn't be free of charge, but would be charged
for, by the hotel, restaurant, etc. in question. With the introduction of such commercially accessible
hotspots, interesting opportunities became possible. It would be possible to place hotspots in restaur-ants
along highways which are used a lot by business people. These business people would then be
able to make a stop over between one appointment and another at such a restaurant, and be able to
check their email, enter information into a corporate system about the last appointment, etc. Or it
would be possible to equip hotels with publicly accessible access points, and enable business people
staying over at that hotel for a conference to perform tasks that otherwise would have to wait until
these people would return from the conference.
This commercial approach started small. Most large companies are usually hesitant to take the first
steps in a completely new market, in which successful involvement is uncertain. This meant that
several small parties first started initiatives, slowly implementing more and more public places with
hotspots. Once the business gains were recognized by large corporations (mostly telecommunication
providers), these corporations would buy out the small WISPs, to take over their market share, and
start expanding from that point on. A good example of this in the Netherlands was Hubhop, which
was initiated in May 2002, and by May 2003 was bought by KPN, the largest telecommunication
provider of the Netherlands.
The buyout of small WISPs by large corporations meant the initiation of a widespread implementa-tion
of public hotspots. At this moment, there are three major parties (and some minor parties) in the
Netherlands offering Internet access over public hotspots: KPN Hubhop, T-Mobile and Swisscom
Eurospot, and each of these parties is independently implementing public hotspots.
5

1.2.3. The problems that we are trying to solve
We observe that the Wi-Fi world is fragmented, possibly because Wi-Fi is still an immature techno-logy.
We see home user systems being backed by large corporations such as Linksys (daughter com-pany
of Cisco). For public hotspot systems we however see no systems from large corporations. No-madix,
which is rather expensive (in terms of investments for managers of public institutions which
house the public hotspots), is not backed by some large corporation. It has such a dangerous market
position, perhaps even more because their systems are quite expensive. In short, there's little to
choose from in the world of public hotspot systems. It would be nice to see a more diverse set of
systems available, of which this project perhaps could be one. For example, when we look at sys-tems
for cellular communication, why do Motorola, Siemens, Nokia and Ericsson all develop mo-bile
phones? The technology they provide is not renewing (compared amongst each other), the com-ponents
used for the transmissions are quite standard. Their approach to certain usability problems
or features however differs greatly. This is where they've got something to gain. The same goes for
the world of systems for public hotspots. While the core technology doesn't differ at all between sys-tems
(we do want to maintain interoperability, at least the end user expects this), there are possibilit-ies
for new systems by focusing on different features and problems. This however is only a market-ing
problem/observation.
We will now go into more depth as to which technical (and sometimes technical and economical)
problems exist. Basically, the problem that we observe is that there's no system that's extensible to a
large degree, that supports SNAT circumvention (i.e. adjustments needed in existing infrastructure
in order to support management and monitoring of devices), supports zero configuration and which
is low cost.
SNAT circumvention
This plays a role with networking hardware, in the IP layer of the TCP/IP stack, where hardware
used in a network is placed behind a NAT-gateway. Before we can fully understand what the prob-lem
is, we first need to look at what NAT actually is.
"Network Address Translation (NAT) allows computers on a private network to
access the Internet without requiring their own global (public) Internet address.
NAT modifies outgoing network packets so that the return address is a valid Inter-net
host. Return (incoming) packets have their destination address changed back,
and are relayed to the client host, thereby protecting the private addresses from
public view." [MLIP1]
Network Address Translation is usually applied in order to perform Internet Connection Sharing:
sharing one Internet connection with multiple clients on an internal network. Since normally each
network client should be configured with its own unique IP address, we would run into a problem:
the number of external IP addresses that are in possession of a certain person are usually less than
the amount of network clients. In order to solve this, the network clients get a private IP address as-signed,
an IP address that is not recognized on public networks such as the Internet, it has to be
translated to the public IP address of the network gateway (the gateway between the local network
and the Internet). When replies of traffic (initiated by a local network client) arrive at the gateway,
the destination IP address of the reply is translated back to the private IP address of the respective
local network client, and the packet is forwarded to that network client. Two forms of address trans-lation
exist:
6

• S(ource) NAT: the Network Address Translation process that was previously described, it cre-ates
the possibility for internal hosts to access an outside network. Furthermore, it makes these
hosts unreachable for network devices on any outside network, since the internal hosts are not
known by a public IP address, this can either be an increase of security or a problem.
• D(estination) NAT: is the process of translating the IP address of traffic that arrives at the gate-way
to the IP address of some internal host, and forwarding the traffic to that host. This is inher-ently
different from SNAT, since in this case the network traffic doesn't get initiated by the in-ternal
host but the external host. DNAT can occur on the transport layer, in which case one or
more TCP or UDP ports get forwarded to an internal host. DNAT can also occur at the network
layer, in which case all traffic for a certain external IP gets forwarded to an internal host. DNAT
can be useful in situations where one might want to place servers behind a NAT-enabled fire-wall,
either to decrease the number of needed IP addresses (DNAT on network layer), or to be
certain that traffic to such a server is only possible on specified ports (DNAT on transport layer).
SNAT only has to be set up for outgoing traffic, replies to such traffic are automatically handled by
a NAT daemon which maintains state tables in which logs are kept of all translated traffic. The
problem usually plays a role on non-enterprise networks (i.e. home or small to middle sized business
networks), where SNAT is applied in order to give several machines access to the Internet. SNAT in
itself increases the security of the internal hosts and because the internal machines don't need to al-low
incoming connections, they only setup outgoing connections. In most cases no DNAT has been
setup in order to make the internal machines reachable, as it is normally desired to have these ma-chines
to be unreachable from the Internet. This however is a problem for Mobidot, as Mobidot
needs to monitor and access its access points, which it does by consulting certain daemons running
on the access points. In other words, we want to circumvent SNAT and make these daemons reach-able
from the Internet (but without modifying the configuration of an existing infrastructure).
Zero configuration (Plug 'N Play)
The problem of zero configuration is one particularly important problem to deal with. It is related to
the problem of SNAT circumvention: we don't want to bother the managers of public institutions. It
shouldn't be needed for them to do all kinds of configurations, ideally the system would be a zero
configuration: the manager places the access point, connects it to the Internet, and the access point
then configures itself. Further, due to the fact that we need to connect to the Internet, we might need
user credentials if the access point is to be the main gateway. We need to get this information from
the manager of the public institution and into the access point.
Low cost solution
The last problem, with current systems, that should be mentioned is the costs for creating and main-taining
a hotspot. Each WISP uses its own hardware, but current systems for such purposes are ex-pensive
in three aspects. First, the hardware needed is quite expensive, and leads to a large invest-ment,
for the owner of a public location (such as a hotel). The second and third cost aspects are the
installation and maintenance costs. Due to the fact that current systems aren't flexible in local net-work
layout (the previously discussed problem) and the fact they need to be configured locally for
some specific settings, introduces the need for a mechanic, which means extra investment costs. Be-cause
hardware is not 'plug 'n play' means a mechanic will be needed for maintenance (read: support
contract) also, in the case of problems or in the case of firmware updates of the access point hard-ware.
This results into costs much too high for local businesses that want to add Wi-Fi as an extra
service beside their core business. Current systems allow for example hotels with rankings of three
stars or more to invest in a current Wi-Fi solution. For hotels in the low end of the market there is no
such possibility, while the visitors of such hotels (for example backpackers), might just as well (or
7

even more) be interested in wireless access. The situation even gets worse due to the fact of the ex-istence
of multiple, non-interoperable, WISPs, as will be discussed below. All these costs might lead
to a too uncertain return-on-investment, meaning businesses won't invest.
Furthermore, there are two problems which in itself don't make the project renewing, but do need to
be addressed in this project:
Extensibility
This isn't a problem that plays a role in competitive systems such as Nomadix, but it does need to be
taken into account if a system is to be created which can last. Even though performance is sacri-ficed,
extensibility is needed to keep up with the fast development in the world of Wi-Fi. It basically
means the entire system should be extensible, i.e. all different parts of the system. Even extensibility
in other directions have to be taken into account, for example: can the system that is created be run
on different hardware? If the Nomadix system would only run on the current selected set of hard-ware,
they would have a problem when that certain piece of hardware is not available anymore.
Roaming
Each WISP implements the authentication of its users (checking whether a certain user is allowed to
use the services of the network) in its own way, which makes roaming difficult. "Roaming is a gen-eral
term in wireless telecommunications that refers to the extending of connectivity service in a net-work
that is different from the network with which a station is registered. The canonical example of
'roaming' is for cellular phones, when you take your phone to an area where your service provider
does not have coverage (e.g., another country). In order for a mobile device to roam to another net-work,
a number of processes need to be performed. The first necessity for inter-network roaming is
that your service provider must have a roaming agreement with the network to which you have
moved. In 802.11 roaming can also mean subscriber mobility or handover within the same network"
[Wikipedia9]. This means that users are unable to roam to the networks of other WISPs. When, for
example, some hotels are equipped with T-Mobile hotspots and some others with KPN hotspots,
then a client who has a KPN Wi-Fi subscription will be forced to find a hotel room in a hotel which
equips a KPN hotspot, while his preference for a certain hotel might force him into a hotel which
equips T-Mobile hotspots. This might be a problem for certain businesses, which already have a
public hotspot, but not with multiple WISPs. Since roaming in many cases is not possible, it would
be needed to pay for wireless access more than once, i.e. getting a Wi-Fi subscription with more
than one WISP. This is a inconvenience for the user. Clients of for example hotels and restaurants
will be more selective. Previously they would select a hotel by its ranking and perhaps its location.
Now they will also take into account if they can have access to the network of their WISP. This
might result into a drop of clients for certain hotels. The problem with roaming is mainly in combin-ation
with the large investment costs. Roaming partnerships, such as Picopoint and Boingo do exist,
but these equip expensive hardware and partnership costs as discussed above, and as such the roam-ing
problem is not solved.
1.3. Project goal
The goal is to design and implement a prototype of the mentioned network architecture, in order to
facilitate a solution to the mentioned problem. This will be done using OSS and budget hardware.
Some important requirements of this network include user friendliness, scalability, flexibility, com-patibility,
robustness and low production costs.
8

Figure 1.2. Mobidot network with a centralized management system
The network architecture needs to be augmented with a management system from which the various
hotspots of the network can be monitored and managed.
In other words, the goal is to create a prototype of the two parts of the system (firmware that runs on
the access points and a management system that runs on the central server) and implement as much
requirements as possible. A minimal running system should be delivered, while at the same time
designing the system in such a way that enhancements can be implemented easily.
The main personal goal in this project is to learn many new things (both in terms of technology and
in terms of project approach) as well as to look at various different approaches in solving problems,
and try several approaches if the problem occurs multiple time. This relates not so much to the actu-al
project contents, but it does relate to the project approach as will be discussed further on.
1.4. Project approach
This document describes the thesis project from inception to completion in chronological order. The
project is divided into a number of phases. The first phase, the analysis, will look at the system. In
this phase the problem domain is identified. The actors which play a role in the system are identi-
9

fied. An identification of the use of the system takes place. In the second phase, the design phase,
the system is designed on an abstract level. The involved hardware is defined and described. The de-composition
of the system into subsystems is described. The assignment of the various subsystems
to certain hardware is given. Further, choices regarding persistent storage are also decided upon in
the design phase. The design phase is followed by the implementation phase, in which the object
design and the actual implementation of the system is performed. Finally the evaluation phase fol-lows,
in which the system is tested to see if it meets expectations.
Besides the creation of the system, the thesis project consists of the creation of a report documenting
the project. The basis for this report (notes, pieces of text, images) is created in-line with the project.
The actual creation and finalization of the report takes place at the end of the thesis project.
1.5. Social and scientific relevance
1.5.1. Social relevance
Being connected using wireless technologies is becoming more popular every day. More and more
people are using wireless technologies every day. Wireless technologies are becoming a part of
people's lives, either personally or professionally or both. People are counting on wireless technolo-gies
to be able to do their work more efficiently, resulting in a great dependence on these technolo-gies.
The fact that the society is becoming wireless connected makes it socially relevant.
1.5.2. Scientific relevance
The scientific relevance of this research lies in the same realization as stated before: being connec-ted
using wireless technologies is becoming more popular. This popularity can result in a downfall
of such a technology if no good structure is thought of to fit it all in. A scientific approach (as op-posed
to the economic approaches taken by the various telecom providers) is needed in order to cre-ate
a well-structured architecture. The structured approach using academic techniques, the use of
OSS and the new way of approaching the problem (top-down: from a general abstract overview to a
detailed implementation; as opposed to the bottom-up approach applied by telecom providers: func-tionality
is needed somewhere and later on at other places, eventually leading to an integrated,
though not well designed, whole) is what makes this project scientifically relevant.
1.6. Used terminology and conventions
1.6.1. Terminology
A lot of terms exist in the world of wireless networks, hereby is stated what is meant by each term.
First of all a clear distinction needs to be made between access point and hotspot. Access point
refers to the hardware device providing wireless access to other networks or to other wireless cli-ents.
Hotspot refers to the coverage area of the access point, which usually has a radius of 100 or up
to 300 meters. In this area or 'spot' one can get wireless access, but not outside it, i.e. the spot in
which one can get access is 'hot'. Furthermore, companies providing Internet services using wireless
technologies are called WISPs (Wireless Internet Service Provider), by analogy to ISP (Internet Ser-vice
Provider). There is also something which is called 'hotzone'. This refers to another type of ser-vice
(which will not be discussed in this document) provided by WISPs. In this case the coverage
10

area of the hotspot has a radius of several kilometers.
1.6.2. Conventions
In this document, references made to other documentation and quotations from other documentation
will be denoted by square brackets ('[' and ']') with an identification tag inside that is formed of the
author's name, the year in which the document was published (if known) and possibly an integer to
denote a sequence if multiple documents exist of the same author and publishing year. Further, not
yet defined terms will be defined in-line in the respective document section (as opposed to the use of
footnotes, which are unfortunately not supported fully, as described in appendix C.1). Lastly,
whenever references in third person are made, the word 'he' is used, in each of these cases 'she' could
be meant just as well, unless stated otherwise.
1.7. Document outline
This document discusses the thesis project 'Design and implementation of a hotspot network' from
inception to completion. It starts with an introduction, in which the problem domain is discussed,
followed by a discussion of the project's goal and approach.
The document then discusses the various phases of the project, namely the analysis, design, imple-mentation
and testing phases. Each chapter will tell about the approach taken to finish a phase. Fur-thermore
it discusses the choices that were made as multiple options appeared. There are four
chapters discussing the various phases, the analysis chapter (chapter 2), which discusses the require-ments
elicitation and the determination of the actors and use cases, the design chapter (chapter 3) the
implementation chapter (chapter 4) and finally the evaluation chapter (chapter 5).
Finally, in the conclusions the results of the project and some interpretations of these results will be
given. The conclusions will also include a general discussion of the study as it was provided by the
TU Delft and how it was perceived by the writer of this document.
11

Chapter 2. Analysis
In this chapter the analysis of the Mobidot project is discussed. The requirements elicitation is dis-cussed,
in particular, requirements of the project and product. Further, the translation of the problem
domain and defined requirements to the definition of a data model and definition of use cases and
actors is described.
2.1. Requirements elicitation
2.1.1. Purpose of the system
The purpose of the system is to provide public Wi-Fi access to Internet under a user friendly envir-onment.
Users have to share bandwidth, and this happens in a fair way. Sign-ups and payments for
accounts is made easy. Furthermore, the system will require minimal adjustments to a client's sys-tem,
using the system to access the Internet is practically plug and play. Finally, security is provided
as much as possible without interfering with the mentioned features. The system will support easy
roaming to and from other Wi-Fi networks. It is possible for users from other Wi-Fi networks to use
our system, and vice versa.
2.1.2. Scope of the system
The scope of the system is quite complex, four parties are involved, each having one or more re-sponsibilities.
The main party involved is Mobidot itself. It is responsible for three systems: the
central management system, the support department and the development department. Furthermore,
zero or more telecommunication providers are involved, either as technology partners or as roaming
partners. They supply NAS or VPN servers in order to support roaming. Further, they supply the In-ternet
connections needed for the various hotspots and the central management system. The third
party that's involved is the group of managers of the public institutions (hotels, etc) housing the hot-spots.
They are responsible for housing the Mobidot access points and for a reception desk that can
function as a 1st line helpdesk. Finally, there are the clients who visit the public institutions and that
use the system. They are responsible for the hardware used to access the system. Further, they are
responsible for retrieving an account needed to access the system.
2.1.3. Objectives and success criteria of the project
2.1.3.1. Objectives
The objective of the project is to create a working prototype of the system, which will completely
implement a small set of important features. The system should be developed in such a way that it
can be used in production environments but also can easily be extended with additional features.
2.1.3.2. Success criteria
The project is a success when the mentioned set of important features has been implemented within
the time constraints described in the global plan (see appendix A) and when the system is designed,
implemented in such a way that it can already be deployed successfully in production environments.
2.1.4. Current System
13

The system to be developed doesn't replace any existing system, as it introduces new technology to
create new possibilities.
2.1.5. Proposed System
2.1.5.1. Overview
The system's main function will be the deliverance of paid wireless Internet access to visitors of
public places (such as hotels and restaurants). It will do this by means of the 802.11 wireless fidelity
protocol. The system will consist of multiple hotspots, which are constituted themselves of one or
more APs. These APs will be connected to a central server in a centralized topology (purely central-ized
or centralized+ring, etc).
The APs will offer the wireless Internet access to the visitors of the hotspots. The central Mobidot
system will manage the network of APs by monitoring, by configuring and keeping it up-to-date.
Wireless users will need to authenticate themselves before they can use the network, unless they
want to visit some particular websites, which can be accessed for free.
2.1.5.2. Functional Requirements
• Free websites : The user can visit certain websites (a small amount of informational sites, such
as yellow pages, etc) without being authenticated.
• Mobidot Wi-Fi accounts : The client creates a Wi-Fi account at the Mobidot login website, and
uses a simple pay system such as paid SMS or a 0900 service number to pay for the account and
activate it.
• Live roaming : Client moves around with his mobile equipment within the hotspot from the cov-erage
area of one AP to the coverage area of another, while the Internet connection is kept alive.
• Inter-network roaming : A client of another public Wi-Fi provider connects to the Internet using
the Mobidot Wi-Fi network by selecting his provider on the central Mobidot system login web-site.
• Manager to user communication (one way) : Manager notifies client of an upcoming event by
means of a message, sent from the central management system.
• Bandwidth adjustment per hotspot : Manager activates a different (as compared to the standard
setup) bandwidth sharing setup on one or more APs of a certain hotspot.
• Easy new configuration deployment : Manager sets up a new configuration for all or some of the
Mobidot hotspots. The new configuration is then automatically applied by all hotspots in ques-tion.
• Status overview : Manager visits the 'status overview' page of the central Mobidot system man-agement
website where the central Mobidot system shows status and statistical information of
all Mobidot hotspots.
• Easy firmware updates : Manager uploads new firmware to the central Mobidot system from
where it is distributed automatically to all hotspots.
14

• Account management : Manager manages clients' accounts, such as editing of user information,
resetting passwords and deleting accounts.
• AP status/statistical information supply : At regular intervals, APs gather status and statistical
information (about the network, users, hardware status, etc) and send this information to the
central Mobidot system.
• Usage statistics logging : The central Mobidot system keeps logs of the usage of the system by
users, both in terms of usage duration and data traffic.
• Monitoring : The central Mobidot system monitors the Mobidot network by retrieving certain
SNMP (Simple Network Management Protocol) information from the APs from time to time.
• Web redirection : Users are redirected to the login screen of the system if they try to visit a web-site
with their web browser, while they are not authenticated yet.
• Mail redirection : The mail agents of users are redirected to the mail server running on the cent-ral
Mobidot system, but only if these users have authenticated successfully.
• Manageability from central point : Manager manages the Mobidot network from the central Mo-bidot
system, using the central Mobidot system management website.
• Easy hotspot setup : APs of a certain hotspot configure themselves automatically such that new
hotspots can be deployed or existing hotspots extended in a plug and play manner.
2.1.5.3. Non-functional requirements
2.1.5.3.1. User interface and human factors
• User friendly access to the system : It should be possible for clients to use the system without
(too many) adjustments to their computer system. The user can use the infrastructure without
modifying his IP settings.
2.1.5.3.2. Hardware consideration
• AP hardware : Hardware is needed for the access points. The APs should support running Linux
firmware.
• Thin AP hardware : As much functionality as possible should be implemented in the central
Mobidot system, instead of in the APs.
2.1.5.3.3. Error handling and extreme conditions
• Monitoring alerts : When the central Mobidot system notices that an AP is not announcing its
presence anymore and is being non-responsive, the central Mobidot system sends an alert to the
manager(s).
15

2.1.5.3.4. Quality issues
• Fair use : Bandwidth as made available by the APs on a certain hotspot is divided (roughly)
evenly among all connected users, i.e. it shouldn't be possible for one user to block out another
by means of heavy downloads or uploads.
• Basic bandwidth availability : A bandwidth of 256 Kbps is made available for the manager of
the location (i.e. a hotel) where the hotspot is hosted.
2.1.5.3.5. System modifications
• On the fly firmware updates : APs upgrade their firmware automatically by regularly checking
in with the central Mobidot system to check for new versions of the firmware. If an upgrade is
available, the firmware is automatically downloaded, installed and activated.
• Traffic tapping : The system should provide hooks such that tapping network traffic can be setup
easily.
2.1.5.3.6. Security issues
• Host-to-network layer isolation : Laptops should operate isolated on the wireless network, it
shouldn't be possible for laptops to contact each other circumventing the AP and it shouldn't be
possible for laptops to contact machines on a possibly existing wired network (to which the AP
might be connected).
• Optional extra security for users : Privacy of users is protected as much as possible, without
having the user friendly access to the system suffer degradation. Either 802.11i should be sup-ported
(if it can be supported without requiring users to use it; some hardware might not support
it), or optional VPN connections of any type should be supported.
• Authentication before system use : Unauthenticated users cannot use the wireless network, be-sides
browsing some free websites.
• Rogue APs : Rogue APs are detected and (if possible) locked out.
2.1.5.4. Pseudo requirements
The system will be written in at least two programming languages, one for the management system
and one for the firmware additions. The management system will be programmed in PHP, the firm-ware
additions in shell script.
2.2. Further analysis
In this section, the second part of the analysis is discussed. Since it's clear we are dealing with a cli-ent-
server type of system, we need to choose an appropriate network topology. This will be dis-cussed
first, starting with a theoretical discussion about various possible topologies. After this, the
16

identification of the various actors and uses of the system (in terms of scenarios and use cases) from
the requirements is discussed, followed by a discussion of the inception of the data model from the
use cases.
2.2.1. Network topologies
The theory of network topologies is actually based on graph theory of mathematics. Many similarit-ies
can be found, and also many algorithms from graph theory are used in network applications that
apply a particular topology.
When we are talking about network structures and topologies in relation to the objective of this
project, there are actually two distinct network structures to talk about. The first one is the network
that is formed by the various hotspots and a central Mobidot system, in this document this network
will be referred to as Mobidot network. The other one is the network that is formed between mul-tiple
access points at one location (a hotel, a train station, etc), this network type will be referred to
as 'Mobidot WLAN'. Multiple access points are used when the coverage area of one access point is
too small, or when the bandwidth offered by one access point is too small for the amount of custom-ers
that want access to the network.
Before having an in-depth look at each of the network topologies, first lets have a look a what kinds
of network topologies there are in general. [Webopedia1] states:
"Topology refers to the shape of a network, or the network's layout. How different
nodes in a network are connected to each other and how they communicate is de-termined
by the network's topology. Topologies are either physical or logical."
According to [Minar2002] there are four basic topologies: centralized, decentralized, hierarchical
and ring systems. These topologies can be used by themselves or they can be combined in one way
or another to create hybrid networks. [Minar2002] considers topology in terms of the information
flow. This means that the information flow that occurs between nodes more or less defines with
what kind of network topology we are dealing. Because of this fact we will later on have a look at
what kinds of information flows exist within the Mobidot network, in order to be able to choose a
network structure.
Centralized architecture
In a centralized architecture, client machines
have to contact a central server in order to get
something done.
Figure 2.1. Centralized architecture
17

[Webopedia1]
Figure 2.2. Star architecture
[Webopedia1]
Star architecture
The star architecture is a member of the central-ized
architectures group, and is realized as a net-work
which contains a central hub and several
nodes. All nodes (can only) communicate to
each other through the central hub.
Bus architecture
In the bus architecture, nodes are connected to
one another through a common bus. This archi-tecture
is a special kind of centralized architec-ture,
since it's not merely the fact that there can
be nodes that play a centralized role in the net-work,
but more the fact that the backbone
through which the nodes communicate is the
centralized part of the network.
Figure 2.3. Bus architecture
[Webopedia1]
Figure 2.4. Decentralized architecture
[Minar2002]
Decentralized architecture
Decentralized systems are essentially pure peer-to-
peer systems, thus there is symmetrical com-munication
(one node can request something
from another and get a response, that other node
can also request something from the former
node, and get a response also), and all nodes
have equal roles. There is no central part in the
network, and as such, the availability of the net-work
is not dependent on one single machine,
while this is an advantage, pure decentralized
systems also introduce the problem that there is
no central authority.
18

Mesh architecture
The mesh architecture is a concept that comes
from graph theory, and denotes a network in
which all nodes are connected to all other nodes.
Figure 2.5. Mesh architecture
[Webopedia1]
Figure 2.6. Hierarchical architecture
[Minar2002]
Hierarchical architecture
One of the systems that made the Internet ac-cessible
to humans is the Domain Name Service
(accessible in the meaning that it is relatively
easy to operate). The Domain Name Service (or
DNS) is a hierarchical system "where authority
flows from the root name-servers to the server
for the registered name and often down to third-level
servers" [Minar2002].
Ring architecture
"A single centralized server
cannot handle high client load,
so a common solution is to use
a cluster of machines arranged
in a ring to act as a distributed
server. Communication
between the nodes coordinates
state-sharing, producing a
group of nodes that provide
identical function but have
19

fail-over and load-balancing
capabilities." [Minar2002]
Figure 2.7. Ring architecture
[Minar2002]
Figure 2.8. Centralized+Ring
architecture [Minar2002]
Hybrid: centralized+ring architecture
"Serious web server applica-tions
often have a ring of serv-ers
for load balancing and fail-over.
The server system itself
is a ring, but the system as a
whole (including the clients) is
a hybrid: a centralized system
where the server is itself a
ring. The result is the simpli-city
of a centralized system
(from the client's point of
view) with the robustness of a
ring." [Minar2002]
Hybrid: centralized+centralized architecture
In situations where servers themselves are clients
to other servers, we are talking about a central-ized+
centralized architecture. For instance 2-tier
and multi-tier applications work this way.
Figure 2.9. Centralized+Centralized
Hybrid: centralized+decentralized architec-ture
"A new wave of peer-to-peer
systems is advancing an archi-
20

Figure 2.10. Centralized+Decentralized
tecture of centralized systems
embedded in decentralized
systems. This hybrid topology
is realized with hundreds of
thousands of peers in the
FastTrack file-sharing system
used in KaZaA and Morpheus.
Most peers have a centralized
relationship to a "super node,"
forwarding all file queries to
this server (much like a Nap-ster
client sends queries to the
Napster server). But instead of
super nodes being standalone
servers, they band themselves
together in a Gnutella-like de-centralized
network, propagat-ing
queries. Internet email also
shows this kind of hybrid topo-logy.
Mail clients have a cent-ralized
relationship with a spe-cific
mail server, but mail serv-ers
themselves share email in a
decentralized fashion."
[Minar2002]
Hybrid: tree architecture
"A hybrid topology. Groups of
star-configured networks are
connected to a linear bus back-bone."
[Webopedia1]
Figure 2.11. Tree architecture
[Webopedia1]
2.2.1.1. Evaluation properties for choosing network topologies
21

[Minar2002] presents seven properties which can influence decisions in choosing a certain network
topology. Whenever a new application is designed, one of the design steps includes the choice of a
suitable topology, based on the requirements of the application that is to be developed. These seven
properties (as presented by [Minar2002]) are:
• Manageability
Manageability defines if it is easy to manage the system. Management activities could include
updating, repairing and logging.
• Information coherence
Coherence is defined by Dictionary.com as:
"The quality or state of cohering, especially a logical, orderly, and aesthetically
consistent relationship of parts."
So when we are talking about information coherence, we are talking about pieces of information
throughout the system, which have to be or naturally are consistent with each other. In this docu-ment,
when a system is said to be coherent, it means information coherence exists in the system,
or can be enforced without problems. When talking about information coherence, three aspects
play a role: non-repudiation, auditability and consistency. Non-repudiation means that it is not
possible for people to send information through the system and later on deny that they sent it.
Auditability means that transactions through the system are traceable to an origin. Consistency
deals with the fact that certain pieces of information shouldn't contradict with certain other
pieces of information in the system. When these aspects are either enforced or readily available
by nature within the system, then we are dealing with a system in which information is coherent.
Information in a system is said to be not coherent when it is impossible to enforce information
coherence without changing the network topology used.
• Extensibility
Extensibility deals with the fact how well a certain system can be extended with resources (as in
information or other data). For example, how easy is it to add a host sharing some files to an ex-isting
file sharing network?
• Fault tolerance
Fault tolerance concerns the immunity of the system to erroneous situations or faults. The more
fault tolerant a system is, the more a system can continue to operate without having the user no-tice
a fault occurred.
• Security
Security deals with how easy it is to hack the system, or seen from the other viewpoint, how
hard it is to secure the system.
• Resistance to lawsuits and politics
Is the system easy to shutdown by authorities, for example in media sharing applications? Being
lawsuit proof mainly plays a role in popular peer-to-peer file sharing applications, which are un-der
pressure of large music and movie production companies.
22

• Scalability
Scalability is about being able to enlarge a system to meet demands. It deals with how well the
network scales when resources are actually being added to the network. For example can a cer-tain
network handle 2000 clients or hosts, or can it only handle 10 clients?
Of these seven properties, resistance to lawsuits, extensibility and information coherence will not be
reviewed. Resistance to lawsuits doesn't play any role in the choice of network topologies for a cer-tain
business application. And since the Mobidot network is not destined to be an information sys-tem,
but rather a network access providing system, it won't be dealing with information and as such
extensibility and information coherence don't play a role in this case.
2.2.1.2. Evaluation of the various network topologies
In order to ease the choice of a network topology, these properties are valued against each network
topology set forth by [Minar2002] and [Webopedia1] with a 'good', 'average' or 'bad' designation.
Each network topology will be discussed individually, all properties will get a grade depending on
the results of the discussion and a summarizing table will be provided at the end of this section.
2.2.1.2.1. Centralized architectures
In centralized architectures, there is one central server to which many clients connect. The fact that
there is only one server in the system, means that the system is easily manageable, all data is con-centrated
at one host and as such only one host needs to be managed. Securing a centralized system
is very easy, there is only one host that needs to be protected. Fault tolerance is not achieved in any
way in a centralized system. If the central Mobidot system goes down, the network is down, causing
the entire system to be unusable. When talking about scalability there are little growing possibilities
of the system (hardware might be added, but only a limited amount) without changing the network
topology used, thus the scalability of centralized systems is bad.
2.2.1.2.2. Ring architectures
Ring architectures are architectures which consist of multiple servers. Since these servers usually
have a single owner, these networks act the same as centralized architectures when it comes to man-ageability
and security. One of the added advantages of ring architectures over centralized architec-tures
is the fact that there is fault tolerance, since multiple servers are doing exactly the same thing.
This first of all achieves load balancing, but it also creates the possibility of letting other servers
take over the work of a certain server if it goes down, resulting in fault tolerance. Lastly, contrary to
centralized architectures, ring architectures scale quite well if well-designed, any number of hosts
can be inserted into the ring.
2.2.1.2.3. Hierarchical architectures
Hierarchical systems have a clear chain of actions, but usually are owned by various people, making
it hard to manage individual hosts of the network. Since nodes in the network usually are owned by
multiple individuals, incorporating security into the system is hard. Contrary to centralized architec-tures,
hierarchical architectures provide good scalability. On any level of the tree below the root, any
number of servers can be added in order to handle the system load. Finally, hierarchical systems are
more fault tolerant than centralized systems, but the root of the hierarchical architecture is still a
single point of failure.
23

2.2.1.2.4. Decentralized architectures
Decentralized systems consist of multiple systems, which all form an active part of the network.
Usually the various hosts in the network are owned by various individuals, making the system hard
to manage. Further, for the same reason, a decentralized system is hard to secure. Any host could
connect and start to inject bad information or data into the system, because of the fact that there is
no central authority. But contrary to centralized systems, decentralized systems are very fault toler-ant,
since in essence all nodes are equals, it won't be noticed if one node goes down, since others can
take over. Lastly, a decentralized system scales quite well when information coherence is not con-sidered,
any number of hosts can be connected without performance degradation (any node that con-nects
to the network can from then on provide the same services to the network to again other nodes,
and these nodes in turn can do the same) If it would be necessary to keep the information in the sys-tem
coherent, algorithms would be needed to achieve this, causing a lot of overhead. "If that over-head
grows with the size of the system, then the system may not scale well." [Minar2002]. Since in-formation
doesn't play a role in the Mobidot network, information coherence doesn't have to be con-sidered,
causing decentralized architectures to scale quite well in that particular situation.
2.2.1.2.5. Hybrid architectures
It is impossible to discuss the properties of all possible combinations of architectures, so only a gen-eral
overview will be presented here.
Combining different architectures, creating hybrid architectures, is usually done to add the advant-ages
of one architecture to those of another, trying to get the best of both worlds. For example file
sharing applications like Kazaa utilize a hybrid centralized + decentralized architecture. Having a
couple of super nodes form a decentralized network, and having this network of super nodes acting
as a centralized system to many clients. This gives advantages like manageability of the system,
ability to keep the system secure (in essence the super nodes are central and in control of one party),
but still the system has the very good fault tolerance of decentralized systems.
2.2.1.2.6. Summary of the evaluation properties
Below are presented the evaluation properties as defined and discussed for the various topologies
above.
Name Manageability Fault tolerance Security Scalability
Centralized good bad good bad
Decentralized bad good bad good
Hierarchical average average bad good
Ring good average good average
Table 2.1. Evaluation properties for several network topologies
2.2.1.3. The appropriate topology
A problem with the system that is to be designed is the fact that the system has a distributed nature,
which makes things more complex. On one hand there are the access points which have to be mon-
24

itored and managed, on the other hand there is the system that manages and monitors the infrastruc-ture.
There are three information flows active in the infrastructure: an authentication flow (user try-ing
to get access), a user data flow (user making use of the Internet) and a management flow
(between the access points and the central managing system). In all situations, the management flow
is centralized, since the information is needed centrally in order to manage the system. The other
two information flows can however be centralized or decentralized. Before we can make a well-weighed
decision in choosing a network topology, we must first know which options there are and
discuss the pros and cons of each option.
Figure 2.12. Mobidot Infrastructure Situation 1
In the first situation, both the authentication flows and user data flows are decentralized and directly
sent to the roaming partner of which the current user is a client. This situation imposes a serious lim-itation:
we have no control over the authentication flow. As such we don't know who is active on
our networks and we cannot manage these users nor monitor them. For example, we cannot send
network announcements to these users in order to inform them about upcoming downtime of the
network, due to the maintenance.
25

In the second situation, both the authentication flows and user data flows are proxied through the
central Mobidot system, before they are sent to a roaming partner, if any. Having the user data flow
centrally imposes a very large problem: the central server becomes a bottleneck and a single point of
failure. Unless the central server is heavily invested in, it will lead to performance problems. Fur-thermore,
the central server might need to be setup redundantly on geographically separated net-
26

works, possibly leading to high costs.
In the third situation, the authentication flow is setup centrally, i.e. it is proxied through the central
Mobidot system before it is sent to the roaming partner in question. The user data flow is however
decentralized. In this situation we have combined the pros of the first two options and filtered out
the cons of these options. As such, this situation seems to be the best choice.
2.2.2. Defining the actors
Having a good look at the system and the environment in which it operates leads to the identifica-tion
of four actors. First of all there's the end user, the visitor of for example a hotel who wishes to
browse the Internet with his laptop wirelessly (HotspotVisitor). There's the manager of the institu-tion
(hotel, restaurant, etc) housing the public hotspot (HotspotLocationManager). This actor is in-volved
with the system in two ways. First as an unlimited user (that is, only on his hotspot). Further
he manages everything that is needed to operate his hotspot, i.e. the investments for the necessary
hardware and the necessary network connections (externally to the Internet, and internally). And in
time, he might be responsible for maintaining the portal site (using specialized Mobidot tools) for
his specific hotspot. The third actor which is identified is the manager of a WISP with which Mo-bidot
has a roaming agreement (RoamingPartner). This actor needs information about the use of the
Mobidot infrastructure by its users, in order to be able to bill its users. Finally, there's the technical
staff of Mobidot, the Mobidot network managers, who manage and monitor the infrastructure
(MobidotNetworkManager).
Now let's have a look at the system and its environment. Each involved actor is responsible for a
certain piece of the system.
27

Figure 2.15. Involved systems, their dependencies and responsible actors
Basically, the HotspotVisitor's hardware (i.e. laptop) depends on the presence of Mobidot access
points. The APs together with the needed Internet connection to connect the AP to are the responsib-ility
of the HotspotLocationManager. The HotspotLocationManager orders an AP from Mobidot
and places it in a strategic location (considering the coverage area of the access point), making sure
28

it can connect to the Internet. The APs in turn depend on the central Mobidot system, which the Mo-bidotNetworkManager
is responsible for. This system is, like the other systems, composed of sever-al
parts. One of these is the AAA server. This AAA server (which, amongst other things, performs
authentication of users) is in turn dependent on the AAA server of RoamingPartners, whenever
users from such roaming partners roam onto the Mobidot network. Both the central Mobidot system
and the AAA servers of RoamingPartners depend on an Internet connection, just as the Mobidot
APs. Finally, the diagram above also shows a little about the assignment, it shows two parts of the
system which are to be developed for this assignment: The Mobidot AP system and the Mobidot
management system.
2.2.3. Defining the various uses of the system
Taking a good look at the requirements, we can find that most use cases are similar, but not exactly
the same. The fact that most use cases are similar means we can quickly design and implement the
system, as the same design philosophy that is used for one use case can be used for the others. In
this case, there are two groups of use cases.
Figure 2.16. Use case diagram group 1
29

Figure 2.17. Use case diagram group 2
2.2.3.1. HotspotVisitor use cases
The tables below describe the CreateNewAccount use case, the Login use case and the UseSystem
use case in detail. The CreateNewAccount use case describes how one retrieves an activation code
and uses this code to create a new account. The Login use case describes how one logs in into the
system to be able to use the system. The UseSystem use case, finally, describes how one uses the
system. For CreateNewAccount a translation into a sequence diagram is provided too.
Use case name CreateNewAccount
Participating actor(s)
Initiated by HotspotVisitor
Entry condition
1. The HotspotVisitor starts his laptop and
runs his favorite web browser, trying to vis-it
a website.
Flow of events
2. The AP contacts the AAA server on the
central Mobidot system to find out whether
the user has logged in successfully.
3. The AAA server returns a false value and
the AP redirects the HotspotVisitor to the
central Mobidot system login website.
4. The HotspotVisitor activates the "Create a
new HotspotVisitor account" function of
the central Mobidot system login website.
5. The HotspotVisitor is asked to use a phone/
cellular payment system in order to get an
30

activation code.
6. [The HotspotVisitor uses the external pay-ment
system, which generates and stores an
activation code and announces this code to
the HotspotVisitor. The activation code
(including some extra information, such as
the amount that was paid for) is stored in
the Mobidot database by the external pay-ment
system.]
7. The HotspotVisitor enters personal inform-ation
(name, postal address and email ad-dress),
a new user name and password, and
the activation code into the input form on
the "create new account" web page and hits
the "Create Account" button.
8. The central Mobidot system checks in the
Mobidot database whether this user name is
available.
9. The central Mobidot system receives the re-quest,
checks whether the activation code is
correct by contacting the Mobidot database.
When it is, the central Mobidot system re-trieves
some additional information from
the same table in the Mobidot database (i.e.
the amount that was paid for).
Exit condition
10. The HotspotVisitor's account is created in
the Mobidot database. The HotspotVisitor
receives a message confirming the success-ful
creation of the account.
Table 2.2. Use case CreateNewAccount
Figure 2.18. Sequence diagram for use case: CreateNewAccount
31

Figure 2.19. Sequence diagram for use case: CreateNewAccount (part 2)
Use case name Login
Entry condition
1. The HotspotVisitor starts his laptop and
runs his web browser, in order to visit the
central Mobidot system login website.
Flow of events
2. The HotspotVisitor enters his login creden-tials
in the input form that is presented, and
hits the Login button.
3. The AP intercepts the request, interprets the
query and queries the AAA server on the
central Mobidot system with the provided
information.
4. The central Mobidot system AAA server
checks whether the login credentials are
correct, and if so returns a success message
to the AP, else it sends a failure message. It
records several details about the login
(login status, login time) in the Mobidot
database.
5. The AP forwards the response detailing
success or failure to the HotspotVisitor. The
AP adjusts its firewall tables such that net-work
traffic from the HotspotVisitor is al-lowed.
Exit condition
6. The HotspotVisitor receives either a failure
or success message. In case of a success
message, the HotspotVisitor is then authen-ticated
and can then initiate the UseSystem
and Logout use cases.
32

Table 2.3. Use case Login
Use case name UseSystem
Entry condition
1. The HotspotVisitor was successfully au-thenticated
as described in the Login use
case and starts his web browser to visit a
website.
Flow of events
2. The HotspotVisitor's laptop sends the web-site
request to the nearest AP.
3. The AP checks whether this user is authen-ticated
(by checking with the AAA server in
the central Mobidot system), if so, it allows
the query to pass.
4. The central Mobidot system forwards the
website request to the intended server and
the central Mobidot system returns its re-sponse
to the AP.
5. The AP forwards the response to the Hot-spotVisitor's
laptop.
Exit condition
6. The HotspotVisitor receives the website
that was requested. The use case keeps re-peating
from step 2, unless the HotspotVis-itor
logs out from the system.
Table 2.4. Use case UseSystem
2.2.3.2. MobidotNetworkManager use cases
In this section we will look at various management use cases. These use cases basically describe
how one manages a certain type of information. Management of information (in this system) in-volves
four basic actions: add, view, edit and delete. Each of these actions are described in the tables
below, followed by a translation into sequence diagrams. We will discuss the add action of the Man-ageFirmware
use case, the view action of the ManageHotspotsAndAPs use case, the edit action of
the ManageConfigurations use case and the delete action of the ManageAccounts use case. Further-
33

more, we will look at the use case descriptions of the use cases PutHotspotDownForMaintenance
and SendNetworkAnnouncement.
Use case name ManageFirmware (add)
Initiated by MobidotNetworkManager
Entry condition
1. The MobidotNetworkManager activates the
"Firmware Management" function of the
central Mobidot system management web-site.
Flow of events
2. The central Mobidot system queries the file
system and shows a list of all previously
uploaded firmware images to the Mobidot-
NetworkManager.
3. The MobidotNetworkManager clicks the
Add button and browses to and selects the
firmware on his PC he wants to upload. He
hits the Submit button.
4. The central Mobidot system then stores the
firmware image in a previously configured
location in the file system of the central
Mobidot system.
Exit condition
5. The firmware image is added to the file sys-tem
of the central Mobidot system. APs will
notice the new firmware within the next
hour and update themselves.
Table 2.5. Use case ManageFirmware (add)
Figure 2.20. Sequence diagram for use case: ManageFirmware (add)
34

Figure 2.21. Sequence diagram for use case: ManageFirmware (add, part 2)
Use case name ManageHotspotsAndAPs (view)
Entry condition
"Manage Hotspots" function of the central
Mobidot system.
Flow of events
2. The central Mobidot system queries the
Mobidot database and shows a list with all
hotspots to the MobidotNetworkManager.
3. The MobidotNetworkManager clicks on a
hotspot he wants to view.
4. The central Mobidot system then fetches all
related hotspot information of the selected
hotspot from the Mobidot database and
shows it to the MobidotNetworkManager.
Exit condition
5. The MobidotNetworkManager gets an over-view
of all information related to the selec-ted
Hotspot, including the collection of APs
which are located at that hotspot.
Table 2.6. Use case ManageHotspotsAndAPs (view)
35

Figure 2.22. Sequence diagram for use case: ManageHotspotsAndAPs (view)
Figure 2.23. Sequence diagram for use case: ManageHotspotsAndAPs (view,
part 2)
Use case name ManageConfigurations (edit)
Entry condition
"Manage Configurations" function of the
central Mobidot system.
Flow of events
configurations to the MobidotNetworkMan-ager.
3. The MobidotNetworkManager selects some
configurations he wants to edit, he then hits
the Edit button.
36

4. The MobidotNetworkManager changes the
preferred firewall and traffic shaping con-figurations
of the selected hotspot configur-ation
and hits the Save button.
Exit condition
5. The hotspot configuration is updated with
the new information.
Table 2.7. Use case ManageConfigurations (edit)
Figure 2.24. Sequence diagram for use case: ManageConfigurations (edit)
Figure 2.25. Sequence diagram for use case: ManageConfigurations (edit, part
2)
Use case name ManageAccounts (delete)
Entry condition
37

"Account Management" function of the
central Mobidot system management web-site.
Flow of events
users to the MobidotNetworkManager.
3. The MobidotNetworkManager selects some
users to delete and hits the Delete button.
4. The central Mobidot system asks the Mo-bidotNetworkManager
whether he is sure,
the MobidotNetworkManager hits the Yes
button.
5. The central Mobidot system then instructs
the Mobidot database to delete the selected
accounts.
Exit condition
6. The selected accounts are deleted from the
Mobidot database.
Table 2.8. Use case ManageAccounts (delete)
Figure 2.26. Sequence diagram for use case: ManageAccounts (delete)
38

Figure 2.27. Sequence diagram for use case: ManageAccounts (delete, part 2)
Use case name PutHotspotDownForMaintenance
Entry condition
1. The MobidotNetworkManager uploads a
new firmware according to the Manage-
Firmware (add) use case.
Flow of events
2. The AP checks in with the central Mobidot
system once every hour in order to check
for updated packages and new firmware. It
finds a new version of the firmware.
3. The AP puts itself in offline mode in order
to prepare for the firmware upgrade.
Exit condition
4. All APs are put offline for maintenance.
Table 2.9. Use case PutHotspotDownForMaintenance
Use case name SendNetworkAnnouncement
Communicates to/with HotspotVisitor
Entry condition
1. The MobidotNetworkManager uploads a
new firmware according to the Manage-
Firmware (add) use case.
39

Flow of events
2. The central Mobidot system stores a general
message concerning downtime of the sys-tem
in the Mobidot database, for each user
separately.
3. The browser on the laptop of the Hot-spotVisitor
regularly polls the AP for new
info. In this case it will find a NetworkAn-nouncement
is available, at which point it
will download and delete the message and
show it to the HotspotVisitor.
Exit condition
4. The network announcement is broadcast to
all HotspotVisitors.
Table 2.10. Use case SendNetworkAnnouncement
2.2.3.3. HotspotLocationManager use cases
The table below describes the SetupAP use case in detail. It describes the actions the HotspotLoca-tionManager
performs in order to get his Mobidot hotspot working.
Use case name SetupAP
Initiated by HotspotLocationManager
Entry condition
1. The HotspotLocationManager has invested
in AP hardware from Mobidot.
Flow of events
2. The HotspotLocationManager receives the
AP hardware and places it in a strategic loc-ation.
3. The HotspotLocationManager intends to
connect the AP to the Internet. He turns on
the AP, which immediately starts installing
itself.
4. The AP checks whether it can get an IP ad-dress
by DHCP (automatic configuration).
5. The previous step failed and the AP brings
an Internet connection configuration web-
40

site online.
6. The HotspotLocationManager connects his
laptop to the Mobidot AP and starts his web
browser to visit this configuration website.
7. The HotspotLocationManager enters his
user credentials, which he received from his
ISP, which are needed to get an Internet
connection.
8. The HotspotLocationManager presses the
Save button to store the user credentials.
9. The AP then checks, using the new inform-ation,
whether it can get an Internet connec-tion.
10. The AP can successfully connect to the In-ternet.
It connects to the central Mobidot
system in order to download an installation/
configuration script.
11. The AP runs this script, which then starts
installing several needed packages. After
the installation phase has finished, the AP
starts configuring itself according to set-tings
which are stored in the central Mo-bidot
system.
Exit condition
12. The AP is setup and ready for servicing Wi-
Fi users.
Table 2.11. Use case SetupAP
2.2.3.4. RoamingPartner use cases
The table below describes the RetrieveUsageStatistics use case in detail. It describes how a roaming
partner retrieves the usage statistics of its users, who have roamed onto the networks of other Wi-Fi
providers.
Use case name RetrieveUsageStatistics
Initiated by RoamingPartner
41

Entry condition
1. The RoamingPartner activates the "Retrieve
Usage Statistics" function of the central
Mobidot system.
Flow of events
Mobidot database for usage statistics for all
users which belong to the RoamingPartner.
Exit condition
3. The central Mobidot system returns the us-age
information to the RoamingPartner.
Table 2.12. Use case RetrieveUsageStatistics
2.2.4. Defining the data model
The previous discussion dealt with various use cases which play a role in the system. These use
cases are the basis for the creation of the data model.
The use cases describe the system modifying or accessing certain information based on user input. A
model is a collection of such information which represents data about a part of the system that is be-ing
managed. The essence of the Mobidot infrastructure management system is to manage the vari-ous
parts of the system, which means to add, view, edit and delete information. From the use cases
we can find which models to manage: user accounts, roaming partners, hotspots, hotspot configura-tions,
firewall configurations, traffic shaping configurations, access points and firmware. Each of
these objects can be translated directly to a class in the class diagram. Another model also plays a
role in the management of the system, which is however not fully managed, but only read and de-leted:
the activation code. From the new account creation use case we can find that there is an ex-ternal
system used by customers in order to pay for their accounts. This external system adds these
payments in the form of activation codes in the Mobidot database, for the users to be able to activate
their accounts.
Besides the various classes, relations between these classes need to be expressed in the data model.
For example each hotspot has one or more access points and exactly one hotspot configuration. Each
hotspot configuration has exactly one firewall configuration and exactly one traffic shaping config-uration.
From all this information, the data model (the class diagram of the models) can be defined and de-signed,
of which the result is shown below.
42

Figure 2.28. The data model
43

Design hotspot With Opensource Tools

Design hotspot With Opensource Tools

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Design hotspot With Opensource Tools

Similar to Design hotspot With Opensource Tools (20)

Recently uploaded

Recently uploaded (20)

Design hotspot With Opensource Tools