WISPiab specifications: Difference between revisions

From WirelessAfrica
No edit summary
No edit summary
 
(12 intermediate revisions by 2 users not shown)
Line 8: Line 8:
It is meant to be commented and refined.
It is meant to be commented and refined.


Please also note the related document, specifying concrete tasks and job profiles:
[[Image:WISP task specifications.pdf]]


=Business Models / Use cases=
=Business models=


It is essential that the specifications be based on business model needs and real life use cases.
Discussion of business models: [[WISPiab_business_models]]


=High level architecture=


While these need to be refined and studied further (e.g. in the Wireless Africa II project),
Our currently suggested architecture splits the WISPiab hardware package into two components plus an option:
we list some main examples and key words here.


==Basic access models: Centralized and Mesh==
#Front Access Node
##
# Back end server (with or without screen, depending on existing ...)
##
#(Sub)Laptop as GUI admin (optional)


'''The entrepreneur wants to offer both centralized (aka infrastructure, hot spot, access point) and mesh models'''


==> We need to implement both Access Point Management and Mesh protocols
This seems appropriate based on the analysis of the SW specs in detail.


However, if test implementations seem to suggest reuniting the two tiers on one box, this is an open option, which might bring manageability benefits.


===Networks models in detail===


In particular, we need to take into account the following 3 network models, and the hybrid models between them.
[[Image:WISPiab elements horizontal with net small.png|thumb|left]]


In the following pictures,
=Software Specification / Feature list for the WISP-in-a-box product=


* red stands for business / entrepreneur owned and operated nodes,
==Shared functionality==
* blue stands for clients / users.


The line between the two may be transparent.
* All configuration etc to be accessible via browser based GUI
* ssh access




====Centralized model====
* Routing Protocols
** OLSR
** b.a.t.m.a.n.


[[Image:WISPiab models 1 centralized.png|thumb|left|Centralized model]]


The business/entrepreneur acts as a central access point.
Clients connect to this central point, e.g. with PCs, laptops, client nodes or VoIP phones.


====Inframesh model====


[[Image:WISPiab models 2 inframesh with clients.png|thumb|left|Inframesh model]]
==Front access node==


The business/entrepreneur operates an infrastructure mesh
* CoovaAP
Clients connect one or more of these nodes, as clients, e.g. with PCs, laptops, client nodes or VoIP phones.
** Authentication potentially with 2 options
*** Against itself / on acces node
*** Against back end server Radius


====Full mesh model====
CoovaAP will bring most of the following mandatory features for the front access node.


[[Image:WISPiab models 3 fullmesh.png|thumb|left|Full mesh model]]


The business/entrepreneur operates one or many mesh nodes.
* OpenSER
Clients fully particpate in that mesh, typically dedicated node hardware, less likely with PC/laptop, and even less with VoIP phones.


==Network Management==
==Back end server==


'''The entrepreneur needs to be able to monitor, manage, troubleshoot the network'''
==> We need network management SW plus interfaces, e.g. Nagios, Cactus, Webmin, ...
==Voice Services==
'''The entrepreneur wants to offerVoice services'''
==> We need to implement Asterisk, OpenSER or similar, plus additional management tools for these, if idnetified as needed
==Billing==
'''The entrepreneur wants to offer a variety of billing options, e.g. monthly subscription, time/voucher (airtime) based, free access'''
==> We need to implement billing and accomodate the various models on the box, in parallel (e.g. parallel free and closed segments, etc)
=High level architecture=
Our currently suggested architecture splits the WISPiab into two components:
#Front Access Node
##
# Back end server
##
This seems appropriate based on the analysis of the SW specs in detail.
However, if test implementations seem to suggest reuniting the two tiers on one box, this is an open option, which might bring manageability benefits
=Software Specification / Feature list for the WISP-in-a-box product=
==Base system, servers==
* The box has X / GUI
** all configuration etc via browser based GUI, user friendly


* apache
* apache
* php
* mediawiki
* mysql


**php
* ispconfig
**mediawiki
** webmin?


* mysql
* DNS server (DDNS, DynDNS)
* DNS server (DDNS, DynDNS)


Line 107: Line 76:
** Squid
** Squid


==Mail==
===Mail===
* Postfix / Courier
* Postfix / Courier
* webmail: squirrelmail
* Webmail: squirrelmail
* gmail syncing ?
* gmail syncing desirable
* Google server local? (--> talk to gmail, Kobus)
* Google server local? (--> talk to gmail, Kobus)


Line 117: Line 86:
** amavis
** amavis
** spamassassin
** spamassassin
locally stored updates


==(Auth, Access, Security, Billing)==


* ssh access
===Network management===
 
* Nagios
* Cacti
 
 
* Statistics
** awstats or similar
 
 
===Auth, Access, Security, Billing===
 
* Radius
* Radius
**FreeRadius
* OpenLDAP
* OpenLDAP
* OpenID
* OpenVPN
* OpenVPN
* GnuPG
* GnuPG


* Billing
** Business models: Prepaid – voucher
** Captive portal
*** Chilispot?


==Storage, FS==
===QoS===


