Pages: pp. 291-303
Abstract—Remote access to physical laboratories for education has received significant attention from both researchers and educators as it provides access at reduced cost in sharing manner of real devices and gives students practical training. With the rapid growing of wireless technologies, it has become an essential of learning to have the hand-on experience on wireless networking for the proliferated number of students in engineering. Some of current implementations for wireless networking are either using simulations, which lose the reality, or too complicated for undergraduate students to control experiments. In this paper, we present a practical online laboratory platform, Web-based Wi FiLaboratory (WeFiLab). WeFiLab mainly focuses on providing students hand-on experience of doing experiments on real devices through webpage anytime anywhere. It uses the structure of two-level operations, which facilities increasing the scale of wireless devices and allows WeFiLab to be extended to more complicated operations. The schedule schemes of WeFiLab let more students share and make efficient use of wireless devices. A prototype of WeFiLab has been implemented and used successfully as complements for an undergraduate course for two years in a university. In total, 315 computer science students attended the evaluation.
Index Terms—Wireless networking, remote laboratories, web-based laboratories, e-learning
Networking technologies have been playing irreplaceable roles in today's global village. With Internet, information at one corner of the world can instantly travel to another corner of the world. In particular, Mobile Internet which links together mobile users has contributed an essential part to this achievement. Recent years have witnessed an explosive growth of Mobile Internet access fueled by the increasing popularity of WiFi and the worldwide deployment of high-speed wide area wireless networks such as the third-generation (3G) wireless cellular networks (e.g., HSPA). On the other hand, proliferation of hand-held multimode smartphones and other wireless devices has significantly stimulated the use of wireless Internet, e.g., the city wide high-bandwidth low-priced WiFi networks. As the popularity of wireless networking increases, the industry and academic have accumulated a huge demand for people with the necessary skills to design and create practical networking facilities.
For science and engineering students, laboratory plays a crucial role in their undergraduate degree courses because the laboratory activities provide the hands-on problem solving skills and necessary experience for adopting their knowledge in real-life contexts [ 1], [ 2]. With enough laboratory experience, students can put concepts into practice to consolidate their knowledge learned during lectures. Nevertheless, running laboratories creates high financial burden to colleges or universities because they are expensive and resource intensive. So, traditional laboratories have following shortcomings. First, a number of qualified staffs are required to manage the laboratory and assist the conduct of experiments. Second, constant budgets are needed for continuous equipment maintenance and renewal. Third, laboratories are only accessible during opening hours for a very limited amount of registered students. Nowadays, mobile learning that not being tied to a particular location has become the next generation of e-learning [ 3], but the traditional laboratories have failed to meet this demand. Due to these reasons, a plenty of previous efforts have suggested various types of online laboratories which allow students to access via Internet to share the computer controlled equipments [ 4], [ 5], [ 6], [ 7], [ 8], [ 9].
Generally, there are mainly two approaches for online laboratories: virtual laboratories and remote laboratories [ 10]. Virtual laboratories are based on software to simulate experiments environment, while in remote laboratories experiments are conducted and controlled remotely through Internet, using real components or devices. One of the very important features of virtual laboratories is to let the students learn from failures without causing any real damages. However, virtual laboratories limit students learning activities due to the missing of reality [ 11]. While remote laboratories are designed to provide real-time experiments to students via Internet, gives students the opportunity to work on the remote real devices, which will eventually provide students real laboratory experience.
However, our literature review results show that most of the current remote laboratories are too complicated for network beginners as students may need to write programs/scripts to conduct experiments. Among reviewed projects, we also analyzed their web laboratories and found that Java, Flash, or ActiveX are frequently used tools for User Interfaces (UIs) to link the laboratory equipments to the users. These tools can be utilized to build powerful and sophisticated systems, but they are also too resource hungry and computation intensive to be employed on some resource limited devices such as mobile devices.
To resolve the above-mentioned problems, we present our web-based WiFi (IEEE 802.11) Laboratory platform— WeFiLab. We believe that WeFiLab covers both beginning and advanced learners as it enables students to learn, produce the network design, and conduct experiments about WiFi networks through the web browser via Internet anytime anywhere. All these learning and experiments activities are conducted on real wireless devices.
The WeFiLab system has been successfully used as the complement for the course of CS4284- Mobile Computing [ 12] and the course CS4289- Pervasive Computing for two years, which totally included 315 undergraduate computer science students, in City University of Hong Kong. The case studies' results show that WeFiLab not only improve students' understanding about the WiFi but also provide them with adequate hands-on experience about WiFi network design.
In short, our main contributions are threefolded:
The rest of this paper is organized as follows: Section 2 provides some background and related works about networking laboratories. Section 3 describes the details of the WeFiLab design including the structure of two-level operations, roles and capacity of WeFiLab. Section 4 introduces some experiments that we designed based on WeFiLab. Section 5 is the implementation of the prototype of WeFiLab. And two study cases for evaluation of WeFiLab including the Outcome-Based Teaching and Learning (OBTL) scheme are introduced in Section 6. In Section 7, we discuss the current challenges problems and give some future works about WeFiLab. Finally, Section 8 is the conclusion of the paper.
In education, simulation software is seen as one way of imparting practical knowledge by allowing students to conduct experiments on the computer simulating all the steps, which a student would take in real laboratory while performing the experiments [ 13]. Compared to the cost and time involved in setting up an actual laboratory, network simulators are considered as a fast and inexpensive way to provide students with hand-on training on networking. Graphical User Interface is often provided to allow users to configure and visualize the simulation environment and to display simulation result. There are a variety of network simulators, ranging from the very simple ones to the very complex ones [ 14]. Usually, the simple ones enable a user to represent a network topology, specify the nodes (e.g., switch or router) on the network, the links between those nodes and the traffic between the nodes. On the contrary, the complex ones allow the user to configure everything about the protocols used to handle network traffic.
Some educators argue that although simulation studies can make students meet the requirements of the course and enable him to complete it satisfactorily from the point of view of the university that offers the course, the element of reality will be missing, which will causes students to become spectators rather than a learners [ 11]. Involvement of body and mind in a real experiment yields rich dividends of knowledge gained by the experimenter. Remote laboratories take the advantages of real laboratories while also extend the capability of a conventional laboratory by increasing the number of times and places students can perform experiments [ 15], [ 16] and extending its availability to larger groups of students [ 17]. In the last years, significant research effort has been done by teaching institutions on the development of remote laboratories for a wide variety of engineering courses. Authors in [ 18] described the history of some of these changes and explored in some depth a few of the major factors influencing laboratories today. Authors in [ 19] have developed an online RFID laboratory. Students can access to technological resources through the web technology to apply appropriate configurations to the system, conduct experiments using RFID technology, and perform statistical analysis on the acquired data. Bochicchio and Longo [ 20] described the authors' experience in the development of a reusable framework for remote laboratories, which has been adopted as a case study for IT engineering classes. Authors in [ 5], [ 6], [ 7], [ 8] share their experience on building a networking laboratory, in particular, DeHart et al. [ 8] have built a remotely accessible network testbed of high perforce routers for users from the naive to expert. Emualab [ 4] is an online virtual and remote laboratory which has been used for several universities. It provides both virtual nodes and real testbed for both wired and wireless networks. One of the important features of Emualab is that it uses the same directives as the ns2 simulator for setting up real nodes and connections. The main difference between WeFiLab and Emulab is that WeFiLab tries to let students conduct experiments through mouse events and view the responses immediately on the webpage, while Emulab requires users to write complicated scripts to control experiments.
While a lot of efforts have been paid to develop web-based frameworks for various uses of remote laboratories, many out of them adopt Java or ActiveX or other technologies that require additional plug-ins for web browsers. Authors in [ 21] pointed out the shortcomings of existing implementations and indicated that emerging internet technologies can assist in overcoming these shortcomings. Nevertheless, these technologies aim to serve end users with powerful terminals. WeFiLab specifically adopts Ajax, which compatible with most of the current popular standard web browsers. The main underlying technology provides true anywhere anytime wireless networking laboratories.
Following the footsteps of previous successful works, we provide one step further system WeFiLab, which aims at teaching and learning on wireless networking. At current state, the system only concerns about 802.11b/g (WiFi). The reason for setting WiFi off first is that it is so far the most commonly available wireless networking technology surrounding us. We assume that the system users are both students and teachers/tutors of a course in a university/college. Students can gain instant access to the WeFiLab for hands-on training anytime anywhere so as to consolidate the knowledge they have already gained from lectures. Teachers/tutors can design experiments, assess students performance, and review students' records, e.g., operation history, mistakes they have made and their experiments results. All these information will help teachers to understand students' performance and coordinate their teaching activities.
The design of WeFiLab focuses on encouraging students to be fully involved into the experiments on real wireless devices. It hides the details of the complex configurations on wireless devices from users through the two-level operation structure, so students can concentrate on their experiments, which are conducted completely on webpage. WeFiLab also allows the administrator to add new wireless devices whenever needed to support more students.
The illustration of WeFiLab architecture is shown in Fig. 1a. The whole WeFiLab system consists of a server, the wireless nodes array, and edge client terminals. The corresponding logical components of the whole system are depicted in Fig. 1b.
Figure Fig. 1. WeFiLab architecture.
Clients. All students, teachers, and tutors can be users of the WeFiLab. Web browsers running on their terminals connecting them to the WeFiLab are the clients of the system. These terminals can be PCs, laptop computers, and even mobile devices, e.g., mobile smartphones.
Server. As a bridge between clients and wireless devices, the server plays two important roles in the WeFiLab platform. One is to act as a webserver to provide Ajax-based user-friendly GUI for enabling sufficient interactivity for students and teachers/tutors. Another role of the server is to act as a gateway to relay control and response messages between clients and wireless devices. Building on top of Ajax, the webserver allows every user with capable web browsers to log on and use the provided functions without additional plug-ins even on mobile phones. And using the structure of two-level operations, server enables users to control the assigned wireless devices through web browser remotely. All the operations are done on the webpage, students needn't write any scripts/programs. The database equipped along with the webserver facilitates the control of users' sessions and wireless devices. It can also store all the useful records/data, e.g., operation histories and captured frames produced during the experiments, for students' and teachers' further study and analysis.
The wireless nodes array. The wireless nodes array contains a group of off-the-shelf wireless devices (routers), which all the experiments of students are actually carried on. These wireless devices are shared among all the users of WeFiLab. All these devices are connected to the server through Ethernet for the exchange of control and management messages. The Ethernet can provide efficient communication between wireless devices and server without influencing the wireless communication among wireless devices. Each wireless device receives instructions from the server and sends back the response/results upon finishing the tasks. These wireless devices can work under different modes according to students' experiments, such as access point (AP)/STA, ad hoc 1 mode and so on. Particularly, there are also some devices working under the monitor(sniffer) mode, which can capture all the wireless frames in the air and filter the results based on students' needs.
Some typical logical components of WeFiLab in Fig. 1b are described as follows:
Session control. The WeFiLab system will create a session for each login user. Then, all the users' operations will be tracked for further analysis. Especially, each session has a session timer, which will be expired after MAX_SESSION_ TIMEOUT. The system will retrieve all resources, e.g., wireless devices, allocated to the user once the user's session expired.
Feedback module. The Feedback Module is for pushing messages from server to clients. These messages include any updates of wireless devices' configuration, status and responses after users' operations, as well as teachers'/tutors' suggestions during the experiments.
Schedule control. The Schedule Control allows students to do the experiment through two different schemes: Reservation and First-Come-First-Served (FCFS). The details of the two schedule schemes are discussed in Section 3.4.
Device control. The main tasks for this component are the wireless devices discovery and devices maintenance. It can either discover wireless devices through continuing listening on a predefined ports, or broadcast query packets for proactive discovery. After devices have been found, Device Control will further check the status of each device periodically, e.g., the working mode, current channel, Server Set IDentifier (SSID), IP address, etc. Based on these information, the system can assign available devices for the experiments according to users' requests.
Command control. Command Control module is mainly responsible for the interpretation of commands between the two-level operations. The details are provided in Section 3.2.
The WeFiLab uses the structure of two-level operations to provide communication between clients and wireless devices. Fig. 2 gives an example of how the two-level operations work when a client wants to connect one wireless device to another under AP/STA mode.
Figure Fig. 2. An example of two-level operations.
The structure of two-level operations is explained as follows:
Under this structure, the server is responsible for interpreting these two kinds of operations (commands) between clients and wireless devices. Through the two-level operations, students just need to focus on the first-level operations which are independent of specific wireless devices, without bothering the detailed operation commands on the specific platform wireless devices. As the client's operations of WeFiLab are GUI based, the first-level operations are mainly triggered by mouse events rather than scripts.
When a student needs to use some wireless devices to do experiments, he/she must lock those devices first to avoid unnecessary operation collisions that one device is used by more than one student simultaneously. After receiving the LOCK request from a client, the server will check the status of that device and do some necessary configuration to the wireless device before responding to the client.
After locking enough wireless devices successfully, students can conduct their experiments. These experiments can be designed by the teachers or based on the students' own idea. Using the two-level operations provided by WeFiLab, students can deploy a wireless network, capture wireless frames, send out specified packets and any other operations. Students can also change the configuration of each locked device, such as the SSID, current channel, the working mode, and so on. Section 4 will introduce some basic experiments that we designed based on WeFiLab.
The structure of two-level operations also simplifies the maintenance of wireless devices. When students are doing experiments in WeFiLab, the status/configuration of the locked devices may be changed. In light of this, the server is responsible to recover the configuration of wireless devices automatically by using WD_RECOVER command to let devices reset all the configurations when these devices are released. So, the other students can lock these devices for experiments without caring about the previous users' operations. At the same time, the Daemon Process running on the background of each wireless device also reports its status to server periodically. The server would response to each device after checking the report. Should there be any unexpected problems, i.e., wrong status or haven't received the report/response for a period, the device will recover the configuration or reset the network module of wireless devices if needed.
Under the structure of two-level operations, the scale of WeFiLab can be easily extended. New wireless devices can be added to the wireless nodes array anytime without changing the first-level operations.
A positive experiment environment for learning needs different roles to work out together, e.g., students, teachers, tutors, other support stuffs, and so on. As a system to facilitate students learning on wireless network, WeFiLab tries to involve both students and teachers/tutors during experiments. Besides that each student can do their own experiments, view their operation histories and results, WeFiLab also allows teachers/tutors to view students' operation histories, experiment results, and so on, which will give them more knowledge about students' performance and where the common weakness is for all students.
Besides, some experiments may need several students to cooperate together. WeFiLab also allows students to form a group with a selected group leader to coordinate the whole experiments.
We believe that effective learning during experiments should be bidirectional between students and teachers. So, in addition to grading students' performance on experiments and questions, teachers/tutors can also give comments to students based on their performance on experiments and their submitted answers/reports. Besides, the WeFiLab offers students chances to give feedback about their experience of doing experiments and using the system to teachers and tutors.
The capacity of WeFiLab is defined as how many students can be allowed to do experiments during the same time period. Generally, it depends on the number of wireless devices and what kind of experiments students are doing.
Besides taking the advantage of the diversity of students' profile of diversity, WeFiLab also uses the lock restriction on wireless devices and the schedule scheme to ensure the capacity for students.
Students' diversity. WeFiLab allows students to access at anytime anywhere as long as the Internet service is available. The web-based property of WeFiLab enables students do not need to do the experiments during course/tutorial time. Furthermore, students are also not required to do the experiments in the campus. Actually, according to our observations on the records of the system, more than 37 percent login records are outside the university campus and about 32 percent students indicated in their feedback that they do the experiment at their home. Because students can access WeFiLab at anytime anywhere, their login activities are distributed in a large range during the period available for their experiments. These diversities can increase the capacity of WeFiLab to some extent. We will give more detailed information about these diversities in the Section 6.3.
Lock restriction. According to our observations, for wireless beginners, 2-3 wireless devices are almost enough for most experiments about wireless networking. And most of experiments can be finished in about 10-20 minutes if everything goes on well. To avoid that some students may lock devices too long or forget to unlock them after finishing experiments, the WeFiLab system will retrieve the devices after being locked for more than MAX_LOCK_PERIOD (current setting for WeFiLab is 60 minutes, which is enough for students to finish an experiment). Furthermore, when a student login WeFiLab, a session will be created for this user on the server. And the users' session will be expired after MAX_SESSION_TIMEOUT (current setting for WeFiLab is 30 minutes) since their last activity. The expiration of users' sessions will also trigger the server to retrieve all the devices locked by that user.
Schedule scheme. Considering that students may spend more time on their experiments, WeFiLab provides two schedule schemes for students to lock devices and do experiments:
For those experiments that only need to capture some wireless frames or scanning the environment, sometimes students don't need to lock any devices explicitly. They just need to send a request to server. The server will coordinate all these kinds of requests, capture the desired frames, and send back the results to corresponding clients. Besides, each capture request usually takes only several seconds at most, so many students can be served at the same period with a few wireless devices. The FCFS Scheme will be enough for this kind of operations.
For those experiments that students need to lock several devices to do experiments, WeFiLab can use the Reservation Scheme (scheduled) to ensure that each student have enough time (e.g., a slot of 60 minutes) to do their experiments, and at the same time WeFiLab also uses FCFS Scheme to allow those students who failed completing experiments during the scheduled slot to have more chance to do their experiments.
Finally, as to the bandwidth of WeFiLab, the Ethernet connecting the wireless devices to server can be 100 Mbps at least, so the bottleneck that can influence the throughput of WeFiLab is the bandwidth from clients to server through Internet. Due to the structure of two-level operations, most of messages exchanged among Clients, Server and Wireless devices are short commands with only few bytes (within 4 bytes in current implementation), and sometimes one command of the first-level operation can be translated to several commands of the second-level operations. So, the communication overhead needed for the control flow among Clients, Server and Wireless Devices is very low.
We have carefully designed two kinds of experiments to maximize the benefits of WeFiLab for students. First of all, the experiments introduce the basics of WiFi, for example, letting students know what SSID, BSSID or Channel is and how do they work in connection with other WiFi devices. There are also some advanced experiments which let students decode/analyze wireless frames, enabling students to learn the details of WiFi frame structures and the communication process.
Compared with wired networking concepts, many students find it harder to understand the fundamental concepts of wireless networking. Students either directly link wired networking with wireless one or have largely degree of misunderstanding about the wireless networking. In this section, we introduce several experiments provided by WeFiLab and describe how they can be utilized to help students know the basics of WiFi mechanism.
Almost in every textbook which introduces WiFi begins with the mode of operation, channels, and associations. WiFi allows for both “Infrastructure” mode and “ad hoc” mode. A wireless access point is required for infrastructure mode operation to bridge wireless subnetwork to Internet or enable communication among wireless client stations (STA). In comparison, ad hoc mode is a method for wireless clients to directly communicate with each other. Operating in ad hoc mode allows all wireless clients within coverage range of each other to discover and communicate in peer-to-peer fashion without involving an access point.
To help students to distinguish the difference between the two modes, the experiment allows students to operate up to four wireless devices at a time. The procedure of this experiment is as follows:
Step 1. The students are first asked to configure one of the wireless devices to be AP (infrastructure) mode. The remaining devices act as wireless clients (STA mode).
Step 2. Students are then asked to associate the clients with the AP and send text messages among the clients to verify the inter connections.
Step 3. Once this is completed, it is followed by asking students to turn off the connectivity of AP node.
Step 4. Students are then instructed to send text messages among wireless clients again to guess and see what would happen.
Result. Text messages should never be received through the network because the connectivity among all clients is broken due to the lost of AP in the WiFi group.
For ad hoc mode experiment, as a comparison, students are guided to:
Step 1. Turn one of the wireless nodes into ad hoc network initiator and then join other nodes to the network one by one.
Step 2. Students are then asked to send text messages among the clients to verify the inter connections.
Step 3. Once this is completed, it is followed by asking students to turn off the connectivity of the initiator node.
Step 4. Students are then instructed to send text messages among wireless clients again to guess and see what would happen.
Result. Text messages should be received through the network because the connectivity among all clients remain alive due to peer-to-peer connection under ad hoc mode in the WiFi group.
By observing the differences during the previous two experiments, students are expected to understand that nodes in ad hoc mode communicate peer-to-peer fashion, while infrastructure mode requires a central access point, the AP, for facilitating the communication among associated clients.
In 802.11, each wireless station needs to associate with an Access Point before it can send or receive network-layer data. When a network administrator installs an AP (or wireless router), the administrators must assign the name of the network known as its Server Set IDentifier that identifies a particular 802.11 wireless LAN. A client device receives broadcast messages (Beacon Frame) from all APs within range advertising their SSIDs. The client device can then either manually or automatically select the desired network to associate with. The SSID can be up to 32 alphanumeric characters long. Multiple access points can share the same SSID if they provide access to the same network. SSID is the name of a wireless LAN, while the communication between AP and clients are based on the MAC address. So, the SSID can be changed after finishing the association. To verify this, students are required to finish following experiment:
Step 1. Students are required to set the SSID for one of the wireless devices and turn it into AP mode.
Step 2. For the other devices, scan and associate themselves with the AP.
Step 3. Send text messages among them to verify the connections.
Step 4. Modify the SSID of AP and send text message again to verify the connection.
Result. The connections remain because the change of SSID does not affect ongoing connections since it is merely an identifier of a wireless LAN.
The administrator must also assign the channel that the AP uses. 802.11b/g operates in the frequency range of 2.4 GHz, and there are 14 channels designated in this range spaced 5 MHz apart. Any two channels are nonoverlapping if they are separated by four or more channels. Consequently, the set of channels, 1, 6, 11, and 14 are recommended to avoid interference. Many students perceive WiFi as just a single radio channel which connect their WiFi capable devices to the internet. The following experiment aims at showing the students that the channels exist and wireless devices can only communicate in the same channel number.
Step 1. Students are asked to turn one of the wireless devices into AP mode.
Step 2. For the other devices, scan and associate themselves with the AP.
Step 3. Send text messages among them to verify the connections.
Step 4. Modify the channel of AP and send text message again to verify the connection.
Result. The connection is lost because WiFi devices cannot communicate at different channels.
Through these serial of basic experiments about WiFi, students are supposed to understand the role of SSID and wireless channels during the association and data communication between AP and Client, and the difference of the Infrastructure mode and ad hoc mode.
For advanced learners, who want to dig deeper about 802.11 knowledge, WeFiLab can be used to go through 802.11 frame structure and study the detail communication between AP and client stations. To do this, reading through the IEEE 802.11 specification [ 22] is an option.
Some of the wireless devices can work at monitor mode, i.e., a sniffer, to capture all the wireless frames in a specific channel. WeFiLab is also equipped with a WiFi frame analyzer. The benefit of using the analyzer is to help students to go through complicated frame structure with real frame with enough aid of automation. For example, given a beacon frame, the analyzer can highlight the different fields instantly with different color, see Fig. 3a. That can significantly stimulate students' interest toward learning. With the assistance of the equipped WiFi frame analyzer, students can decode each frame they captured. Furthermore, with all the captured frames from the sniffer, students can see the entire communication process, such as association, authentication, transmission, and so on.
Figure Fig. 3. WeFiLab accessed through desktop PC and smartphone.
We design the following experiment about WiFi Frames, which mainly focuses on the AP/STA mode. The procedure is as follows:
Step 1. Students are first asked to activate one sniffer to monitor the environment.
Step 2. Students need to capture some WiFi frames of a certain types, such as frames of Beacon, Probing Request/Response, Association Request/Response, Authentication, and so on.
Step 3. Then, students are asked to interpret the meaning of header/data fields of these frames according to the IEEE 802.11 Specification [ 22].
Step 4. Several questions will be displayed for each student to answer according the frames that they captured. Students can save and submit their answers on the server.
Once completed, all students' answers will be stored for grading and further studying by tutors/teachers. WeFiLab provides an AnswerCheck view for tutors/teachers to grade students' submissions. Also, teachers review the analysis of students' performance.
After this experiment, students are supposed to get a deep insight of the details of WiFi communication, such as the detail structure of WiFi frame, the association/authentication between AP and client, the detailed transmission of data packets and so on. Through the set of questions, teachers can trace students' performance and locate the common mistakes and misunderstandings.
We have successfully built the prototype of WeFiLab, which has been used for conducting experiments of a course for two years.
In our current implementation, we use 16 wireless routers to form the wireless nodes array. In order to enable efficient message transfer between server and wireless nodes, all these wireless routers are connected to the server through a switch on Ethernet. Ported with a comprehensive OpenWRT embedded Linux OS, the wireless device adopts Broadcom's BCM5354, which is a 802.11b/g Router System-on-Chip, as the core of the wireless node. It can work on different modes, such as AP/STA, ad hoc, and so on. Since this chip comes with a USB2.0 host controller, the wireless devices can be extended for some advanced learners, such as 3G, wireless sensor network, and so on. Various wireless devices can be used here as server will hide the difference from users through the two-level operations.
The server is implemented as a bridge between user and wireless nodes array. It is connected to the wireless node array through an Ethernet switcher. The server coordinates wireless devices according to users' requests and forwards the response of wireless devices to correspondent clients.
WeFiLab adopts Ajax to build the user-friendly GUI for enabling sufficient interactivity students and the systems. Ajax allows every user with capable web browser to use WeFiLab without additional plug-ins, and makes the anywhere anytime wireless networking laboratories to mobile learners come true. Currently, we have tested WeFiLab successfully on several web browsers, such as Google Chrome 9 or above, Firefox 3.6.X or above, IE 8.0 or above, Safari 5. Fig. 5 shows the snapshot of WeFiLab on a web browser of PC. In this figure, we can see the three locked wireless devices and a panel in the bottom which can display the captured frames in real time. WeFiLab can also be accessed through smartphone. Fig. 5 displays a view of WeFiLab on a HTC G2 mobile phone.
WeFiLab uses MySQL as the database server to facilitate the whole system, e.g., storing user information, schedule information, wireless device information, and so on. It can also record all the data produced during students' experiments such as operation history, captured wireless frames, students' answers to the questions, and so on.
To investigate to what extent WeFiLab can facilitate students' understanding of WiFi and help teachers during the course, we have evaluated WeFiLab through two study cases, where WeFiLab was used as a complement of assignments for two courses in City University of Hong Kong: the course Mobile Computing [ 12] for two semesters: CS4284 2010B (Semester B 2009/10) and CS4284 2011B (Semester B 2010/11), the course Pervasive Computing [ 23] for one semesters: CS4289 2011A (Semester A 2011/12).
In the semester CS4284 2010B, 146 undergraduate computer science students are involved into the experiment about 802.11 Frame, which is described in Section 4.2. After we optimized the design and implementation of WeFiLab, we used it again for the experiment of the course in semester CS4284 2011B and CS4289 2011A, which involves 116 and 53 undergraduate students, respectively, from computer science.
Both of the study cases in the two semesters are designed following the OBTL scheme [ 24] in City University of Hong Kong.
OBTL [ 24] is a student-centered approach for the delivery of educational programmes where the curriculum topics in a programme and the courses contained in it are expressed clearly as the intended outcomes for students to achieve. Teaching is then designed to directly encourage students to achieve those outcomes and reflect on the learning process with assessments undertaken. In this approach, teachers act as facilitators, and students should take responsibility and participate actively. It has been widely adopted in universities across the world.
Some glossaries of OBTL that will be used in the following description of the two cases in this section include:
Intended learning outcomes (ILO). ILOs state what students are expected to be able to do at the end of the courses/experiments according to a given standard of performance. ILOs are the goals to be achieved through the learning activity.
Teaching/learning activities (TLA). TLAs in constructive alignment refer to situations that elicit the appropriate learning activities, whether teacher, peer, or self-initiated. In the two cases of this section, we provided students short sessions of introducing the experiments, demonstrations, some related materials for students learning and let them do the assigned/self-motivated experiments on WeFiLab.
Assessment tasks (AT). Assessment Tasks are what teachers ask students to do to demonstrate evidence that a particular Learning Outcome has been achieved. Some ATs provided in WeFiLab include letting students conduct an experiment (detecting based on the captured frames on the sniffer), analyze WiFi frames, answer questions at the end of experiments, etc.
All the ILOs, TLAs, and ATs of the experiments are aligned, and assessment rubrics (criteria) for the experiment are also provided in the two cases, so students know what they need to do and how they will be assessed for the experiments using the WeFiLab.
The first case is the experiment for CS4284 in semester 2010B. This experiment mainly focused on the infrastructure mode of IEEE 802.11 WLAN. The participants of this case study include 146 undergraduate computer science students. They all attended the experiment about 802.11 Frame capture and analysis, which is described in Section 4.2.
The whole experiment includes two parts: first, students need to capture a certain types of wireless frames by WeFiLab; second, students need to answer a group of questions according to the captured frames.
The ILOs of this experiment are
The TLAs of the experiment include a session for introduction and demonstration to let students know how to capture real wireless frames, decode and analyze these frames. Before the experiment was officially released, teachers/tutors had explained the issues in Wireless LAN and the IEEE 802.11 frames both in the lectures and tutorials. Some related materials, e.g., one chapter (Chapter 7) in the IEEE 802.11 Specification Document [ 22], were recommended to students for their self-learning and reference while doing the experiment. A short manual of WeFiLab for this experiment was also provided to ensure that students understand the whole experiment.
To evaluate whether the ILOs are achieved for students, the ATs of this experiment are to let students answer some questions, which are designed based on the frames captured by them during the experiment, and grading them based on their performance.
As in this experiment, students only need to capture some frames and they don't need to lock devices explicitly, the FCFS Scheme (Nonscheduled) is used, referred to Section 3.4. When students send to request to the server, the server will assign and activate a sniffer to students. The sniffer will capture all wireless frames on the specified channel. In case that the channel is idle, i.e., no traffic occur within a predefined time period, the server will control a wireless device to take activities such as scanning, association, authentication, or transmission in order to generate some wireless traffic.
During this experiment, students were asked to:
Step 1. Log in the WeFiLab system and activate a wireless sniffer.
Step 2. Capture a certain types of WiFi frames through the wireless sniffer. The desired frames include Beacons, Probing Request/Response, Association Request/Response, Authentication Request/Response, RTS/CTS, DATA and ACK.
Step 3. Interpret the headers/body of the captured frames using the embedded frame analyzer in WeFiLab and according to the IEEE 802.11 Specification.
Step 4. Answer 25 questions generated for them according to the frames that they captured and submit the answers through WeFiLab after finished.
Students were allowed to try the whole experiment again whenever they needed before the deadline. The system will store all their submissions but only choose the last version as their final answers for grading.
These 25 questions provided for students include topics such as the association process, data transmission, and other issues about Infrastructure mode in Wireless LAN. Table 1 shows the general topics of these 25 questions and some related frame fields. These fields include both information element and noninformation elements in IEEE 802.11 frames. As all the wireless frames are captured by students on the air dynamically, the answers of the same question for each student would be different.
The whole experiment, including both capturing frames and answering questions, continued for two weeks (12-26 April 2010). All the 146 students in the CS4284 2010B were able to use WeFiLab to complete the whole experiment and submitted their answers successfully before the deadline. Some students didn't complete the experiment first time. According to our system records, most of students tried 2-3 times of the experiment before the deadline, with each student try 2.74 times on average.
Fig. 4 gives the results of students' performance on these 25 questions based on the records of WeFiLab. Fig. 4a shows the percentage of students who provide correct answer on each question. Based on these statistic results, teachers can easily find out on which questions students' knowledge are weak. Using the WeFiLab, teachers can view these students' answers on these questions and locate the weak points of them, which will help teacher to give more explanations to students on these topics in the lecture.
Fig. 4. Results of the 802.11 frame experiments.
Fig. 5. Overall diversity of students' login time for both courses.
For example, the result in Fig. 4a shows that there are nearly 80 percent students failed on the questions 5, 9, 12, 20, 21, and 25. Among these questions that many students failed, all the first five questions are about the supporting rates in the Beacon/Probing/Authentication/Association frames. The supported rates carried in these frames describe the rates that the particular wireless LAN supports. This information field is encoded as 1 to 8 octets, where each octet describes a single Supported Rate. According to the students who failed on these questions, most of them still unclear about how to calculate the supported rates after reading the IEEE 802.11 Specification. So, the teacher needs to explain the calculation during the lecture course.
The question 25 is about the four-way handshake of data transmission procedure between AP and client, which involves exchanging frames of RTS-CTS-DATA-ACK. This question is to test students understanding of the interframe space (IFS) and Net Allocation Vector (NAV), such as DIFS, SIFS, and duration field in the frames. According to students' answers, many students failed on this question because they don't understand the time spaces and duration clearly. So, the teacher may need to reemphasize students understanding on the mechanism of CSMA/CA with RTS-CTS.
Fig. 4b also shows the distribution of all students' final scores of the experiment. The blue bar is the distribution of raw scores. The red dotted curve shows the normal distribution based on the mean and standard variation of the raw scores. It helps teacher to obtain an overview of all the students' performance. We can find that the distribution is almost the classical “bell curve” [ 25]. According to this result, the teacher can know that most students got 15-21 correct answers. As most students successfully captured the required wireless frames and answering the questions about decoding/analyzing these frames, the two ILOs for this experiment are achieved.
The second case involves assignments for CS4284 in semester 2011B and CS4289 in semester 2011A. This experiment in the assignment combines part of the experiment in Section 4.1 and the 802.11 Frames in Section 4.2. In total, 169 undergraduate computer science students attended this experiment (116 from CS4284 2011B and 53 from CS4289 2011A).
The ILOs of this experiment are
The TLAs of this experiment mainly include two parts: 1) Deploy an ad hoc network in WeFiLab cooperating with other group members. 2) Decode and analyze the frames generated during the experiment and answer some related questions. A detailed manual of the system was also provided for students. The IEEE 802.11 Specification Document [ 22] was recommended to students for their self-learning. At the end of the experiment, we also give students a chance to provide feedback/questionnaire about the experiment.
The experiment allows students to finish it in a group. Each group is formed on students' own and then their grouping information will be registered to the system. All group members must collaborate with each other to complete the experiment, e.g., controlling one device to work as AP for other members, capturing other members' packets. For each group, a group leader is elected to coordinate the whole experiment among group members. In the course CS4284 2011B, the 116 students are divided into 45 groups by students themselves. Most of the groups included three students, others include two or only one student (29 groups have three members, 13 groups have two members and three groups have only one member). In the course CS4289 2011A, 53 students are divided into 31 groups, including 12 one-member groups, 16 two-member groups, and three three-member groups.
The ATs of this experiment are to let students answer the questions, which are generated according to their captured frames during the experiment, and grading them based on their performance.
As in this experiment, the number of students are far more than the current wireless devices resources of WeFiLab, both the Reservation Scheme (Scheduled) and the FCFS Scheme (Nonscheduled) are used, referred to Section 3.4. For each group, WeFiLab reserved a one-hour slot and three devices based on all students' preference for the experiment. So, each group has enough time to do the experiment. And for the time outside the reserved schedule, we use FCFS Scheme to allow students who failed competing for the available resources to do the experiment.
The manual provides students detailed instructions during the experiment. Some of the main procedures include
Step 1. All members log in the WeFiLab system. Each member of a group can see the online status of the other members.
Step 2. Group Leader request and lock three devices. If the group locked the three devices successfully, the system will also assign a sniffer to the group. The sniffer will capture all the frames generated by the locked devices.
Step 3. The three locked devices will be assigned to each member of the group automatically. Each device will be controlled by only one member. Some members may need to control more than one devices for those groups with less than three students.
Step 4. Set SSID for each devices. Use broadcast/unicast packets to check the connectivity of the three devices.
Step 5. Choose one device as initiator of the ad hoc network, the other devices join the initiator to constitute an ad hoc network. Use broadcast/unicast packets to check the connectivity of the three devices.
Step 6. Set new SSID for the initiator and other devices. Use broadcast/unicast packets to check the connectivity of the three devices.
Step 7. The sniffer will capture all the generated frames. The server will simply analyze these frames to get the status of students' experiment. Once the system detected all the operations are finished, it will notify students.
Step 8. Interpret the headers/body of the captured frames using the embedded frame analyzer in WeFiLab and according to the IEEE 802.11 Specification.
Step 9. Answer some questions generated for them according to the frames that they captured and submit the answers through WeFiLab after finished.
A questionnaire is also provided in WeFiLab to let students give their feedback and rate the WeFiLab system after they complete the whole experiment.
Those questions provided for students include topics such as the format of “FrameControl” Field in Frame Header, locating and decoding information elements, (e.g., SSID, supported rates, working channel, etc.), the association process among stations, data transmission, the setting of NAV value and other issues about Infrastructure mode in Wireless LAN. Students were allowed to submit the answers whenever they needed before the deadline of the experiment. The system will store all their submissions but only choose the last version as their final answers for grading.
Through the simple experiment and further studying of the captured wireless frames during answering the questions, students are supposed to understand some basic characteristics in ad hoc network, such as the role of SSID and initiator for ad hoc networks, detailed data transmission process, the broadcast which is not guarded by RTS/CTS mechanism, and so on.
The whole experiment, including the ad hoc experiment, frame analyzing questions and the questionnaire, continued for three weeks (CS4284 2011B: March 22-April 11, CS4289 2011A: September 26-October 14). All students in the two courses were able to use WeFiLab to complete the ad hoc network experiment and answer the required questions before the deadline successfully. Table 2 shows more details about the students' information in the two courses.
According to the results, about 88.9 percent groups from CS4284 2011B and 87.1 percent groups from CS4289 2011A complete the ad hoc Network experiment during their reserved one hour slot (Scheduled). The others finished the experiment using the FCFS Scheme. Table 3 also shows how many times students retried to do the experiment and the total time period they locked the wireless devices. Most of the groups tried the experiment for 3-4 times and finished the ad hoc experiment using 15-30 minutes.
Fig. 6 is the overall statistics of Students and the Clients information for both the courses CS4284 2011B and CS4289 2011B. Fig. 6a shows the places where students do the experiment according to the questionnaire. It is worth to note that about 38 percent students do their experiment at home, and the 4 percent of “Others” in the figure includes companies (part-time students), students' residences and so on. Besides the questionnaire that students provided, WeFiLab also record students login IP, from which we find that about 37.3 percent students' login activity are taken place outside the university campus. Furthermore, Fig. 5 shows the distribution of login time of all students based on the hour of a day (00:00-23:59) during the whole three weeks. Though around 50 percent students' login activities appears during 13:00-16:00, their activity still distributed in a large range of a day. All these phenomena are mainly because that WeFiLab enables students to study anytime anywhere as long as there is Internet service. And the diversity both on the place and time dimension increase the ability of WeFiLab to reuse wireless devices resource for more students.
Figs. 6b and 6c are the web browsers and client OS that students used while doing the experiment. All these information are captured through the HTTP User Agent [ 26]. The various of web browsers and OS used by students during doing the experiment, which contain most of the current popular browsers and OS, shows that WeFiLab has much compatibility.
Fig. 6. Overall statistics of students' and clients' profile for both two courses.
Fig. 6d shows the type of clients based on the questionnaire. The goal of WeFiLab is to let students do experiments on real devices through webpage. It allows students to use both desktop computers and mobile devices to access the system. The results show that most of the students used desktop/laptop PC, or Mac to do the experiment. However, there are still 1 percent records which students used WeFiLab on iPad and smartphones, i.e., iPhones. The iPad has the size and weight fell between those of smartphones and laptops, but shares the same OS as the iPod Touch and iPhone.
To assess the performance and design of the prototype WeFiLab, there is also a group of statements in the questionnaire to let students rate the experiment based on their experience during the experiment on a scale between 0 and 10, where 0 indicates “very bad” and 10 indicates “excellent.” Table 4 shows students feedback on these statements. Most students think that WeFiLab provides very good functions for their study (i.e., the item 3 in Table 4, whose average score is over 7).
Though WeFiLab is designed for students to have hand-on experience of wireless network, its architecture and design rationale, e.g., the two-level operations and schedule scheme, can be applied to other fields that require students to have experience on real devices, e.g., RFID, Internet Switcher/Router experiment, etc.
Some challenging problems and future works about WeFiLab are described as follows.
As we mentioned in the previous sections, the WeFiLab platform adopts Ajax for the design of GUI, which is compatible with many current mobile web browsers of smartphones. However, smartphones still have the following limitations, which need to be considered for the further development of WeFiLab: 1) small screen size: the screen size are varied for different types of mobile phones and smaller compared to PC and laptop. 2) Limited computing and memory resources. 3) Limited network ability: depending on the condition of mobile phone, they may have low bandwidth and long packet delay. Furthermore, due to the mobility of smartphones, clients may experience unexpected connection interruptions.
One of the great challenges while developing WeFiLab is the interference among all the wireless devices. We have tried to reduce the transmission power of the wireless module as low as possible without influence students' experiments. Though the interference in WeFiLab is not so obvious under the current settings currently, we believe with the increasing on the number of wireless devices, the interference would be a serious problem and challenge to work on in future. To separate devices into different locations, which are far away enough not interfering with each other, is also an option. More optimization on the design and more efficient schedule are need to be conducted on WeFiLab.
We will continue to focus on improving the relationship among students and teachers/instructors. There are two aspects about this relationship [ 27]: 1) Student-Student relationship: this relationship is about the collaboration among students who might also be remote from each other. Currently, WeFiLab already allow students to collaborate with each other while doing the experiments. WeFiLab will further enable students to collaborate more efficiently to finish large experiments together or help each other during experiments. 2) Student-Instructor relationship: Similar to the relationship between students, we aims to provide more interaction among students and teachers/instructors when the experiments are carrying on, rather than just providing the results and histories of students' performance after the experiments. For example, it would be very useful to let teachers trace students' real-time activities and status during doing experiments. The sufficient information can enable teachers find the weak points of students or providing some suggestions before students making mistakes.
Some more complex configuration of wireless network can be provided to serve some advanced students for further learning, e.g., graduate students. Also the wireless devices in WeFiLab can be extended (through the USB port) to support other networks, such as the third-generation wireless cellular networks (e.g., HSPA), wireless sensor network to fulfill the interest of students for new technologies.
The WeFiLab is designed as an education platform currently. However, with some extension, it can also be used as a platform for academic researches. The operations would be much more complicated for research purpose compared to education. So, some advanced features would be provided, such as scripts-support for the control of each step of experiments, programming on wireless devices (compilation/uploading/running), more scientific process on experiment data, and so on. Furthermore, a group of APIs for the system may also need to be developed and provided in order to allow access and reuse by third-party educational applications.
In this paper, we present the platform of WeFiLab, an online web-based laboratory for undergraduate students. WeFiLab mainly focuses on the wireless networking technologies (WiFi). It aims to provide undergraduate students for hand-on experience of doing wireless network experiments on real devices. With the web-based GUI, it enables students to do experiment on webpage via Internet anytime anywhere. WeFiLab uses the structure of two-level operations to coordinate the communication between clients and wireless devices, allowing students' experiment on real wireless devices. The Schedule Scheme of WeFiLab also facilitating the efficient use of these devices.
We've also implemented a prototype of WeFiLab system and evaluated it in two study cases. In both of the two study cases, which totally involved 315 undergraduate computer science students, WeFiLab was successfully used as a complement for the course of Mobile Computing and Pervasive Computing in City University of Hong Kong. The case study results show that WeFiLab not only improve students' understanding about the WiFi but also help teachers to locate the weak areas of students' knowledge and reemphasize these topics in the lecture course.
This work was supported in part by the following grants: CityU Teaching Development Grant (TDG(CityU)) No. 6000325, General Research Fund of the Hong Kong SAR, China, No. (CityU 114609 and CityU 114012) and CityU Applied R&D Funding (ARD) No. 9681001; CityU Applied Research Grant (ARG) No. 9667052; National Science Foundation of China No. 61070222; and Shen Zhen Basic Research Project No. JCYJ20120618115257259.