## 2 Our Proposed Context-Aware Smart Classroom Architecture
### Supporting Measures for the Proposed Architecture  
The proposed model is a conceptual technology integration model and is beneficial to high level and campus-wide smart classroom applications in terms of underlying technology integration. This model is not intended for addressing issues such as security, networking, and daily operations. Therefore, supporting measures are also proposed in this architecture for successfully adopting the proposed classroom prototype and technology integration model in smart campus programs. Two important supporting measures related to network configuration are:  
* Device control network, which is layer 1 and layer 2 in the model, and normal network, which is layer 3 or layer 4 in the model, should be at least logically separated in smart classrooms. * Every classroom should have its own private network for device control, and the configuration of the private network in every classroom should be identical. In Figure 8, a network gateway is placed between layer 2 and layer 3, which means the network design of the proposed model, in terms of device control, is based on IP network and every classroom should have its own private IP network for device control and network traffic not related to classroom device control should be separated from the device control network. The major reason to separate control and the normal network is security. The public computer and IoT devices are both vulnerable. However, normally IoT device vendors will not provide system patch as frequently as operating system vendors. Even if an IoT device has a new security patch, it is still not having efficient methods, such as automatic update, for massively deploying security patches to IoT devices. Therefore, it is very dangerous and not recommended to put the classroom public computers and smart classroom IoT devices in the same network. Multiple smart classrooms using the same IP network for device control is also not recommended in the proposed architecture, which means every smart classroom should have its own private network for device control and the configuration of the private network in every classroom should be identical. The major reason for this policy is the efficiency of classroom application development, device operation, and management. With this policy, the use of IP address should be well planned for the devices in the control network because there will be only one private network configuration for every classroom. For example, if projectors in every classroom are all using 192.168.50.100, and the Raspberry Pi boards in every classroom, which are responsible for controlling the projector in the same classroom, are all using 192.168.50.2, the program and configuration related to sending control commands from the controlling Raspberry Pi to the controlled projector can be used in all classrooms without any modification. Raspberry Pi boards, which are playing the same role and performing identical functions in different smart classrooms, should have identical IP configurations. This rule also applies to Layer 1 devices with the same model number and playing the same role in the different smart classrooms. Therefore, device configuration and device control procedure programming efforts can be minimized with this policy and the only network configuration for device control differs from classroom to classroom is the external IP address of the NAT gateway for each classroom. Therefore, the central control server only needs to know the external IP address of each classroom for delivering layer 2 operation commands to each classroom. Although the proposed architecture does not have other rules for issues related to network security and management. Mechanisms helpful to enhance security and manageability while implementing the proposed architecture still need to be considered, for example:  
* It is recommended to use Secure Sockets Layer (SSL) encryption to protect web application interface calls.