White paper excerpt
Advanced IoT Policies
Mobile operators must use advanced policy control to customize their IoT services for each customer’s needs and use case.
As discussed, in our post why cellular IoT is another story, providing granular policy control for IoT enterprise customers in a mobile core designed to handle a handful of smartphone subscription types is challenging.
This is another good reason for adding the hyperscale programmable layer of policy control and security such as the Enea Aptilo Connectivity Control Service (IoT CCS). Adding such a layer is a prerequisite to delivering a unified IoT service with granular policy control across all mobile operator partners’ networks.
It will also facilitate the creation of a customer self-management portal, where the IoT Enterprise customers can handle their policy and security settings.
Hyperscale Cellular IoT – White Paper
This is an excerpt from our white paper Hyperscale Cellular IoT. The full white paper is available here if you like what you read. Don’t hesitate to contact us if you have any questions.
Unified UX across all networks
Policy-Based IP Assignment
One would expect that the IP address would not matter so much in modern architecture. Dynamically assigned IP addresses should be sufficient, and there would be mechanisms that update the IoT back-end when the IP address changes.
However, many enterprise IoT customers rely on keeping the same IP address for an IoT device and even their own IP range for all their devices.
There are many benefits to letting a programmable hyperscale layer handle the IP allocation. The most obvious one is the ability to maintain the same IP address even when a device moves across mobile operator partners’ networks. The allocated private device IP address and the IP address of the primary and secondary DNS server for the IoT device are then provided in the RADIUS response to the MNO’s packet gateway.
The IP allocation should be very flexible. As an example, this is the IP-allocation options for Enea Aptilo IoT CCS:
- Dynamic IP: The IoT device gets a new IP address from the pool at every connection.
- Static IP: The assignment of a specific IP address that always will stay the same.
- Sticky IP: The IP address is allocated from the pool at the first connection, and then the IoT device keeps this IP address as a static IP configuration.
Note that with Enea Aptilo IoT CCS, mobile operators can assign the same IP address to a device also when it is localized by changing its SIM identity to belong to a partner MNO’s network. Learn more about localization of eSIM/eUICC in our upcoming post about global connectivity. This, together with consistent use of policies and security settings,
will provide a unified IoT experience across all partner networks.
Let the customer decide
Policy-Based Advanced Routing
The enterprise customer should be in complete control over the routing of their IoT traffic.
Some of the traffic, such as firmware upgrades and sensitive analytics data, may need to be routed in secure VPN tunnels. In contrast, all other traffic can go directly to the Internet, protected by firewalls.
Some IoT enterprise customers may need to have multiple VPN tunnels and separate different kinds of traffic into different tunnels.
In global connectivity, some use cases require that the traffic goes the closest route out to the Internet for low latency. Other use cases, such as streaming TV content, may require the opposite. The traffic must be routed to the home country and then out to the internet.
The customer in the driver’s seat
Granular Business and Security Policies
The mobile operator should put their customers in the driver’s seat and allow them to define granular IoT connectivity policies supporting their business and security needs.
Some policies need to be set hierarchically: all devices in the Enterprise, per device group, and down to an individual IoT device.
The business-related policies will vary from customer to customer, but some generally applicable policies include:
- Maximum bandwidth usage.
- Maximum data usage.
- Location down to individual cell level.
- Time of day.
- Approved for service: For example, bill paid, Ok to onboard device.
- Quarantine: The device needs configuration.
Security-related policies that may need to be set include:
- Suspend or enable device/SIM.
- Quarantine: For devices with suspicious behavior.
- URL Lock: Filter traffic so it can only go to specific destinations.
- APN Lock: Prevents SIM hijacking. Each device authenticates to APN with an individual username /password.
- IMEI Lock: A SIM can only be used in a specific device.
- Location lock: The use of a SIM is only possible where you want it to be used.