2.3 Industrial Applications --------------------------- (a) Make the section on Building Automation section 2.3, thereby moving Industrial applications to 2.5 and Home automation to 2.5, since a reference to Building Automation like scenarios exist in both of these areas as well. (b) I believe that separating Building Automation from Industrial Applications is important. Industrial Applications, in my view, are typically those systems that may be required to adapt the operating conditions of a manufacturing plant, monitor the production systems and trigger specific decision making processes (e.g. ordering components, trigger safety mechanisms and etc.). As such, I propose the following change to the first few sentences of the first paragraph: "Industrial Applications and smart manufacturing refer to networked control and monitoring of tasks such as equipment related to manufacturing, asset and situation management or process control. For the management of a factory it is becoming essential to implement smart capabilities. From an engineering standpoint, industrial applications are intelligent systems enabling rapid manufacturing of new products, dynamic response to product demand, and real-time optimization of manufacturing production and supply chain networks. Potential industrial applications e.g. for smart factories and smart manufacturing are:" (c) Of course, it is still possible that Building Automation may be performed or interfaced with in order to achieve the goals of an Industrial Application. For example, a steel manufacturing plant may use a building management system to control the temperature of a furnace in order to change the grade of steel produced. It is likely important to highlight that even though there might be some differences between the application scenarios, in some situations the boundaries might be blurred, so that the reader understands that some applications scenarios are closely coupled. Another example of intersect is that between Industrial Applications and Environmental Monitoring, especially when it comes to Nuclear Energy Plants. As such, I propose adding a new second paragraph to clarify this intersect that may occur, but still keep Building Automation separate from Industrial Applications in general: "Management of Industrial Applications and smart manufacturing may in some situations be achieved by interfacing with and completing Building Automation tasks such as control of energy, HVAC (heating, ventilation, and air conditioning), lighting, access control, and etc. Interacting with management systems from other application areas might also be important in some cases (e.g. environmental monitoring for nuclear energy production, energy management for dynamically scaling manufacturing, vehicular networks for mobile asset tracking and etc.)." In case an example of such a scenario is required, it could be added as well. (d) As such, in totality the new first two paragraphs of this section would read: "Industrial Applications and smart manufacturing refer to networked control and monitoring of tasks such as equipment related to manufacturing, asset and situation management or process control. For the management of a factory it is becoming essential to implement smart capabilities. From an engineering standpoint, industrial applications are intelligent systems enabling rapid manufacturing of new products, dynamic response to product demand, and real-time optimization of manufacturing production and supply chain networks. Potential industrial applications e.g. for smart factories and smart manufacturing are: * bullet points follow Management of Industrial Applications and smart manufacturing may in some situations be achieved by interfacing with and completing Building Automation tasks such as control of energy, HVAC (heating, ventilation, and air conditioning), lighting, access control, and etc. Interacting with management systems from other application areas might also be important in some cases (e.g. environmental monitoring for nuclear energy production, energy management for dynamically scaling manufacturing, vehicular networks for mobile asset tracking and etc.)." (e) Diff of the new and old text is attached. 2.4 Home Automation ------------------- (a) Make the section on Building Automation section 2.3, thereby moving Industrial applications to 2.5 and Home automation to 2.5, since a reference to Building Automation like scenarios exist in both of these areas as well. (b) I propose including security infrastructure into home automation as well, since this is already a significant market that is operated and maintained by either home users, or contracting agencies like ADT. Furthermore, security services also consist of constrained devices, especially in the form of sensors. As such, the first paragraph could be changed to the following: "Home automation includes the control of lighting, heating, ventilation, air conditioning, appliances, entertainment and home security devices to improve convenience, comfort, energy efficiency, and security. It can be seen as a residential extension of building automation." (c) The differentiation between home automation and building automation is not very clear at this point. An extension to the first paragraph can be made in the following way: "It can be seen as a residential extension of building automation. However, it is expected that unlike a building automation system the infrastructure in a home is operated in a considerably more ad-hoc nature, with no centralized management system akin to a Building Automation System (BAS) available to concentrate various functions together." (d) Currently the draft suggests that home automation configuration services may be provided by electricians. But, in time, there might be other players that emerge in this market as well (ISPs, small private companies, device manufacturers and etc.). This makes it likely that configuration and management services may be provided to home users, similar to the way it is offered in the home security sphere today. As such, I recommend the following modification to the second paragraph: "Home automation networks need a certain amount of configuration (associating switches or sensors to actors) that is either provided by electricians deploying home automation solutions, third party service providers (ISPs, small outsourcing firms, device manufacturers, online portals and etc.) or done by residents by using the application user interface to configure (parts of) the home automation solution. Similarly, failures may be reported via suitable interfaces to residents or they might be recorded and made available to service providers in charge of the maintenance of the home automation infrastructure." (e) Based on the addition of third party service providers, the last paragraph could be extended as well: "The management responsibility lies either with the residents or it may be outsourced to electricians and/or third parties providing management of home automation solutions as a service. A varying combination of electricians, service providers or the residents may be responsible for different aspects of managing the infrastructure. The time scale for failure detection and resolution is in many cases likely counted in hours to days." (f) This causes the new text of the section on Home Automation to read as below: "Home automation includes the control of lighting, heating, ventilation, air conditioning, appliances, entertainment and home security devices to improve convenience, comfort, energy efficiency, and security. It can be seen as a residential extension of building automation. However, it is expected that unlike a building automation system the infrastructure in a home is operated in a considerably more ad-hoc nature, with no centralized management system akin to a Building Automation System (BAS) available to concentrate various functions together. Home automation networks need a certain amount of configuration (associating switches or sensors to actors) that is either provided by electricians deploying home automation solutions, third party service providers (ISPs, small outsourcing firms, device manufacturers, online portals and etc.) or done by residents by using the application user interface to configure (parts of) the home automation solution. Similarly, failures may be reported via suitable interfaces to residents or they might be recorded and made available to service providers in charge of the maintenance of the home automation infrastructure. The management responsibility lies either with the residents or it may be outsourced to electricians and/or third parties providing management of home automation solutions as a service. A varying combination of electricians, service providers or the residents may be responsible for different aspects of managing the infrastructure. The time scale for failure detection and resolution is in many cases likely counted in hours to days." A diff of the section is attached. 2.10 Mobile Applications ------------------------ (a) The whole use case of Mobile Applications in Section 2.10 seems to be not really a use case, but rather special cases related to access technologies. All the issues discussed here seem to be use case issues that should be part of other use case sub-sections. As such, one approach to overcoming this problem would be to merge this sub-section into the previous sub-sections. Another possibility is to create a new section that discusses only access technologies rather than application scenarios. (b) For the sake of simplicity, I propose creating a new section for access technologies: "3. Access Technologies ---------------------- Besides the management requirements imposed by the different use cases, the access technologies used by the constrained devices might also impose restrictions and requirements upon the Network Management System (NMS) and protocol of choice. It is possible that some networks of constrained devices might utilize traditional non-constrained access technologies, e.g. LAN, for network access. In such scenarios, the constrainedness of the device presents special management restrictions and requirements rather than the access technology utilized. However, in other situations constrained or mobile access technologies might be used for network access, thereby causing management restrictions and requirements to arise as a result of the underlying access technologies. 3.1 Constrained Access Technologies ----------------------------------- Due to resource restrictions, embedded devices deployed as sensors and actuators in the aforementioned use cases can utilize low-power low data-rate access technologies such as IEEE 802.15.4, DECT ULE or BT-LE for network connectivity. In such situations it is important for the NMS to be aware of the restrictions imposed by these technologies efficiently manage these constrained devices. Specifically, such low-power low data-rate access technologies typically have small frame sizes. So it would be important for the NMS and management protocol of choice to craft packets in a way that avoids fragmentation and reassembly of packets since this can use valuable memory on constrained devices. Devices using such access technologies might operate via a gateway that translates between these access technologies and more traditional Internet protocols. A hierarchical approach to device management in such a situation might be useful, wherein the gateway device is in-charge of devices connected to it, while the NMS conducts management operations only to the gateway. Mobile Access Technologies -------------------------- M2M services are increasingly provided by mobile service providers as numerous devices, home appliances, utility meters, cars, video surveillance cameras, and health monitors, are connected with mobile broadband technologies. Different applications e.g. in a home appliance or in-car network use Bluetooth, Wi-Fi or Zigbee and connect to a cellular module acting as a gateway between the constrained environment and the mobile cellular network. Such a gateway might provide different options for the connectivity of mobile networks and constrained devices, e.g.: o a smart phone with 3G/4G and WLAN radio might use BT-LE to connect to the devices in a home area network, o a femtocell might be combined with home gateway functionality acting as a low-power cellular base station connecting smart devices to the application server of a mobile service provider, o an embedded cellular module with LTE radio connecting the devices in the car network with the server running the telematics service, o an M2M gateway connected to the mobile operator network supporting diverse IoT connectivity technologies including ZigBee and CoAP over 6LoWPAN over IEEE 802.15.4. Common to all scenarios above is that they are embedded in a service and connected to a network provided by a mobile service provider. Usually there is a hierarchical deployment and management topology in place where different parts of the network are managed by different management entities and the count of devices to manage is high (e.g. many thousands). In general, the network is comprised by manifold type and size of devices matching to different device classes. As such, the managing entity needs to be prepared to manage devices with diverse capabilities using different communication or management protocols. In case the devices are directly connected to a gateway they most likely are managed by a management entity integrated with the gateway, which itself is part of the Network Management System (NMS) run by the mobile operator. Smart phones or embedded modules connected to a gateway might be themselves in charge to manage the devices on their level. The initial and subsequent configuration of such a device is mainly based on self-configuration and is triggered by the device itself. The gateway might be in charge of filtering and aggregating the data received from the device as the information sent by the device might be mostly redundant." Talk of mobility of nodes has been removed from this section because this should either be merged back into individual use cases wherein mobility is expected, or be merged into a section on Vehicular Networks and a reference made to this, as necessary. 2.12 MANET Concept of Operations (CONOPS) in Military ----------------------------------------------------- (a) Section 2.12, MANET Concept of Operations (CONOPS) in Military, is considerably more detailed than any of the other use case sections. In fact, a lot of the text here focuses on things like hierarchical management, special access technologies and mobility. This was all covered in other use cases. It would, as such, make more sense to re-write this section in keeping with the level of detail provided in other use cases, while shifting the focus to purely military applications and the special conditions that come with military operations. This could cover things like increased international military unit cooperation that bring along with it multiple different standards, best practices and conflicting/contradicting implementation approaches. As such, I propose the following new text for this section: "2.12 Military Operations ------------------------- The challenges of configuration and monitoring of networks faced by military agencies can be different from the other use cases since the requirements and operating conditions of military networks are quite different. With technology advancements, military networks nowadays have become large and consist of varieties of different types of equipment that run different protocols and tools that obviously increase complexity of the tactical networks. In many scenarios, configurations are, most likely, manually performed. Furthermore, some legacy and even modern devices do not even support IP networking. Majority of protocols and tools developed by vendors that are being used are proprietary which makes integration more difficult. The main reason for this disjoint operation scenario is that most military equipment is developed with specific tasks requirements in mind, rather than interoperability of the varied equipment types. For example, the operating conditions experienced by high altitude equipment is significantly different from that used in desert conditions and interoperation of tactical equipment with telecommunication equipment was not an expected outcome. Currently, most military networks operate with a fixed Network Operations Center (NOC) that physically manages the configuration and evaluation of all field devices. Once configured, the devices might be deployed in fixed or mobile scenarios. Any configuration changes required would need to be appropriately encrypted and authenticated to prevent unauthorized access. Hierarchical management of devices is a common requirement of military operations as well since local managers may need to respond to changing conditions within their platoon, regiment, brigade, division or corps. The level of configuration management available at each hierarchy must also be closely governed. Since most military networks operate in hostile environments, a high failure rate and disconnection rate should be tolerated by the Network Management System (NMS), which must also be able to deal with multiple gateways and disjoint management protocols. Multi-national military operations are becoming increasingly common, requiring the interoperation of a diverse set of equipment designed with different operating conditions in mind. Furthermore, different militaries are likely to have a different set of standards, best practices, rules and regulation, and implementation approaches that may contradict or conflict with each other. The NMS should be able to detect these and handle them in an acceptable manner, which may require human intervention." 2.TBD Vehicular Networks ------------------------ (a) Since there are management requirements and restrictions that arise out of mobility of nodes, and vehicular networks is a case that highlights these well, it would make sense to include this use case within the document as well. As a starting point, I propose the following text: "2.TBD Vehicular Networks ------------------------ Networks involving mobile nodes, especially transport vehicles, are emerging as a new area. Such networks are used to provide inter-vehicle communication services, or even tracking of mobile assets, to develop intelligent transportation systems and drivers and passengers assistance services. Constrained devices are deployed within a larger single entity, the vehicle, and must be individually managed in this scenario. Vehicles can be either private, belonging to individuals or private companies, or public transportation. Scenarios consisting of vehicle-to-vehicle ad-hoc networks, a wired backbone with wireless last hops, and hybrid vehicle-to-road communications are expected to be common. Besides the access control and security, depending on the type of vehicle and service being provided, it would be important for a Network Management System (NMS) to be able to function with different architectures, since different manufacturers might have their own proprietary systems. Unlike some mobile networks, most vehicular networks are expected to have specific patterns in the mobility of the nodes. Such patterns could possibly be exploited, managed and monitored by the NMS. The challenges in the management of vehicles in a mobile application are manifold. Firstly, the issues caused through the device mobility need to be taken into consideration. The up-to-date position of each node in the network should be reported to the corresponding management entities, since the nodes could be moving within or roaming between different networks. Secondly, a variety of troubleshooting information, including sensitive location information, needs to be reported to the management system in order to provide accurate service to the customer. The NMS must also be able to handle partitioned networks, which would arise due to the dynamic nature of traffic resulting in large inter-vehicle gaps in sparsely populated scenarios. Constant changes in topology must also be contended with. Auto-configuration of nodes in a vehicular network remains a challenge since based on location, and access network, the vehicle might have different configurations that must be obtained from its management system. Operating configuration updates, while in remote networks also needs to be considered in the design of a NMS.”