Skip to main content

The Big M2M To Consumer RSP Migration Debate!

Written by: Iain Maxwell

As a mature technology Machine-to-Machine (M2M) has been re-invigorated by the introduction of the embedded SIM (eUICC). The eUICC is now being introduced in consumer devices and in a few years remotely switching profiles in all mobile devices will become a common occurrence.

It is likely that the M2M specifications will be merged with the Consumer RSP specifications to become a single specification for both markets. But there has been a lot of debate on how – or even whether - to do this. But what is the best option? Is the current separation something that the industry can live with? The following options have been identified:

  • Evolve Consumer RSP Subscription Managers to support both M2M and Consumer RSP eUICCs, OR
  • Evolve Consumer RSP eUICC to support M2M Use Cases


M2M historically has been around for many years enabled by the legacy UICC targeted at business-to-business (B2B) use cases before the arrival of eUICC. M2M using eUICC is a ‘push’ mechanism where the servers perform remote profile management OTA on request of the MNO or Service Provider (SP). Consumer RSP was then developed afterwards targeted at business-to-customer (B2C) use cases where the end-user is in control of local profile management over-the-internet (OTI) using mobile data or Wi-Fi ‘pulling’ profiles from the servers as required.
At the conception of Consumer RSP it is unclear if a combined architecture was envisaged to provide a framework for both the existing M2M solution and the new Consumer RSP solution architectures. But given that the core task of loading a profile onto the embedded SIM is the same for either solution it would have been a logical approach if the two different markets originated at the same time. However, the resulting Consumer RSP architecture is quite different from the M2M architecture due to the ‘push’ nature of M2M and the ‘pull’ nature of Consumer RSP.



M2M architecture and Consumer RSP architecture


Consequently the following business and architectural differences exist:

  • M2M is a ‘push’ service solution whereas Consumer RSP is a ‘pull’ service solution.
  • Service Provider in current M2M architecture is replaced by the End-User in the Consumer RSP solution.
  • M2M uses OTA BIP (Bearer Independent Protocol) and Consumer RSP uses mobile data or Wi-Fi OTI
  • The Subscription Manager-Secure Routing (SM-SR) in M2M is no longer be required in Consumer RSP and is replaced by a combination of the Subscription Manager-Data Provisioning+ (SM-DP+) and the Local Profile Assistant (LPA) acting as a local proxy application to perform local profile management in Consumer RSP.
  • The LPA was also introduced for Consumer RSP to manage connectivity and also to enable the support of Wi-Fi to improve scalability of the Consumer RSP solution. The LPA can be located in the device as LPAd or in the eUICC as LPAe.
  • The Subscription Manager-Discovery Service (SM-DS) was introduced for Consumer RSP to ensure that profile download notifications from the SM-DP+ can be pulled by the end user to their device partly replacing the SM-SR.
  • The architecture of the Consumer RSP eUICC is slightly different from the M2M eUICC as it needs to support the new functions on the LPA interface, not to mention the potential differences if the LPAe is used.
  • The M2M architecture uses a Pre-Shared Key (PSK) infrastructure to establish secure channels to the eUICC whereas the Consumer RSP architecture uses a public key infrastructure (PKI) infrastructure.

It is clear then that although the business use cases are quite similar there are different entities in the ecosystem that impact business processes for each solution and also the two resulting architectures are very different.


Irrespective of the approach taken, there are differences at the business and technical levels that would need to be overcome to enable a successful merge of the two technologies.

Evolve Consumer RSP Subscription Managers to support both M2M & Consumer RSP eUICCs

In this option either the SM-DP+ would merge with the SM-SR and SM-DP to create a new platform, or the SM-DP+ is upgraded to support both M2M and Consumer RSP eUICCs. But in either case this would mean that the new platform or enhanced SM-DP+ (SM-DP++) has to be able to identify the type of eUICC in the device that it is communicating with. It would then need to ensure that the correct eUICC profile type is used along with the correct crypto scheme; PSK or PKI. The advantage of this approach is that M2M and Consumer RSP eUICCs already deployed in the field can still be targeted and communicated, but the disadvantage is the increase in complexity and cost of the new server platform.

Evolve Consumer RSP eUICC to support M2M Use Cases

In this option the Consumer eUICC evolves to support M2M use cases resulting in one new type of eUICC. The advantage to this approach is that Consumer RSP uses the more efficient PKI infrastructure where no SCP03t keysets are actually stored discarding M2M’s PSK architecture and benefit from the use of Wi-Fi and mobile data over-the-internet (OTI) to provide a scalable solution. The M2M’s SM-DP and SM-SR could then still communicate with original M2M eUICCs in the field until ‘end of life’, and this new type of eUICC could be included in all new M2M or Consumer RSP devices now communicating with the Consumer RSP’s SM-DP+ and SM-DS.
But the disadvantage of this option is that the SM-DP+ would need to be upgraded to handle the ‘push’ nature of the M2M use cases and prohibit the ‘pull’ nature of the Consumer RSP use cases when an M2M device was being targeted. Therefore Consumer RSP SM-DP+ would again need to be updated to be able to identify the type of device that it is communicating with. It also doesn’t seem feasible that all M2M devices could support an LPAd that is required to deliver Wi-Fi and mobile data for scalability as that would drive up cost in the wrong side of the one-to-many relationship that the device has with the server side. Therefore the LPAe would be the only option.


GSMA’s M2M and Consumer RSP use cases are still quite separate but it can be envisaged in the future that the differences between these use cases becomes more blurred creating a compelling business use case for convergence. A corporate entity may choose to manage all of their Consumer RSP device connectivity as if they were M2M devices, or in the automotive industry the end-user may want to perform local profile management on their M2M device after the initial connectivity deal with the vehicle vendor expires. ETSI are also developing an eUICC based technical solution and although not officially released ETSI TS 103 384 tries to support both M2M and Consumer use cases (although it’s not clear how this relates to or would work with the GSMA solution).
Plus a major benefit of merging the two specifications would be that the Consumer RSP architecture delivers a more flexible and scalable approach to remote provisioning. But either option discussed so far requires complex and costly technical changes to the architecture and technical specifications. Evolving Consumer RSP Subscription Managers to support both M2M & Consumer RSP eUICCs only impacts the server side but evolving the Consumer RSP eUICC to support M2M use cases impacts both the eUICC and the server sides plus the M2M architecture would still need to be supported for 10-15 years before it could be completely phased out. Therefore, theoretically it seems that evolving Consumer RSP Subscription Managers to support both M2M & Consumer RSP eUICCs would be the best approach.
Convergence isn’t always necessarily a good thing and the pragmatic solution for GSMA might be just be to keep the two different solutions aimed at two different markets. The resulting over-complication of the specifications and any architecture adjustments required to merge both solutions might not be a worthwhile exercise. 
Ultimately the RSP teams at GSMA will decide whether to merge the two different solutions or not, but it is not expected to be addressed in the next major release of the Consumer RSP specifications due in Q4 2017.