This use case represents a periodic and/or planned file delivery to a large number of devices. Smart water-metering devices are installed in deep indoor and wake up once or twice a day to send the consumption reports to the water-metering network that is regularly extended. The payload size for uplink transmission is in the range of 12 to 100 bytes. Based on growing amount of data, the system configuration is adjusted, requiring the delivery of small configuration updates to all metering devices. Moreover, the water-metering manufacturer regularly provides non-critical software updates for bug fixes, performance improvements, or new features/functionalities. For example, the clause E.2.4 of TR 45.820 estimates a periodic inter-arrival time of 180 days between software update events. This frequency is equivalent to twice per year. Depending on the application, the update frequency can be lower or higher. These devices require a battery lifetime of approximate 15 years and are significantly resource-constrained (processing and storage).

The following recommended requirements are considered:

• The 3GPP system supports the reliable delivery and associated procedures to ensure data integrity.
• The 3GPP system supports the report on successful delivery.
• The 3GPP system supports eMBMS delivery mechanisms and procedures for devices with very limited capabilities (e.g. limited battery life of 15 years, limited processing and limited storage).
• The 3GPP system supports a mechanism to inform the scheduled delivery session to the devices that enables the UE to download the file at the planned schedule time.- The 3GPP system supports a mechanism to acknowledge a successful reception and action required (e.g. successful file update).

In addition, the following recommended requirements are not directly related to 3GPP system but necessary for IoT software update:

• The update needs to be robust. An update does not make the device unusable.
• The update needs to be atomic. An update needs to be completely installed or not at all.
• The update needs to be fail-safe. There is a fall-back mode if the update has failed.

This use case represents the unplanned data delivery to a large number of devices. A device manufacturer wants to distribute a software/firmware update after some bug fixes. These devices may wake up periodically (e.g., every 12 hours to upload measurement data), or dynamically, for instance, when the buffer which contains measurement data is about to be full. The information that a new software/firmware update is available is transmitted during these wake-up periods. The device recommended requirements and constraints are similar to the use case 1.

In addition to the recommended requirements in clause 4.1.2, the following additional recommended requirement is considered:

• The 3GPP system supports a mechanism to inform the UE during its wake-up periods about any newly scheduled download delivery sessions.

This use case represents the unplanned critical data delivery to a large number of devices. A bug in software could be a target for exploitation or is being exploited by unwanted people to perform a massive attack if the devices are connected to the Internet. To solve the issue, a device manufacturer wants to distribute as soon as possible a critical software/firmware update. The device recommended requirements and constraints are similar to the use case 1. But in contrast to use case 2, the device manufacturer wants to speed up the update mechanism such that devices can obtain information on a newly scheduled download delivery session, as opposed to having to wait until the next wake-up period to obtain such information.

In addition to the recommended requirements in clause 4.1.2, the following additional recommended requirement is considered:

• The 3GPP system supports a mechanism to page the UE in order to inform the UE about a newly schedule download delivery session.