Monshizadeh and Khatri
254
yet challenges to be addressed. In addition, if a drone breaks down while performing
an assigned task such as delivering vaccines, the control platform for drones should
guide another drone to replace it and recover the failed drone so it is not stolen to be
used later to gain unauthorized access to the platform of the drone. One can attack,
gain unauthorized access, and divert the mobile robot to an improper location or steal
the data collected. Therefore, security for such an environment (MCR) is extremely
important. However, the overall scope of the proposed architecture is on security‐
related functions, which covers three main security requirements: Authentication,
Authorization, Accounting (AAA), and integrity and availability of data. To fulfil these
security requirements, the data should be collected and sent from LRC to a service
provider for further analysis.
11.4 Distributed Security Platform
Various communication systems may benefit from an improved security. For example,
communication systems that include machine‐type communications may benefit from
improved security and fault detection. This study proposes a platform for enhancing
robots and MVNO security, where robots refer to both fixed robots and drones. The
platform includes detecting an attack based on the robot information and determining
a preventive action. Furthermore, the architecture includes sending an indication of an
attack to LRCs or MVNOs via an IoT orchestrator. An MVNO receives data at an IoT
anomaly detection module from an LRC. The data includes robot user plane and control plane information.
11.4.1 Robot Data Classification
Collected data from robots could be on different protocols, such as HyperText Transfer
Protocol (HTTP) and User Datagram Protocol (UDP). The chosen protocol is robot
vendor specific and based on the robot’s application. In particular, a model could be
tuned based on robot vendor proprietary protocols when their protocol specifications
are known. But, in general, and for all protocols, data is categorized into two groups:
control plane data and user plane data.
Control plane data includes signaling data such as Non‐Access Stratum (NAS),
authentication‐security, bearer request, paging, location area update, etc. User plane
data covers telemetry and command‐control data. Telemetry data is related to application of the robot and geographical location, for example, images, video, measurements
(temperature, speed, etc.) and HTTP traffic. Command‐control data is related to control of the robot such as status check, software update and task management. All user
plane data should be normalized before being processed for anomaly detection.
MVNOs can deny access to their networks for vendors that do not open their data
specifications to the operator and export only normalized data using a commonly
agreed data model, thus hiding vendor proprietary protocol design from other operators and vendors. However, legislation mandates that vendor protocols are open as a
perquisite for approval for license to enter markets. Another way for tuning the model
to process different types of robots’ data is reverse engineering the vendor protocols, in
case the specifications are not communicated.
254
yet challenges to be addressed. In addition, if a drone breaks down while performing
an assigned task such as delivering vaccines, the control platform for drones should
guide another drone to replace it and recover the failed drone so it is not stolen to be
used later to gain unauthorized access to the platform of the drone. One can attack,
gain unauthorized access, and divert the mobile robot to an improper location or steal
the data collected. Therefore, security for such an environment (MCR) is extremely
important. However, the overall scope of the proposed architecture is on security‐
related functions, which covers three main security requirements: Authentication,
Authorization, Accounting (AAA), and integrity and availability of data. To fulfil these
security requirements, the data should be collected and sent from LRC to a service
provider for further analysis.
11.4 Distributed Security Platform
Various communication systems may benefit from an improved security. For example,
communication systems that include machine‐type communications may benefit from
improved security and fault detection. This study proposes a platform for enhancing
robots and MVNO security, where robots refer to both fixed robots and drones. The
platform includes detecting an attack based on the robot information and determining
a preventive action. Furthermore, the architecture includes sending an indication of an
attack to LRCs or MVNOs via an IoT orchestrator. An MVNO receives data at an IoT
anomaly detection module from an LRC. The data includes robot user plane and control plane information.
11.4.1 Robot Data Classification
Collected data from robots could be on different protocols, such as HyperText Transfer
Protocol (HTTP) and User Datagram Protocol (UDP). The chosen protocol is robot
vendor specific and based on the robot’s application. In particular, a model could be
tuned based on robot vendor proprietary protocols when their protocol specifications
are known. But, in general, and for all protocols, data is categorized into two groups:
control plane data and user plane data.
Control plane data includes signaling data such as Non‐Access Stratum (NAS),
authentication‐security, bearer request, paging, location area update, etc. User plane
data covers telemetry and command‐control data. Telemetry data is related to application of the robot and geographical location, for example, images, video, measurements
(temperature, speed, etc.) and HTTP traffic. Command‐control data is related to control of the robot such as status check, software update and task management. All user
plane data should be normalized before being processed for anomaly detection.
MVNOs can deny access to their networks for vendors that do not open their data
specifications to the operator and export only normalized data using a commonly
agreed data model, thus hiding vendor proprietary protocol design from other operators and vendors. However, legislation mandates that vendor protocols are open as a
perquisite for approval for license to enter markets. Another way for tuning the model
to process different types of robots’ data is reverse engineering the vendor protocols, in
case the specifications are not communicated.