* Redundancy
* QoS - details of this not clear yet - what layer? what tools?
** Distributed, many stages, “graded distributed system”
** iproute2
** MasterShaper?
** Wondershaper
 
 
===Storage, FS===


* rsyncing cron'd


* NAS –  iSCSI
* NAS –  iSCSI
Line 144: Line 126:
** SMB
** SMB
** NFS
** NFS
** rsyncing cron'd
* Redundancy - to be specified in more detail
** Would like to build distributed storage - “graded distributed system”


==(Voice over IP)==
===Voice over IP===


* Asterisk
* Asterisk
* OpenSER (--> Fraunhofer Institute, C written)SIP proxy-register
* OpenSER
--> it46
* billing integration
* billing integration
** Aradial?
** a2billing
** Cyneric?
 
* NAT issues / STUN
* AsteriskNow


==(Miscellaneous)==
===Miscellaneous===


* a Local Library of SW
* Local Library of SW
** Documentation
** Integrated Skilling / Education
* patch management
* patch management
* IpCOP
* IpCOP
* wikipedia local copy
* wikipedia local copy


* Content Filtering ? - discussion to be had with
* Content filtering ? - discussion!
 
* Integrated Skilling / Education
 
* Routing Protocols
** Quagga?
** OLSR
** b.a.t.m.a.n.
 
* X Server / KDrive


* QoS
** Traffic Shaping Layer 7
** MasterShaper?
* Virtualization (XenSource)
* Virtualization (XenSource)
** to be discussed - not deemed mandatory


=Hardware Specification / Feature list for the WISP-in-a-box product=
=Hardware Specification / Feature list for the WISP-in-a-box product=
Line 192: Line 165:
===General requirements for all elements===
===General requirements for all elements===


Wattage: 12 V
* Input: 12 V_dc
* Fanless
* Low power (< 8 W)


===Front access node===
===Front access node===
Line 202: Line 177:
===Back end server===
===Back end server===
external switch
external switch


==Hardware candidates==
==Hardware candidates==
Line 253: Line 226:


|- align="left" valign="top"
|- align="left" valign="top"
| Linksys WRT54G(L) ||  access node || cpu memory storage etc || power || wireless || USD 45 || comments
| Linksys WRT54G(L) ||  access node ||
System-On-Chip: Broadcom 5352EKPB
 
CPU Speed:200 Mhz
 
Flash size: 4 MiB
 
RAM: 16 MiB
 
Wireless: Broadcom BCM43xx 802.11b/g Wireless LAN (integrated)  || < 5 W (3.8 if optimized) || wireless || USD 45 || comments
 
 
 
|- align="left" valign="top"
| Accton / Open-Mesh ||  access node ||
(Atheros AR2315 chipset, 32MB DRAM, 8MB Flash, 1 ethernet port) = Meraki
  || power: ?, 5 V || wireless_ 60 dBm max || USD 45 || comments
 
 
 





Latest revision as of 14:28, 16 February 2009


Introduction

The following is our work copy of a specification / feature wish list for the WISP-in-a-box product.

It is meant to be commented and refined.

Please also note the related document, specifying concrete tasks and job profiles: File:WISP task specifications.pdf

Business models

Discussion of business models: WISPiab_business_models

High level architecture

Our currently suggested architecture splits the WISPiab hardware package into two components plus an option:

  1. Front Access Node
  2. Back end server (with or without screen, depending on existing ...)
  3. (Sub)Laptop as GUI admin (optional)


This seems appropriate based on the analysis of the SW specs in detail.

However, if test implementations seem to suggest reuniting the two tiers on one box, this is an open option, which might bring manageability benefits.


Software Specification / Feature list for the WISP-in-a-box product

Shared functionality

  • All configuration etc to be accessible via browser based GUI
  • ssh access


  • Routing Protocols
    • OLSR
    • b.a.t.m.a.n.



Front access node

  • CoovaAP
    • Authentication potentially with 2 options
      • Against itself / on acces node
      • Against back end server Radius

CoovaAP will bring most of the following mandatory features for the front access node.


  • OpenSER

Back end server

  • apache
  • php
  • mediawiki
  • mysql
  • ispconfig
    • webmin?
  • DNS server (DDNS, DynDNS)
  • Proxy / Cache
    • Squid

Mail

  • Postfix / Courier
  • Webmail: squirrelmail
  • gmail syncing desirable
  • Google server local? (--> talk to gmail, Kobus)
  • Spam/Virus control
    • amavis
    • spamassassin


Network management

  • Nagios
  • Cacti


  • Statistics
    • awstats or similar


Auth, Access, Security, Billing

  • Radius
    • FreeRadius
  • OpenLDAP
  • OpenID
  • OpenVPN
  • GnuPG


QoS

  • QoS - details of this not clear yet - what layer? what tools?
    • iproute2
    • MasterShaper?
    • Wondershaper


Storage, FS

  • NAS – iSCSI
  • File servers
    • SMB
    • NFS
    • rsyncing cron'd
  • Redundancy - to be specified in more detail
    • Would like to build distributed storage - “graded distributed system”

