Mobile operator Vodafone UK conducted another trial of Network Slicing technology on their latest 5G Standalone (SA) powered mobile broadband network at this year’s Glastonbury Festival, which despite heavy network load was able to dedicate a “slice” of capacity to help drink vendors speed up card transactions.
Most existing 5G networks in the UK still have some dependencies on 4G, which slow them down and are known as Non-Standalone (NSA). By comparison, 5G Standalone (5GSA) reflects a pure end-to-end 5G network that can also deliver improvements such as ultra-low latency times (fast), better mobile broadband upload speeds, network slicing capabilities, better support for Internet of Things (IoT) devices, increased reliability and security.
Vodafone has already conducted a number of Network Slicing trials on their newest 5GSA network and the Glastonbury Festival, with its high data usage, represented another opportunity. In fact, the operator reveals that festival-goers consumed over 225 TeraBytes (TB) of data during the event (up 33.14% on 2023), which put a huge load on their Cells on Wheels (COWs) masts and network setup (particularly during Coldplay’s headline performance when over 258GB of data was uploaded).
Advertisement
Building a telecommunications network for over 200,000 people in a small area is naturally a complex task at the best of times, particularly when you have to both cater for visitors and keep on-site businesses connected to vital services at the same time. As such, the operator also used the festival to test whether dedicating a portion (slice) of the network to keep EBC payment machines connected would work (EBC managed 10 on-site bars).
Ryan Kingsley, Stock Manager at EBC, said:
“Running some of the busiest bars at Glastonbury, it is so crucial that we have a stable data connection with the capacity to operate our tills. The Vodafone slice ensured that the three bars supported in the demonstration had that stable data connection and helped us serve our customers faster than ever before!”
The slice was optimised to support the maximum number of concurrent transactions during peak busy periods and was protected from the risk of wider network congestion at the event. The result was that payment machines were not impacted by general data usage, meaning customers were served faster and didn’t need to spend as long in a queue.
Real-time connectivity is crucial to authorising card payments. Without real-time authentication of payments, it is estimated that 4% of revenues can be lost to fraudulent transactions.
How is the network slice presented so that card payment machines (as in this example) are using that slice of the network? Is it done by identifying the source and destination/type of the traffic or in some other way?
It’s the SIM card, the payment machines very likely have a SIM card in them or they are connected to a eg. a WiFi router that will be getting it’s internet connection via a mobile connection of which the SIM card is part of the slice, all data from the SIM card will be in the slice
Most likely with something like dedicated APNs for those end devices, a little like how Three have a dedicated APN for mobile broadband v normal mobile phone traffic. Would require them to be configured one time and forget.
It’s complex: the network tells the device (based on SIM identity) which slices are available to it, and both the device and network are involved in the decision about what traffic goes to which slice.
The simplest setup (and the one I suspect Vodafone used for this demo) is to only allow each SIM access to a single slice; this then means that the network behaves as-if Vodafone were running multiple networks (one network for each slice), but more efficiently (since the network can allocate resources dynamically to each slice – so if the card readers are idle, instead of the network resources assigned to them going unused, they can be reused for “normal” users).
However, you can attach to multiple slices at once; when you do that, it’s up to the network and device to decide which traffic goes to which slice. The device does know the difference between the slices, so it can choose the right slice for each bit of traffic, and the network can do the same, based on any information the network and device have about the traffic. So, for example, you can configure things so that traffic to and from the bank goes in the card slice, e-mail traffic goes in a background slice, while other traffic goes in the general slice.
If you’ve ever worked in networking, 5G slicing is basically taking MPLS traffic engineering capabilities, and extending them all the way over the RAN down to the device; anything you’d use to select traffic in an MPLS network is also an option in 5G slicing.
Likely by its simcard
Not certain but I’d imagine it’s just a case that it was done via IMEI. Add them into the network config as having that slice and bam.
Probably a bit more to it than that though
Unsure of the specific scope of the test, but the intention is that network slices will also be something that can be configured by APIs.
So your phone would be able to do things like once you install your work email app, a slice can be configured for that so the mobile network basically provides you a VPN automatically
https://source.android.com/docs/core/connect/5g-slicing
So a use case here could be that a vendor installs the card payment app on their phone, and the phone communicates with the network to make sure that app always gets priority even when it’s congested