VSlice
Independent logical networks
VSlices are used to segregate your estate of devices into logical networks. Each VSlice is isolated from all others and so serves as a security boundary which you can control. If you are familiar with public cloud environments, this is similar to a VPC (AWS) or a VNet (Azure). You might create a VSlice for each project, site, team or environment - whatever makes sense for your application.
For example, if you were the organizer of Music Festivals, you might create a VSlice for each festival site or event, and another for testing purposes.
As a customer, you can create as many VSlices as you need for your use cases - and them modify or delete them as required.
Is a VSlice the same as a private APN?
If you are familiar with mobile networks, you may recognize some similarities with a private APN - which is the typical way to provide isolated connectivity. There are some similarities - but VSlices are much more practical, efficient and flexible than private APNs. Everything that can be achieved with a private APN can be achieved with a VSlice but a lot more too.
Creating and managing a private APN is cumbersome - it needs to be configured by each mobile operator, and then also configured on each device. This takes time, is technically complex and so is often expensive - and as a result. It is therefore only practical to have a small number of private APNs - to plan well in advance - and even then, it is only feasible for larger customers with broad requirements which seldom change.
Moving devices between APNs requires reconfiguration of every device - so takes time.
VSlices, on the other hand, are quick and easy to create - and moving devices between VSlices does not require a configuration change on each device. The mapping of a device to a VSlice is managed within the network - it does not require special SIM designs, provisioning processes, or manual configuration.
A private APN typically provides a connection to a single network, with either no inherent security or only very basic controls. A VSlice, in conjunction with a Routing Policy, allows different traffic to be routed to different networks - and with powerful, fine-grained control over security.
IP Subnets
When creating a VSlice (via the portal or API), you will also need to create one or more IP Subnets which are used to assign IP addresses to endpoints. IP Subnets can be 'static' or 'pooled'.
| Type | Meaning |
|---|---|
| static | The internal IP address of the endpoint will not normally be changed, once it has been assigned. Unless a specific IP address is manually specified for the endpoint, the network will choose and assign an appropriate address the first time it accesses the network. This is the recommended setting for most applications |
| pooled | Internal IP addresses are only temporarily assigned to an endpoint for the duration of a session. This is not recommended. |
If you are unsure what IP address range to use, we recommend using 100.64.0.0/10 (see IPv4 Shared Address Space). Only IPv4 addresses are supported at present - please contact support if you would like to use IPv6.
Note that the IP subnets assigned to different VSlices can be the same, or can overlap. This is because VSlices are independent networks which are isolated from each other. Even if you assign the same IP subnet to multiple VSlices, this will not ordinarily allow endpoints within the two VSlices to communicate with each other.
VSlices contain Endpoint Groups (as many as are required), which are used to contain Endpoints (SIMs) with similar requirements or configuration.
As with most objects in the Stacuity platform, when creating a VSlice you specify a Name and a Moniker. The Moniker identifies the object when using the API - whereas the Name identifies it for humans. Before changing a Moniker, consider the implications for any systems which use the API.
Updated 9 days ago
VSlices contain Endpoint Groups. Let's look at that concept next.