Difference between revisions of "DigI:Processes and Technology"
(→7) Data collection)
(→7) Data collection)
|Line 169:||Line 169:|
Revision as of 08:52, 13 September 2019
Processes and Technology
- 1 Processes and Technology
- 1.1 Processes
- 1.1.1 1) Village Web sites Yeboo.com
- 1.1.2 2) Preparation of LNCC and RPI
- 1.1.3 3) Configuring, testing, sending and repair
- 1.1.4 4) Reporting
- 1.1.5 5) Voucher sales
- 1.1.6 6) Follow up and responsibility of the kiosks
- 1.1.7 7) Data collection
- 1.1.8 8) Digital content managing
- 1.2 Technology issues in DigI
- 1.1 Processes
The DigI team consists of 11 partners from 8 countries. In order to collaborate efficiently, we have established the overall process flow. In this document we'll only describe the technical parts.
1) Village Web sites Yeboo.com
User story: A user finds a Wifi network named BasicInternet. With the tablet or his/her own Smartphone, the user connects to the Wifi network. He is redirected to the Free/Voucher selection (see Figure 1.1). By selecting "Free Basic Internet", the user will be redirected to Yeboo.com using the default browser, and specifically to the health information site, being /var/www/yeboo/health_information_dashboard.php on the RPI (see Figure 1.2).
Selecting voucher access, the user will enter a 4 digit username (e.g. 1xzu) and a 4 digit passwd (e.g. klum), and then just sees "success" (or whatever).
- n.n. (Maghsoud, Hamed, Iñaki) to implement login page. The login page exists both in http:// and https:// format, to allow a redirect from a video on e.g. Youtube.com to the voucher login page.
- Antton to establish the Username/password (4,4) pairs. For testing we'll get 100 pairs each for 1h (username: 1...), 4h (username: 4... and 24h (username: d...). All are valid for 6 months. That gives 300 in total. Question: How can we link them to "all our" TZ boxes? - In addition, please describe in short terms on how to create vouchers.
- Hamed to reconfigure our LNCC (RDB52G) to work with the vouchers.
- Wisam to test a 1 h voucher on one of the LNCCs.
A) Yeboo Web site development: Maurice. The Web site shall have a common directory for all villages, and one specific directory (or a configuration file) for the specific villages. Thus, it will allow us to make one SD-card for all villages, and just "set the village name or redirect the Web server for that village. As an example, yeboo.com points to /var/www/yeboo/index.htm on the RPI, and this index.htm file is a copy of index_izazi.htm, index_migoli.htm, index_esilalei.htm ...
1.1 Yeboo site implementation
Hamed and Wisam . Using the access to the main server set by Maurice to download the files created to each village and to reinstall the specific village index.htm on the RPI and link it with the locally used LNCC.
The process is documented on OwnCloud (steps described in Owncloud = DeviceConfiguring = RaspberryPi_Villageserver)
1.2 FeedBack on information usage
Maurice shares frequent results on the login to the village website, surveys, and questionnaires, ... etc with Danica for analysing, creating, and publishing KPIs.
To be updated from Maurice
A) describe how feed-back and what is measured,
B) automatic process, published on owncloud
1.3 Feedback on data usage, and access in the various locations
- Josef and Maghsoud.
developed a monitoring.basicinternet.org to major the frequent usage traffic, data usage, active hot-spots, and number of users in specific period of time.
To be done:
- Easier architecture: one /var/www/yeboo/common where all common files are located
- logical representation of village: Izazi, Migoli, ....
- Updating the existing running RPI in Izazi, and Migoli
Next steps: Maurice to provide
- a proposal on how these steps can be performed
- the village platform feedback and what is measured
- automatic process, published on owncloud
2) Preparation of LNCC and RPI
User story: In each village, the core of the network is the Local Network Control Centre (LNCC) and the Village server, being a Raspberry PI (RPI). The LNCC gets a universal configuration, making it possible to be swapped by another device. Internally, the name of the LNCC (e.g. RDB52G-04) corresponds to a specific certificate (e.g. Tanzania04), which allows the secure communication to our control centre. The steps we perform include the installation of a RPI as the village server, displaying Yeboo.com from the local SD-card within the RPI. Remote configurability of both LNCC and RPI are installed, to ensure that we can later on access the LNCC and the RPI in the field.
- Maghsoud: What is the advantage of using a specific certificate per LNCC?
2.A) Conversion of Web content to Raspberry Pi (RPI)
Platform development happens on Yeboo.com. From there, the specific files (both phpmyadmin, videos, scripts and other files) will be downloaded to laptop and transferred on an SD card in the RPI. Detailed steps are on Owncloud (steps described in Owncloud = DeviceConfiguring = RaspberryPi_Villageserver)
The RPI is configured with Apache2, thus having a Web server to display the Web pages being available on /var/www. The above steps allows the Raspberry PI to act as a village server and displays the Yeboo.com pages locally.
- Configuration of the LNCCs according to the DigI project certificates and filtering files.
for documentation, see DigI:Village_server
- documented the process on OwnCloud (steps described in Owncloud = DeviceConfiguring = LNCC RBD52G)
- download a copy from Yeboo.com (Web server) and install on RPI
- linking each village server (RPI) to the local LNCC used
- documented the steps for download, and link of the RPI on OwnCloud (steps described in Owncloud = DeviceConfiguring = RaspberryPi_VillageServer)
- download a copy from Yeboo.com (Web server) and install on RPI, (steps described in Owncloud = DeviceConfiguring = RaspberryPi_VillageServer)
2.B) Remote configurability of both LNCC and RPI
Implementation by Hamed with support from Maghsoud.
Allows us to configure the RPI through the LNCC from "anywhere in the world" using maincorerouter.basicinternet.org. The LNCC, once connected to a network, will announce itself to our central server. Our central server will provide the LNCC with an IP address Testing should be performed in the Labs at Kjeller, or/and at Muhas (TZ). Testing includes the IP address of the LNC.
- Maghsoud: When we have configured and tested, and then send to TZ, will the IP address change? How can we establish a link between the IP addresses (seen on our central server) and the MAC address of the LNCC?
- RPI configuration
- Documentation of the remote configurability process
3) Configuring, testing, sending and repair
User story: for each village that has been selected to be connected, specific set of MikroTik equipment must be ordered, configured, tested, and shipped to be deployed in the site/ village
3.1 Order the needed MikroTik equipment
- Registering of the purchased equipment on its-wiki (https://its-wiki.no/wiki/Equipment => add equipment) the registration includes the device class, type, model, purchase date, Identifier (Mac address, IP, phone), the project related to, and the place where the device is
- Configuring the equipment (LTE, LNCC, and Village server) and in case of extension spot (Sector antenna, Point reception, and Local hot-spot) by removing the manufacturing configuration and installing the specific configuration files used in the project in order to get better control and safety.
- All the equipment must have a user name and password for security reasons. The process of setting the user name and the password is documented on OwnCloud=>DeviceConfiguring=> username&password
- The configuring processes for the various MikroTik devices are documented on OwnCloud (steps described in Owncloud = DeviceConfiguring = ....)
- Test the equipment through connecting the designed information spot and insure the availability of the BasicInternet Network/ wifi
- document the test plans for each village on OwnCloud (steps described in Owncloud = DigI-Vision 2030 = Village_installations=...) and be sent to the local representer for installation work
The Mikrotik / information spot equipment will be shipped via an international carrier from the headquarter in Norway to the DigI team presenter in TZ, DHL is preferred.
- For now, Bernard is the person in charge for receiving the equipment in TZ and go through the clearance process.
3.3 Test on arrival
User story: After receiving the equipment from the customs office, an initial test will be accomplished for the equipment set, usually in Dar Al-Salam, to figure out if the are working as expected before sending them to the field. That test is normally done by Felix and with the Test plans document has been created for this spot.
Initial testing -
- LTE Antenna: insert SIM card, connect cables, POE, power source test, and check that lights are working. A detailed connecting and testing document is available on OwnCloud (steps described in Owncloud = DigI-visjon2030 =Village_installation= ....)
- LNCC router: connect the Internet wire coming from the LTE to port 1 on the LNCC, connect the LNCC to power source, and check if the power light is lightning green on the back side, in order to establish a local network /wifi.
- Village server/ RPI: connect the RPI to electricity using the charger, normal Samsung mobile charger, and check if the power light is blinking/on. Then, connect the PRI to port 2 on the LNCC using an Internet wire.
- When all the equipment are well connected to each other and the electricity the person should check on his mobile/ Tablet the accessibility of the Basic Internet network.
Success: I can connect, next step implementation in the site and testing 3.4.
Failure: I can't connect, go to step 3.5.4.
- Test the village platform by opening your browser and open the web-site yeboo.com, or what have been specified for the specific village your are testing its spot :
Success: I can reach the site and the videos, next step 3.4,
Failure: I can't reach. the reason could be:
a) check the RPI connection to LNCC on port 2, and electricity, if that is well connected.
b) check with Wisam or Hamed if the RPI is identified to work with the used LNCC
c) check with Wisam or Maurice that the main server of the village platform is working
d) open the RPI case and check the small lights beside the USB, red and green lights, if they aren't working that means no power and Internet are reaching the RPI otherwise if reason a) was checked well that indicates the RPI is dead and should be replaced with a new one take contact with Wisam
- If the information spot providing wifi and the village platform is accessible, then, the set will be shipped to its final destination, the targeted village.
3.4 Testing in the field
After arrival at the site, connect the equipment and perform a functionality testing before raising the pole. Connect the equipment in the same way in step 3.3 and repeat all the tests to ensure getting the connection to the Basic Internet network and the village platform.
3.5 Error testing in the field
When the equipment (LTE, LNCC, Village server) are deployed in the field, the user should be able to perform simple steps to check the configurability. Through our central equipment, we are able to connect remotely to the LNCC and the RPI (if they are on the network).
A user being at the the site can test the following:
- 3.5.1. I look for Wifi "BasicInternet", and connect to Wifi.
Success: I can connect, next step 3.5.2.
Failure: I can't connect, go to step 3.5.4.
- 3.5.2. The user opens a browser (e.g. Chrome) and connects to Yeboo.com (or Yeboo)
Success: The health information page (see Figure 1) is shown, and the hotspot works as planned
Failure: Web site not found. Goto step 3.5.3.
- 3.5.3 In the Web browser, type google.com.
YES: Google is working, network access. Test Yeboo.com. If still not connected to the health site, probably the Raspberry PI is dead, or a confirguration team. Contact the BasicInternet Team
NO: if google.com is not shown, then we have no network access. Potential sources:
- No credit on the SIM card,
- Devices not working,
- Cables unconnected/loose
- 3.5.4 Check the equipment: Is the light blinking at the back of the LNCC?
NO: no power, or LNCC is dead.
YES: Lights are blinking. Reboot the LNCC: disconnect the power, reconnect and see if the lights come up. Check if you have electricity. If the LNCC still does not work, we need to replace (step 3.6)
Question: What happens if the RPI is "dead", what will the user see when typing Yeboo.com?
3.6 process for replacement
Get into contact with the Foundation, Wisam or "email@example.com"
Make sure that all LNCCs and the corresponding RPIs are connect to the network, either in the villages
Check out: preferably through WhatsApp Info +47 2228 42.... (business WhatsApp)
User story: Goal of the DigI project is to report usage of the local resources from the health information spot. This reporting has two aspects, the reporting from the LNCC on usage and the specific reporting from the RPI
4.1 LNCC reporting
Josef and Maghsoud:developed a monitoring.basicinternet.org to monitor the frequent usage traffic, data usage, active hot-spots, and number of users in specific period of time.
4.2. RPI reporting
Maurice: using the main server to get feedback from the village servers and generate a frequent report on Yeboo.com visits, number of users, videos watching, quizzes visits, and location users.
Danica: to use the generated reports to create KPIs, public reporting documents.
5) Voucher sales
User story: every user connecting to the Wifi network BasicInternet will have free access to all the local content, health videos, governmental sites, and text and picture website. In case the user would like to open, download, upload videos to the Internet, there will different direction. Figure 1.1 shows the starting page with two directions to the free content and to the paid browsing. The village administrator of the information spot will control the local distribution and reporting of the vouchers needed for the paid navigation.
Iñaki and Antton: create the voucher system platform and provided a detailed walk through document on using and generating the vouchers https://vouchers.danz.eus/.
Detailed walk through document on how to generate and manage the vouchers is available on Owncloud= YebooServer=DigIVouchers_platform_easy_walk_through
Antton has finished the voucher administration platform
Next steps: Antton:
- Integrates both the voucher administration platform and the AAA authentication system.
- Guidance on the system usage and voucher generation for the local administrator.
5.2Sales of vouchers
Locally the village information spot administrator will have the responsibility to manage, distribute, and report the vouchers flow to cover the needed demand and to frequently update the SIM card subscription accordingly.
After the integration of the voucher platform and the AAA authentication system the local spot manager will get a training on using the voucher system.
6) Follow up and responsibility of the kiosks
All the information spots are in need for local administrator who follows the spot functionality, wifi accessibility/ availability, equipment maintenance (usually the solar panel if it used), vouchers selling, tablets usage, .. etc. This person will have full responsibility for the spot under the supervision of the DigI project team.
Bernard: has the responsibility of receiving the information spot technical equipment and the clearance process.
Felix: running the initial needed tests, step 3.3, shipping the equipment to the final destination, controlling the tests and the deployment at the field. Finding with the local administration the person to be in charge of the kiosks daily operation.
- Painting walls and producing posters with "how-to connect and assess information".
- Q: What about the fixed tablets? Did we end on the tablets being in the hands of the kiosk operators?
- How is the person in the kiosk being paid today (without vouchers)?
- Will be the mobile accessories selling, mobile maintenance, shop area renting, or public toilets considered business models /sources for generating income for the spots?
7) Data collection
User story: when accessing the Basic Internet wifi the users will have free accessibility to the local health videos and messages. Data collection on the knowledge uptake of the health messages is running through the entire project for evaluation, KPIs creating, development, demand recognising, and academic work.
8) Digital content managing
User story: establishing the right users involvement, reporting publication, and global awareness of the project work needs frequent updated digital content on both the project
A) internal system,
C) social media,
D)academic /technical publications.