7.1 Common service requirements

22.3683GPPRelease 17Service requirements for Machine-Type Communications (MTC)Stage 1TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1.1 General

The following are MTC common service requirements:

– The network shall enable the network operator to identify per subscription which individual MTC Features are subscribed to by a particular MTC Subscriber.

– The network shall provide a mechanism for the MTC Subscriber to activate or deactivate MTC Features.

– The network shall enable the network operator to identify which individual MTC Features are activated for a particular MTC Subscriber.

Note 1: The activation/deactivation functionality can be provided via a web interface that is outside the scope of 3GPP specifications.

– The network shall provide a mechanism for the network operator to control the addition or removal of individual MTC Features to a subscription (e.g. based on matching or mismatching of MTC Features).

– The network shall provide a mechanism for the network operator to restrict activation of MTC Features
(e.g. based on matching or mismatching of MTC Features).

– The network may provide a mechanism for the network operator to allow MTC Devices to override restrictions imposed by a particular MTC Feature.

– The network operator shall be able to restrict the use of a USIM to specific MEs/MTC Devices.

– The network shall provide a mechanism to reduce peaks in the data and signalling traffic resulting from very large numbers of MTC Devices (almost) simultaneously attempting data and/or signalling interactions.

– The network shall provide a mechanism to restrict downlink data and signalling when the network is overloaded.

– The network shall provide a mechanism to restrict access towards a specific APN when the network is overloaded.

– A MTC Device may support the Extended Access Barring (EAB) mechanism defined in TS 22.011 [2].

– A MTC Device supporting the EAB mechanism shall be able to be configured for EAB by the HPLMN.

– The HPLMN shall be able to configure EAB on a MTC Device that supports it.

– Once configured, and upon reception of broadcasted EAB information, the MTC Device shall adhere to the defined EAB mechanisms.

Note 2: The decision of whether a MTC Device is configured for EAB is out of 3GPP scope. In general, MTC Devices considered more tolerant to access restrictions are well suited to be configured for EAB.

– The system shall provide mechanisms to efficiently maintain connectivity for a large number of MTC Devices.

– The network shall provide mechanisms to handle MTC Devices and applications on MTC Devices registering on the IP multimedia core network subsystem and accessing its capabilities including interaction with IMS application servers/enablers.

– Configuration parameters which are provided in the USIM shall take precedence over parameters provided in the MTC Device if both exist.

– The network shall allow a resource efficient registration of MTC Devices and applications on MTC Devices on the IP multimedia core network subsystem (e.g. no need of a permanently assigned ID per MTC Device)

– The system shall provide mechanisms to lower power consumption of MTC Devices.

– The system shall provide a resource efficient way to support MTC Devices that send or receive data infrequently, i.e. with long periods between data transmissions.

– MTC Devices may or may not be kept attached to the network when not communicating, depending on operator policies and MTC Application requirements.

– MTC Devices may keep their data connection or not keep their data connection when not communicating, depending on operator policies and MTC Application requirements.

7.1.2 MTC Device triggering

The requirements related to MTC Device triggering include the following:

– The network shall be able to trigger MTC Devices to initiate communication with the MTC Server based on a trigger indication from the MTC Server.

– The system shall provide a mechanism such that only trigger indications received from authorized MTC Servers will lead to triggering of MTC Devices.

– Upon receiving a trigger indication from a source that is not an authorized MTC Server, the network shall be able to provide the details of the source (e.g. address) to the MTC User.

– The system shall provide a mechanism to the MTC User to provide a set of authorized MTC Server(s).

– Upon receiving a trigger indication, if the network is not able to trigger the MTC Device, the 3GPP system may send an indication to the MTC Server that triggering the MTC Device has been suppressed.

Note: Suppression of triggering could be due to system conditions such as network congestion.

– A MTC Device shall be able to receive trigger indications from the network and shall establish communication with the MTC Server when receiving the trigger indication. Possible options may include:

– Receiving trigger indication when the MTC Device is not attached to the network.

– Receiving trigger indication when the MTC Device is attached to the network, but has no data connection established.

– Receiving trigger indication when the MTC Device is attached to the network and has a data connection established.

7.1.3 Addressing

The system shall provide mechanisms, according to operator policy, where an MTC Server can send a mobile terminated message to the MTC Device. Scenarios include:

– The MTC Server is located in the public IPv6 address space. The MTC Device is assigned a public IPv6 address by the MNO.

Figure 7-1: MTC server and the MTC Device in the public IPv6 address space

– The MTC Server is located in a public IPv4 address space; the MTC Device is assigned a private IPv4 address by the MNO.

Alternatively, the MTC Server is located in a private IPv4 address space and is assigned a private IPv4 address by the MNO; the MTC Device is assigned a private IPv4 address by the MNO corresponding to the same IPv4 address space as the MTC Server.

Figure 7-2: MTC Server in a public or private IPv4 address space,
MTC Device in a private IPv4 address space

7.1.4 Identifiers

The requirements for MTC related to identifiers include the following:

– The system shall be able to uniquely identify the ME;

– The system shall be able to uniquely identify the MTC Subscriber.

Note 1: The two requirements above also apply to human-to-human communications. However, for Machine-Type Communications identifiers will have to be able to cater for a number of identifiers at least two orders of magnitude higher than for human-to-human communications.

In order to use MTC triggering, the system shall support association between an MTC Device identity and one or more Service Enablement Framework individually.

Note 2: The Service Enablement Framework server in the network needs to associate its peer Service Enablement Framework client on the MTC Device with the external identifier of the MTC Device.
Preconfiguration of the association is sufficient when the Service Enablement Framework knows the MTC Device identities in advance to the starting of the service, but this does not match all the relevant scenarios of service deployment.

– The system shall provide mechanisms for the network operator to efficiently manage numbers and identifiers related to MTC Subscribers.

7.1.5 Charging requirements

The core network shall be able to:

– count MTC Feature activation / de-activation.

– collect charging data with a granularity (e.g. in time or location) that can identify the use of network resources when used outside the limits of subscription or MTC Feature, e.g. time window, location, or can identify when the MTC Device is overriding other restrictions (e.g. low priority).

– count particular Monitoring events.

Note: The above charging requirements apply to off line charging only.

7.1.6 Security requirements

The security requirements for MTC include the following:

– MTC optimizations shall not degrade security compared to non-MTC communications

7.1.7 Remote MTC device management

The operator shall be able to manage MTC Devices using existing mechanisms (e.g. OMA DM)