IoT Security 259
orchestrator is used to distribute the malicious patterns and information on malicious robots to all cloud service providers (MVNOs), so they can also retaliate to the
malicious intent. This enhances the scalability of the proposed platform and makes it
a secure distributed platform.
11.5 Mobile Cloud Robot Security Scenarios
Machine‐type communication is increasingly important to both government entities
and enterprises, where the private LTE networks are used to support the application of
drones and robots for military, transportation and energy industry services. Government
entities deploy private LTE networks for emergency and strategic situations, where an
anomaly in the original function means the difference between life and death, such as
in military, national security and emergency services. Therefore, a secure communication
is a major consideration for governments as well as some enterprise entities, such as
energy, transportation, etc. [20–22].
In this chapter, we propose an orchestrated security platform for Internet of robots
that is applicable to entities that use private LTE networks as well as commercial service
providers. On the other hand, based on the robot connectivity to the network, two
scenarios: robot‐with‐SIMcard and robot‐without‐SIMcard, are considered for the
proposed platform.
11.5.1 Robot with SIMcard
As shown in Figure 11.8, we consider “n*m” robots, which belong to “n” different brands,
while robots belonging to brand 1 and brand 2 are connected to MVNO1 and robots
belonging to brand “n” are connected to MVNO2. In this scenario, each robot has a
Subscriber Identity Module (SIM) card. If robots are belonging to a commercial network (and not a private LTE network), LRC is installed at Base Transceiver Station
(BTS) nodes for cost savings.
As shown in Figure 11.9, when a robot tries to connect to a mobile network, first the
robot is authenticated internally by LRC and information is analyzed. Based on the policies or rules that are locally defined in the LRC, the traffic would be either dropped or
passed to related MVNO. If the traffic is dropped at LRC, a notification message would
be sent to the parent MVNO. Later parent MVNOs will inform other MVNOs about
malicious robot through an IoT orchestrator. If the traffic is safe and traffic arrives at the
MVNO1, an IoT anomaly detection module in MVNO1 will analyze whether the traffic
is safe or not.
If the traffic is not safe, it will be dropped and a message sent to associated LRC, and
through an associated IoT orchestrator, to other MVNOs. If the traffic is labeled safe by
an IoT anomaly detection module, the MVNO will forward the robot attach request to
MME and HSS/AAA for the authentication procedure. After the robot is authenticated,
the robot User Plane (UP) data would be forwarded to the mobile network for further
analysis. The same anomaly detection procedure will be applied to UP data, and safe
traffic would be forwarded to mobile network. The above‐mentioned procedure is illustrated in Figure 11.10.
orchestrator is used to distribute the malicious patterns and information on malicious robots to all cloud service providers (MVNOs), so they can also retaliate to the
malicious intent. This enhances the scalability of the proposed platform and makes it
a secure distributed platform.
11.5 Mobile Cloud Robot Security Scenarios
Machine‐type communication is increasingly important to both government entities
and enterprises, where the private LTE networks are used to support the application of
drones and robots for military, transportation and energy industry services. Government
entities deploy private LTE networks for emergency and strategic situations, where an
anomaly in the original function means the difference between life and death, such as
in military, national security and emergency services. Therefore, a secure communication
is a major consideration for governments as well as some enterprise entities, such as
energy, transportation, etc. [20–22].
In this chapter, we propose an orchestrated security platform for Internet of robots
that is applicable to entities that use private LTE networks as well as commercial service
providers. On the other hand, based on the robot connectivity to the network, two
scenarios: robot‐with‐SIMcard and robot‐without‐SIMcard, are considered for the
proposed platform.
11.5.1 Robot with SIMcard
As shown in Figure 11.8, we consider “n*m” robots, which belong to “n” different brands,
while robots belonging to brand 1 and brand 2 are connected to MVNO1 and robots
belonging to brand “n” are connected to MVNO2. In this scenario, each robot has a
Subscriber Identity Module (SIM) card. If robots are belonging to a commercial network (and not a private LTE network), LRC is installed at Base Transceiver Station
(BTS) nodes for cost savings.
As shown in Figure 11.9, when a robot tries to connect to a mobile network, first the
robot is authenticated internally by LRC and information is analyzed. Based on the policies or rules that are locally defined in the LRC, the traffic would be either dropped or
passed to related MVNO. If the traffic is dropped at LRC, a notification message would
be sent to the parent MVNO. Later parent MVNOs will inform other MVNOs about
malicious robot through an IoT orchestrator. If the traffic is safe and traffic arrives at the
MVNO1, an IoT anomaly detection module in MVNO1 will analyze whether the traffic
is safe or not.
If the traffic is not safe, it will be dropped and a message sent to associated LRC, and
through an associated IoT orchestrator, to other MVNOs. If the traffic is labeled safe by
an IoT anomaly detection module, the MVNO will forward the robot attach request to
MME and HSS/AAA for the authentication procedure. After the robot is authenticated,
the robot User Plane (UP) data would be forwarded to the mobile network for further
analysis. The same anomaly detection procedure will be applied to UP data, and safe
traffic would be forwarded to mobile network. The above‐mentioned procedure is illustrated in Figure 11.10.