Voice over IP

  • Asterisk
  • OpenSER
  • billing integration
    • a2billing


Miscellaneous

  • Local Library of SW
    • Documentation
    • Integrated Skilling / Education
  • patch management
  • IpCOP
  • wikipedia local copy
  • Content filtering ? - discussion!
  • Virtualization (XenSource)
    • to be discussed - not deemed mandatory

Hardware Specification / Feature list for the WISP-in-a-box product

To be spec'ed after completion of SW specs.


Minimum requirements

General requirements for all elements

  • Input: 12 V_dc
  • Fanless
  • Low power (< 8 W)

Front access node

Network interfaces 2 minimum, maybe more


Back end server

external switch

Hardware candidates

Table 1: Table title
Name candidate for CPU Memory Storage Power Wireless Cost Comments


ASUS EEE PC server?

ASUS® EEE PC 700-W - Intel® 900Mhz Pentium®M ULV, 512MB DDR2 Memory, Internal 2GB SSD Based Hard Drive, Intel® 910GML Chipset, 7" 800x480 LCD, 10/100 LAN, WiFi b/g, SD Card Slot, 3xUSB 2.0 / ASUS EEE PC 4g with 4 GB SSD / ASUS EEE 900 with 1 GB RAM, 12 GB SSD

power: ? - ? comments
dataevolution.com decTOP etc server?

Memory 128MB SDRAM 10GB HDD

power: ? - ? comments


FON(ERA) access node
CPU: MIPS 180 MHz 
Memory: 16 MB ram 
power wireless EUR 40 comments


Inveneo Outdoor WiFi Access Point access node, server (?) ??? ask Inveneo power 802.11 b/g

Athenos chipset Peak power: +24dBm (250mW) || Single Radio: $469 USD* Dual Radio: $659 USD* || incl antennas, install kits, outdoor ready

Inveneo Hub server server

1.2GHz VIA C7 nanoBGA2 Fanless VIA CN700 North Bridge VIA VT8237RP High-bandwidth Vlink Client South Bridge 51MB standard, 1GB optional One RS-232C serial port (DB-9) Four USB 2.0 ports (two in front, two in back)

< 20 W - Price: starting at $$785 USD* incl many things, see site :)
Linksys WRT54G(L) access node

System-On-Chip: Broadcom 5352EKPB

CPU Speed:200 Mhz

Flash size: 4 MiB

RAM: 16 MiB

Wireless: Broadcom BCM43xx 802.11b/g Wireless LAN (integrated) || < 5 W (3.8 if optimized) || wireless || USD 45 || comments


Accton / Open-Mesh access node

(Atheros AR2315 chipset, 32MB DRAM, 8MB Flash, 1 ethernet port) = Meraki

power: ?, 5 V wireless_ 60 dBm max USD 45 comments




Meraki outdoor access node
Bootloader: RedBoot
CPU: Atheros AR2315
CPU Speed: 180 Mhz
Flash size: 8 MB
RAM: 32 MB 
Power consumption: 12W max; 3W typical
   * 200 mW (23dBm) peak transmission power*
   * Enhanced receive sensitivity
   * External RP-SMA connector
   * 802.11 b/g (1-54 Mbps)
   * 2dBi omni directional antenna included
USD 49/99 note EULA issues!

http://www.mini-itx.com/

Mini-ITX / VIA / LEX / Jetway etc access node, server varies power wireless cost see http://www.mini-itx.com/ http://www.via.com.tw/en/products/mainboards/


Soekris boards access node, server (?) cpu memory storage etc power wireless cost comments


Ultra Mobile PCs / sub laptops becoming a valid candidate as Backend/server component?

many candidates with differing specs, need to check out and test:

   * OLPC
   * eMate 300
   * Classmate PC
   * Linutop, Geode LX -based computer
   * Longmeng or Dragon Dream, China
   * Tianhua GX-1C, Sinomanic in China
   * VIA pc-1 Initiative, VIA Technologies digital divide program.
   * Zonbu, a low-cost desktop computer
   * Eee PC, ASUS and Intel - watch!
   * Clio NXT.
   * InkMedia MC, another low-cost subnotebook
   * Elonex_ONE, subnotebook, expected to be £99


??? - typically low, 3 Watts for OLPC-X01 typically built in

EUR 250 - 400

   * OLPC
   * eMate 300
   * Classmate PC
   * Linutop, Geode LX -based computer EUR 280
   * Longmeng or Dragon Dream, China
   * Tianhua GX-1C, Sinomanic in China
   * VIA pc-1 Initiative, VIA Technologies digital divide program.
   * Zonbu, a low-cost desktop computer
   * Eee PC, model900 = EUR 400, model 4g = EUR 300
   * Acer, Q2 2008, approx EUR 250 ?
   * Clio NXT.
   * InkMedia MC, another low-cost subnotebook
   * Elonex_ONE, subnotebook, expected to be £99


needs testing and verification as candidates





WRAP boards access node, server (?) cpu memory storage etc power wireless cost comments

Solar part

Solar Kit to be spe'ed after HW power is known