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.
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.
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.
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.
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.
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.
In order to use MTC triggering, the system shall support association between an MTC Device identity and one or more Service Enablement Framework individually.
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.
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).
The MTC Feature Time Controlled is intended for use with MTC Applications that can tolerate to send or receive data only during defined time intervals and avoid unnecessary signalling outside these defined time intervals. The network operator may allow such MTC Applications to send/receive data and signalling outside of these defined time intervals but charge differently for such traffic.
For the Time Controlled MTC Feature:
The network operator shall be able to reject access requests per MTC Device (e.g. attach to the network or set up a data connection) outside a defined access grant time interval.
The network operator shall be able to allow access (e.g. attach to the network or set up a data connection) outside a defined access grant time interval and charge this differently.
The network shall reject access requests per MTC Device (e.g. attach to the network or set up a data connection) during a defined forbidden time interval (e.g. to allow maintenance of a MTC Server).
The local network shall be able to alter the access grant time interval based on local criteria (e.g. daily traffic load, time zones). The forbidden time interval shall not be altered.
The network shall be able to restrict the duration of access by terminating access (e.g. detach or disconnect a data connection) after a defined access duration.
The MTC Device may disconnect immediately when it finishes its communications with the MTC Server before wait until the end of the access duration.
The network shall communicate the (altered) access grant time interval and the access duration to the MTC Device.
The network may communicate the (altered) access grant time interval and the access duration to the MTC Server/MTC User.
The MTC Feature Infrequent Mobile Terminated is intended for use with MTC Devices that mainly utilize mobile originated communications.
For the Infrequent Mobile Terminated MTC Feature:
The network operator shall be able to reduce the frequency of mobility management procedures per MTC Device.
The network shall be able to maintain information on when the MTC Device is not reachable for mobile terminated communications. The network shall not trigger the MTC Device when it is known to be unreachable, and instead may inform the MTC Server that the MTC Device is not reachable.
The MTC Feature MTC Monitoring is intended for monitoring MTC Device related events.
For the MTC Monitoring MTC Feature:
The system shall provide mechanisms to detect the following events:
behaviour which is not aligned with activated MTC Feature(s)
change of the association between the ME and the USIM
loss of connectivity. The maximum time between the actual loss of connectivity occurred and the loss of connectivity detected shall be configurable per subscription.
communication failure events of the UE visible to the network (e.g. for troubleshooting)
- change of the location (geographical position and/or point of attachment in the network) of the MTC Device.
The MTC Subscriber shall be able to define which of the above events will be detected.
Upon the above event detection, the network shall be able to:
provide a warning notification to the MTC Server;
limit the services provided to the MTC Device (e.g. reduce allocated resource).
The MTC User shall be able to define what occurs when an event is detected.
The MTC Device shall be able to transfer other event notification to the MTC Server where the event detection is out of 3GPP scope, for example, the loss of signal reception, notification when the MTC Device power level is lower than a threshold.
The MTC Feature Secure Connection is intended for use with MTC Devices that require a secure connection between the MTC Device and MTC Server/MTC Application Server.
For the Secure Connection MTC Feature:
The network operator shall be able to efficiently provide network security for connection between MTC Device and a MTC Server or between MTC Device and a MTC Application Server in case there is a direct connection with the MTC Application Server. This applies even when some of the devices are roaming i.e. connected via a VPLMN.
MTC Feature Group Based Addressing is intended for use with a MTC Group for which the network operator wants to optimize the message volume when many MTC Devices need to receive the same message.
For the Group Based Addressing MTC Feature:
The network shall provide a mechanism to send a broadcast message within a particular geographic area, e.g. to wake up the MTC Devices that are members of that MTC Group; only MTC Devices of the target group configured to receive the broadcast message will recognize it.