Testing M2M and Consumer RSP beyond the specifications
Written by Iain Maxwell.
Why do we need to test M2M and Consumer RSP entities beyond the specifications? Why do it, as it could entail a lot of extra effort? Let’s be honest nobody likes to spend a lot on their testing needs and budgets a frequently quite tight.
The need to perform interoperability testing to determine whether vendor X’s eUICC will really work with vendor Y’s SM-SR in M2M or vendor Z’s SM-DP+ will ensure that the eUICC and Subscription Manager via the device deliver the required customer experience. So that’s the reason we test, but do we really need to go beyond the current set of testing defined by the related industry bodies? There are a range of different reasons what that is the case. Currently full test coverage of all the entities is not in place and some areas that are in place are not fully addressed. We are talking about a combination of factors; hardware, software, network, eUICC, Subscription Manager, and device that are interchangeable and in many cases dynamically switchable.
Over the next month I will analyse the different testing issues related to the eUICC, Subscription Manager and device to determine and explain where we need to test M2M and Consumer RSP entities beyond the specifications.
Specifically we will look in detail at the functional testing, where applicable the testing of the profile, the logical security testing and finally the physical security testing that is performed in the M2M and Consumer RSP industries.
Defining the M2M and Consumer RSP test landscape
To determine what can and cannot be tested in the M2M and the Consumer RSP domain’s we first need to look to the two different architectures for M2M and Consumer RSP to identify the different entities in each architecture.
In this blog I won’t cover the detailed functional differences in the different architectures, but I will consider the fact that Embedded SIM (ES) interfaces in both architectures need to be tested for the entities that are in scope.
Both architectures have the same entities; Certificate Issuers (CI), eUICC Manufacturers (EUM), eUICC and MNO or Operator entities (which are actually the same entity). However, the main differences in the architectures are related to the ‘push’ nature of M2M Vs the ‘pull’ nature of Consumer RSP. So on the server side we have a Subscription Manager for Data Provisioning (SM-DP) and a Subscription Manager for Secure Routing (SM-SR) for M2M. Then on the Consumer side we have a Subscription Manager for Data Provisioning Plus (SM-DP+) and Subscription Manager for Discovery Service (SM-DS to consider. Plus Consumer introduces the End User and the Local Profile Assistant (LPA) that the End User interacts with to ‘pull’ the profiles on demand.
You can also see that some of these interfaces are out of scope in the GSMA core specs. Therefore using this knowledge we can define a list of entities that are ‘in’ and ‘out of scope’ for the testing, enabling us to set the baseline to determine where we might need to test beyond the current specifications.
Entities Under Test – What’s Out of Scope?
Let’s start first by looking at the entities that are ‘out of scope’ of the testing? The CI, EUM and MNO or Operator are common to both M2M and Consumer RSP, so they are indeed all ‘out of scope’. Although the ES1 interface between the EUM and the SM-SR is actually tested, it is only the SM-SR side that is considered.
The Operator in Consumer RSP should have been in scope, but there are so many different MNO backend implementations it has been difficult getting the MNOs to agree on whether they will actually support the ES2+ interface to the SM-DP+. Then the Local Profile Assistant in the eUICC (LPAe) is not implemented on any existing eUICCs, and it might never be realised. Finally, the End User is obviously out of scope as we cannot test a physical person. So now we have identified the list of entities in both architectures that are ‘out of scope’.
Entities Under Test – What’s in-Scope?
Having eliminated the entities that are out of scope, it is now much easier to define which entities are ‘in-scope’ for the testing. There are obvious similarities between M2M and Consumer RSP. Both the eUICC and Subscription Managers need to be tested, although the Subscription Manager entities themselves are named differently and perform slightly different roles and tasks between M2M and Consumer RSP. The SM-SR is required to locate eUICCs and manage profiles in M2M, but in Consumer RSP the End User is in charge so no need to locate the eUICC, and the SM-DP+ starts to do some of the other things that the SM-SR did – hence the ‘+’. The SM-DP and SM-DP+ do a lot of the same things like storing profiles, encrypting them and downloading them, but Consumer RSP introduces the SM-DS which facilitates the “pushing” of a profile from the Operator for devices that are not pre-configured for their network. Finally, Consumer RSP adds the device or handset along with its local profile management user interface the Local Profile Assistant (LPAd), where ‘d’ in this case means device.
That means we now have a list of entities that are ‘in scope’ for testing. We have the eUICC and the Subscription Manager for both M2M and Consumer, and the Device/LPAd for Consumer RSP only.
Next week we will focus on all the testing issues related to the eUICC. So please join me then for some deep dive analysis.
For a more in-depth discussion with a UL expert, you can contact us.