Identifying mobile network devices

Network as Code supports multiple ways to identify devices in different networks. These identifiers both identify the specific device and are also used to route requests to the right networks and operators.

Identifying devices by phone numberheader link

Phone numbers are the most common and easiest to understand mechanism for identifying a device. It is also simple for users, since people are generally able to know or find out the phone numbers their devices are using.

The phone number parameter works as a string and it accepts the "+" sign for country code, but not spaces or "()" marks. A valid phone number format looks like this: "+36721601234567".

Identifying devices by network access identifierheader link

A network access identifier is an alternative, stable device identifier that can be used if a device doesn't have a phone number and to route requests into more specialized networks, such as private 5G environments, digital twins and other special purpose systems.

Network access identifier is given in an email-like format of <device-identifier>@<domain>, where the domain part corresponds to the network into which the requests will be routed. The device identifier can be essentially of any format and is dependent on the network. However, in some cases it is possible to specify the type of the identifier with a type prefix.

Network as Code supports the following device identifier type prefixes for network access identifiers:

Since the valid network access identifiers for devices can vary depending on the system you are integrating with and the correct device identifier is not necessarily obvious, you should consult the systems and information specific to your network and use case to determine the correct identifiers for your devices.

Identifying devices by IP address and portheader link

Some of our APIs require IP address information to work correctly. However, IP addresses are considered ephemeral identifiers and may change over time. IP addresses must therefore be accompanied by a stable identifier, such as an external identifier or a phone number, for all device-specific requests.

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.

Identifying devices behind network address translation (NAT)header link

IPv4 address space is limited, so most networks use network address translation (NAT) to map one public IPv4 address to multiple devices.

This means that mobile devices generally cannot be identified only by their public IPv4 address. This means that, for example, for a QoD session to be established, you will need to specify either of the following:

Identifying devices with a dedicated public addressheader link

In case you have access to a device with a dedicated IPv4 address without NAT, this address is enough to identify the device. However, our APIs may still require you to provide two pieces of identifying info. In this case, you can just provide the same address both as the public address and the private address. Our SDKs will also copy the public address into the private address field, if only a public address is provided.

Identifying mobile network devices with multiple parametersheader link

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(
    "[email protected]",
    # 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 does not accept spaces or parentheses
    phone_number="+36721601234567"
)

TIP: On this page, we further detail which parameters the Client method can contain.

Last updated November 05, 2025