Hi,
As per the call for reviewing the COMAN documents, I have taken a look at the
latest versions and have a few comments/recommendations for both. The reviews,
along with suggestions on fixing them, are attached to this email in
appropriate files.
Regards,
Anuj Sehgal
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.â2,4c2,11
< ventilation, air conditioning, appliances, and entertainment devices
< to improve convenience, comfort, energy efficiency, and security. It
< can be seen as a residential extension of building automation.
---
> 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 infrastrucutre 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.
8,13c15,22
< electricians deploying home automation solutions 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 electricians in charge of the maintenance of the home
< automation infrastructure.
---
> 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.
16,18c25,30
< be outsourced to electricians providing management of home automation
< solutions as a service. The time scale for failure detection and
< resolution is in many cases likely counted in hours to days.
---
> 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 infrastrucutre. The
> time scale for failure detection and resolution is in many cases
> likely counted in hours to days.
1,10c1,9
< Industrial Applications and smart manufacturing refer not only to
< production equipment, but also to a factory that carries out
< centralized control of energy, HVAC (heating, ventilation, and air
< conditioning), lighting, access control, etc. via a network. 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
---
> 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
20c19
< o Smart sensors detecting anomalies to avoid abnormal or
---
> o Smart sensors detecting anomalies to avoid abnormal or
24c23
< system and externally with the smart grid enabling real-time
---
> system and externally with the smart grid enabling real-time
26a26,35
> 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.).
>
1.3 Network Types and Characteristics in Focus
----------------------------------------------
(a) "Mobile Adhoc networks (MANET) are self-configuring
_infrastructureless_ networks of mobile devices connected by
wireless technologies."
--> Why is a differentiation being made between MANETs and other
types of wireless networks? Couldn't moblie phones technically
fit into the IoT as well? Is the differentiation only made
based on the _infrastructureless_ part of it? If so, does it
make sense to have categories of infrastructure and
infrastructureless, rather than MANET and non-MANET networks?
(b) "Wireline non-constrained networks are mainly used for specific
applications like Building Automation or Infrastructure
Monitoring. However, wireline and wireless networks with
multi-hop or point-to- multipoint connectivity are especially in
the interest of the analysis on the management of constrained
devices in this document."
--> This paragraph is unclear. What is it trying to convey? Is it
saying that only wireline multi-hop and point-to-multipoint
are within the scope of this document? Why not regular
wireline networks that may have constrained devices as part of
a non-constrained network?
--> There is talk about bandwidth, but not frame size, which is
likely to have a bigger impact than the overall bandwidth
available in a channel. Maybe this should be mentioned?
1.6. Managing the Constrainedness of a Device or Network
---------------------------------------------------------
(a) "might only be able to support one simple communication protocol,
i.e. the management protocol needs to be possible to downscale
from constrained (C2) to very constrained (C0) devices"
--> Is it important that the same management protocol be
applicable to the entire range of constrained devices? Why not
allow the capabilities of the management protocol to scale up
and down with the type/capabilities of the device at hand?
SOLUTION: A new bullet point stating that different management
protocols work on different class of devices.
(b) "might only be able to support limited or no user and/or transport
security" AND "might only be able to support very simple
encryption"
--> Simple encryption doesn't make sense, maybe it should be
efficient encryption instead?
(c) "might also need energy-efficient key management algorithms for
security."
--> Not just energy-efficient, but also memory, processing and
etc. efficient. No?
SOLUTION: Change text to only efficient key management.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
