The Massive Internet of Things introduces new operational considerations to a 3GPP system. While some support for IoT will be provided by current systems, there is room for improvement in the operational aspects that can be designed into a 5G system whereas they are not easily retrofitted into an existing system. This family includes the operational aspects that will apply to the wide range of devices and services anticipated in the 5G timeframe. These aspects are derived from the use cases included in [2] and cover security needs for IoT as well as support for network servers/applications and devices to identify, address and reach each other.

With the diversity of device types and access interfaces anticipated in the Internet of Things, a security mechanism needs to be designed to meet the service requirements, user and access requirements and deployment models. Since smart devices are expected to support multiple radio access technologies such as 3GPP RAT and non-3GPP RAT, with both access network for 3GPP RAT and access network for non-3GPP RAT connected to the same mobile core network, the core network will need to support authentication methods appropriate to the respective access network to allow a seamless user experience across multiple access networks. Some of the devices are expected to be simple sensor kind of devices, potentially without user interfaces. In addition, as devices are expected to be used and managed (e.g., the device owner may sell the device to another user who can then use the device with a subscription to their own network operator) by end users a method of dynamic subscription generation and management is needed in addition to statically provisioned subscription. Once the subscription is established, subscription management becomes necessary, for example, to modify the subscription when the ownership of the device changes, to update or refresh credentials due to suspected leakage or theft of security keys or as a preventive measure, etc. Another area which needs to be addressed is the proliferation of devices. Devices come in large numbers with varied capabilities and mobility requirements. When the device is manufactured, the deployment location and specific usage may not be known. Sometimes the devices will be added to existing subscriptions, other times they may be part of a new subscription for the user. During their life cycle these devices go through different stages, involving the change in ownership when the device is deployed and possibly afterwards, the activation of the device by the preferred operator, a possible change of operators, etc. These stages need to be managed securely and efficiently.

In the following traffic scenario, a very simple device (e.g., no IMS client) is installed and activated for service. The device could be, for example, a smart electric meter. It records electricity usage, provides up to the minute usage reports that allow the customer to take advantage of time of day rating, and provides a larger, complete report to the electric company once a month The electric company deploys a large number of these smart meters within an apartment building, one for each apartment. The meter technician needs an efficient mechanism to quickly associate each smart meter to the correct account (e.g., apartment number) and activate the smart meter. This mechanism should allow the technician to immediately activate transmission of electricity consumption data to enable real-time tracking and charging for electricity used.

In the following traffic scenario, a video recorder is installed and activated at a street corner. The video recorder includes a camera, some on-board processing capability, as well as the ability to send information to the traffic police. The camera records continuous video, storing the content for some period of time. The device periodically sends a status update to the traffic police indicating that traffic is moving smoothly. When an accident occurs at the intersection, the device begins sending high quality video to the traffic police of the accident and ensuing traffic congestion. The network will need the flexibility to provide efficient service to the device at all times, whether a small or large amount of data is sent in a given transmission. An efficient system could minimize any negative impact to battery life for the device and minimize use of signalling resources. The same device will need to establish a connection when it needs to transmit a large amount of data (e.g., video).

In the future it is expected that devices sold outside operators' channels will likely not be preconfigured with operator-specific subscription credentials. In the following traffic scenario an end user buys a 3GPP enabled smart band or other device, which has not been preconfigured for any operator. Having obtained a subscription (for the device), when the device tries to connect to the 3GPP network there shall be a mechanism to get to the device appropriate subscription credentials over the 3GPP network so that the device is used in its intended way.

Farm machinery is increasingly being automated. Tractors, harvesting machines, and crop loaders autonomously drive through farms under close coordination, alleviating the need for a human driver. Farm machinery can report various sensor data, such as soil condition and crop growth, so that the farmer can remotely monitor the farm condition and control machinery. The data gathered helps with crop predictions and planting plans. Compared to smartphones, farm machinery have very long lifetimes (in the order of 15 years) which makes it essential to have technologies that will remain relevant or easily upgradeable over a very long time frame. Moreover, farm machinery is often leased. Due to these factors, flexible devices that can cope with various regions and migration are desirable. Different renters may prefer different mobile operators for service. It is therefore important to provide technologies that facilitate easy switch between mobile operators.

