Identifying mobile network devices
There are different ways you can identify devices.
You can use an external ID (e.g.: "device@testcsp.net"
), IP address with an optional port and phone number.
Identifying devices by external ID
A Device ID is an email-like external identifier for a device (or subscriber) into the network.
It works as a device object created to manage a particular device on the network, for example: device@testcsp.net
.
Check how it's used in the SDK snippet below.
Identifying devices by IP address and port
Our DeviceIPv4Addr
model allows you to specify Ipv4 and Ipv6 addresses to uniquely identify devices
in order to easily and safely program mobile network features.
Why does the DeviceIpv4Addr model require public or private IP addresses and ports to create a QoD session?
NAT technology:
As you know, private (local) IP addresses are unique and can be assigned in a private network to securely connect to other resources. That's why, they can be more secure than public (observed) IP addresses since they cannot be seen online as it would happen with public addresses.
Network Address Translation (NAT) helps offering an extra layer of security by hiding the private (local) IP address from external networks and mapping it to a single public address. It is also a technique that enables sharing a public IP address among multiple resources.
NAT64, on the other hand, acts like translator that enables IPv6-only devices or resources to communicate with IPv4 ones. So, NAT64 helps bridging the gap between the older (IPv4) and newer (IPv6) protocols by enabling the communication among resources using them.
Carrier-grade NAT (CGNAT) is an alternative to NAT and it allows sharing public IP addresses among multiple customers. Network Operators use it to preserve the amount of public IP addresses, since it is already exhausted. The idea is that the IPv4 range is too narrow to be used as a complete IPv4 address for a device. So, either the private IP address or the ports in use defines a sub-range, which enlarges the original 32-bit range of the IPv4 address.
Why do I need to include private, public IP addresses and port?
Mobile devices cannot be identified only by their public IPv4 address.
For the network translation to happen and the QoD session to be established,
you will need to specify either of the following to the DeviceIPv4Addr()
model:
- Public address and port.
- Public and private (local) addresses (this is the preferred method).
So, NAT technology is applied here, and you can choose to provide information according to which one is known at the moment.
NOTE: The IPv6 address parameter can also be provided in a separate field outside the
DeviceIPv4Addr()
model.
Identifying devices by phone number
The phone number parameter works as a string and it accepts the "+" sign, but not spaces or "()" marks.
Prefer to use only numbers, such as "36721601234567"
.
Check the complete snippet below to see all the different ways to identify a device in practice:
Identifying mobile network devices with multiple parameters
Here is an example of how DeviceIPv4Addr
works in our SDK:
import network_as_code as nac
from network_as_code.models.device import DeviceIpv4Addr
client = nac.NetworkAsCodeClient(
token="<your-application-key-here>"
)
my_device = client.devices.get(
"device@testcsp.net",
# Provide either the public and private address
# or the public address and port.
# Devices cannot be identified by their IPv4 address alone.
ipv4_address=DeviceIpv4Addr(
public_address="233.252.0.2",
private_address="192.0.2.25",
public_port=80
),
ipv6_address="2001:db8:1234:5678:9abc:def0:fedc:ba98",
# The phone number accepts the "+" sign, but not spaces or "()" marks
phone_number="36721601234567"
)
TIP: On this page, we further detail which parameters the
Client
method can contain.
How to gather the necessary information to identify devices?
Phone numbers are the most well-known device identifiers, but how can you identify devices in other ways, in case an IoT device does not have a phone number?
That is why the Device ID (also referred to as External Identifier or Network Access Identifier,
e.g.: device@testcsp.net
) can work as an alternate.
In Business to Business (B2B) scenarios, the enterprise owns mobile subscriptions for the devices, and they obtain it from the Network Operator. So, they would know their Device IDs. Enterprises should provide the Device ID related information so that their applications can use them to identify the devices on the mobile network.
In Business to Consumer (B2C) scenarios, phone numbers can act as a simple identifier for devices or users owning the mobile subscription.
IP Addresses are dynamic. So, they are difficult to identify in advance. Whoever owns the IoT device will need to implement a way for it to tell its current IP address(es). Let's suppose you or a client owns a business that manages flying drones. Then, you (or the client) would have an operations center to manage/control these drones. They would need to connect to this operations center whenever they were on and send their connection details with current IP address(es).
Last updated on July 25, 2024