In the recent years, power consumption of the UE has become a very important aspect due to the rise of several IoT use cases that require that the device remains active for long periods of time, without the possibility to re-charge it. The overall power consumption is obviously composed by the sum of the power consumption of the ME and the power consumption of the UICC.
3GPP conducted a study on the power consumption of the UICC, available in TR 31.970
. This study was shared with ETSI SCP and was the basis to define the UICC suspension mechanism, specified in Release 14.
The UICC suspension mechanism allows the terminal to completely remove the power from the UICC and be able to restore the UICC status later on, when the UICC is required. Such a mechanism can significantly improve the power consumption when the duration of the suspension is sufficiently long, as described in the TR 31.970
, and so it is suitable mostly for devices that are idle for long periods of time.
3GPP CT6 expects that power consumption will remain a critical aspect also for the future, with even more use cases enabled by 5G technology. For this reason, the new secure platform should continue to support the suspension mechanism already introduced for the UICC, even if this might be implemented in a different way.
Also, CT6 encourages SCP to consider additional improvements to reduce the power penalty introduced by the UICC resume operation. This would have two benefits on the UE:
further improve the power saving for devices that are idle for long periods of time
ability to potentially extend the optimization to new classes of IoT devices that are idle for shorter periods of time.
As described in the TS 31.970
, the presence detection polling and the proactive polling performed by the ME are also causes of considerable power consumption. In the current 3GPP specifications, the presence detection polling can be suspended when the UE is idle, and the proactive polling can be disabled by the operator. These changes allows the device to avoid unnecessary polling, with the goal of saving power.
Polling should be taken into consideration while working on the new secure platform, in order to limit it only to cases where it is strictly required, trying to define solutions that allow complete disablement of polling, without compromising on the ability of the secure platform to initiate a proactive session or on the ability of the device to detect a removal of the secure platform (where the removal is possible at all).
In the current 3GPP specifications, only two classes of operating condition are considered valid, that is class B (3.0V) and class C (1.8V). The voltage of the UICC has a clear impact on the amount of power that is consumed by the UICC itself and by the terminal.
Moreover, with the reduction in node technology on the terminals, support for class B has become more expensive, as it requires external power sources. For the same reason, also support for class C is currently at risk.
Since the new secure platform may potentially break backward compatibility with the UICC specification at electrical level, it is recommanded to avoid including any requirements for 3.0 Volts.
CT6 is not aware of specific electrical interfaces that ETSI SCP is considering for the new secure element, and if the existing UICC interface specified in TS 102 221 
will continue to be used at all. In any case, if a specification for the electrical interface is defined, it is recommanded to consider also the addition of a new class that works below 1.8 Volts.
In the existing UICC platform, there are several cases where the device needs to send multiple commands to perform what is logically a single operation. A good example for this is the access of the emergency numbers, stored in the USIM application. The terminal needs to first perform a SELECT command to retrieve the properties of the EF, such as the total number of records and the length of each record, and then needs to perform separate READ RECORD command for each record, regardless of the size of each one.
This access is inefficient in terms of delay and power, as it requires that the terminal is awake while it performs these operations, often waiting for the UICC to respond.
For this reason, SCP is encouraged to consider solutions that limit the number of commands required to access the content stored in the new secure platform, or to perform other operations.
One of the aspects discussed in the recent years was the execution time of certain commands, as described in the LS C6-130181 that was sent to ETSI SCP. As a solution for the problem, the maximum power consumption of the UICC was increased starting with Rel.12.
A fast execution time of commands is an essential part for the new secure element. This is important not only to make sure that all procedures described by 3GPP are performed in a timely and correct way, but it also contributes to the overall power reduction, as the terminal needs to be awake waiting for a response from the UICC for a shorter time.
The execution time is a result of an optimsation between processor capabilities, power consumption and clock frequency. The current interface uses a clock provided by the ME. The power consumption that is allowed for the UICC is clearly defined, which is certainly required for the currently specified form factors for the UICC, especially the removable ones. Setting clear limits for the power consumption was necessary to ensure proper inter-operability.
With the integrated form factor, such inter-operability is not required, as the ME manufacturer is able to design the interface according to the requirements of the chosen secure platform and therefore an optimisation is possible.
Another aspect is the clock frequency. As said, in today's interface the clock is provided by the ME. An internal clock inside the secure platform would allow for faster execution.CT6 encourages SCP to consider solutions that minimize the execution time of commands sent to the new secure element, while still taking into consideration the requirements to save power.
For many use cases in IoT, devices may be optimised in size, functionality and according to the specific needs of the IoT application they are intended for. Some devices may be very small, e.g. simple sensors and may have specific requirements related to size and power consumption.
For such devices it would be beneficial to have a flexible choice of form factor of a UICC that is optimally fitting to the design of such constraint devices. Due to the variety of IoT use cases a large variety of specialised device designs is envisaged. Aspects that are to be considered are for example the form factor, removability, the size, the location and number of contacts.
In several use cases for IoT it may also be beneficial for a device to not have to implement the current ISO interface to a UICC but rather rely on interfaces and protocols already in use inside the device. Examples of such interfaces are I2C or SPI.
Additional aspects to consider are:
Number of wires
Power efficiency (e.g. polling)