When connectivity module gets cheaper, most things will include the connectivity module. As a result, the number of connected devices belonging to one user will also increase. The devices one user possesses can be grouped into following two groups.

1. Group of mutually exclusive device: In this group of devices, at most one device can be simultaneously activated. Typical example of this group is a devices used for fashion item such as a smart watch or smart bracelet, etc. For example, a user may possess several smart watches with different shapes and colour. Because the user does not wear multiple watches at the same time, only one of the watches needs connection to network.
2. Group of independent device: In this group of devices, each device can be connected to network independent of connection status of other devices. For example, a smart glass can be connected to network while a smart watch is connected to network.

In this traffic scenario, the connectivity management (e.g., addition, removal, activation, deactivation, etc.) of multiple devices should be simple and straight-forward. From user experience point of view, it is not desirable that a user is required to make a separate subscription for each device whenever a device is bought, discarded or modified.

Already in the market, many businesses are based on the concept of sharing economy emerged (e.g., car rental services, where the same care is shared by many people). As devices can be shared among people, a new model of providing connectivity to devices is needed together with mechanism from prevention of fraudulent access by unauthorized users.

Control of connectivity based on authorization by the content or service provider can serve various business models. A content or service provider may be willing to pay for the cost of any type of connectivity used for traffic delivery without requiring a user to use specific Apps. In one example, utility company may pay for the traffic generated for the smart meters installed in each house. In another example, traffic generated by a biometric sensor used to track physical activities is paid by a fitness program provider. In addition, the content or service provider may require the ability to provide to the MNO specific connectivity requirements (e.g., QoS). This traffic scenario can be further enhanced with out-of-the-box connectivity provision. For the device manufactures or the service providers with global presence, it is hard to know when and where their devices and services will eventually be deployed and activated. Consequently, the manufacturer and the providers will not be able to pre-provision the devices with PLMN specific and IoT service specific information. In this case, rather than requiring a user to manually provision the device, it would be better for the network to provide connectivity to the UE as long as the device manufacture or the service provider is willing to pay for the device. In fact, from a service user point of view, for a device bought at the local store, the device should be usable right away (i.e. out of the box) without any further user involvement for the connection management. When service provider pays for the connectivity service for the devices, it is necessary to prevent fraudulent use of the provided connectivity. For that, the network needs to filter out traffic other than for the intended service.

In order for the Internet-of-Things not to become a collection of Intranets-of-Things, reachability and addressability should be ensured across different domains. There ideally should be an easy / common way to identify a particular device and then use that identifier to reach and address the device, independently from how the device is connected. In addition, devices from different manufacturers should be able to communication with each other, without any dependency on a specific service provider, a specific IoT platform, a specific operating system or a specific application. I.e, a device should be able to communicate with other device without any adaptation in the middle. In addition, device is typically limited in capability so that it may not support IP protocol or may not be equipped with an IMS client, because more processing power is needed to handle IP/IMS stack and more protocol overhead is expected over radio interface. Thus, efficient communication between the devices should be supported. When the number of devices increases and when each device can be used by different users, it should be easy and intuitive for a user to address each device. For example, it may lead to bad user experience if a user has to remember complex identifier whenever the user purchases new device or if he has to know the identifier of a public device before he can use it. While efficient communication between devices needs to be supported, delivery of messages from unauthorized sources should be prevented.

[PR.5.1.3.1-001] [PR.5.1.3.1-002] [PR.5.1.3.1-003]

[PR.5.1.3.2-001]

[PR.5.1.3.3-001]

[PR.5.1.3.4-001]

[PR.5.1.3.5-001] [PR.5.1.3.5-002] [PR.5.1.3.5-003] [PR.5.1.3.5-004] [PR.5.1.3.5-005]

[PR.5.1.3.6-001] [PR.5.1.3.6-002]