How To Test New Cellular Stuff in the Wild?

Having a lab as a network operator is a great thing. You can test new hardware and software there and once you are happy you can deploy things in the wild and make things better for your subscribers. But every now and then something comes along that you don’t only want to test in the lab but you actually want to have a proper shakedown to test stability and functionality before you let your subscribers use the new technology. So how can this actually be done in practice?

3GPP has quite a number of options available to restrict access to some parts of the network. Depending on the circumstances, one or the other, or a combination of them can be used.

Use A Different Mobile Network Code (MNC)

The easiest way to separate new equipment from the operational network is to use a different Mobile Network Code (MNC) in these cells, run them on a channel not used by the live network and to use special SIM cards that can attach to this network. Devices with ‘normal’ SIM cards don’t consider cells with this network code as part of the network and would thus not even try to attach unless they run out of coverage. And when they do, the network simply rejects them, just like other networks in the country would do as well.

Reserve the Cell For Operator Use

In other cases it is undesirable to use a mobile network code that is different from the live network. For this case, 3GPP has specified the ‘cellReservedForOperatorUse’ parameter in the System Information Block 1 (SIB-1) message. When this parameter is set to ‘restricted’, only devices with SIM cards that are subscribed to Access Class 11 and 15 will try to access the cell. SIM cards of ‘normal’ subscribers have a bit set for Access Class 0 to 9 so mobile devices with such SIM cards stay out of those cells.

Use Intelligent Reject Causes

And yet another option to have cells for yourself is to configure them with a  Tracking Area Code (TAC) that is different from that of the ‘normal’ cells in the area. Subscribers trying to access these cells would thus have to make a Tracking Area Update request and can then be rejected with cause #15, ‘no suitable cells in this tracking area’. The devices would then immediately go to the ‘normal’ cells. If you want to make sure that the devices you want to test with only access those cells but not other live network cells, you reject those with reject cause #15 in the ‘normal’ cells. In other words, ‘normal’ subscribers stay in the normal cells while your test mobiles only use the test cells. This of course requires some magic in the core network but the approach has the beauty that no modifications in the radio network or on the SIM card is required.

Another nice thing about this approach is that the test frequency layer does not have to be announced in the live network cells, so no reconfiguration of cell parameters is necessary. If the test device first ends up in the live network after power-up and is rejected in all LTE, UMTS and GSM location and tracking areas, devices will do a full scan and eventually find the test cell that was not announced by the live network. Also, devices remember all location and tracking areas in which they were rejected and don’t try to go there again until they are power cycled. So while it might take half a minute or so to find the test cells after power-up, devices will not try to go to ‘normal’ cells anymore after that and behave in a ‘realistic’ way, i.e. perform cell changes from one test cell to another without delay.

Brute Force: Frequency Lock

And yet another way to restrict test devices to test cells is to reserve a frequency for those cells in an area and then lock them to that frequency. The nice thing about this is that no network side changes are necessary. Unfortunately, locking devices to a frequency is a pretty invasive thing and is typically not straight forward to do in commercial devices. If you want to make sure ‘normal’ subscribers don’t use cells on that frequency layer, you still have to reject them with cause code #15 which again requires some magic in the core network.

Which of the methods should be used in practice highly depends on on the circumstances and there is no ‘one size fits all solution’.

Question: Any other cool approach I have missed here?