There are several different communication models under which M2M will take place, each with different relevance and importance for the M2M market.
In the first step M2M can be restricted to a "many M2M terminals to one server" communication model (N to 1) which is the mode of operation in nearly all M2M applications running already today. A number of terminals communicating with the same server are considered a group, and a M2M user can run many of these groups. The N to 1 communication model can be further restricted in that way that the group of M2M terminals belonging to one M2M user can communicate with one destination server only whose address is supplied by the network. This would greatly reduce the effects of misuse of stolen M2M terminals which are usually unattended to a very large extent. In other words, the network decides on the destination address the M2M data is being sent to.
For the first step, it is also considered sufficient that M2M communication is initiated by the M2M terminals only as most of the M2M scenarios run well with a pull type of communication.
When the market evolves and the need for other types of communications such as M2M terminal to M2M terminal emerges it shall be possible to introduce this later on.
It is understood that current M2M scenarios are mostly based on SMS. This, however, was driven by historical constraints, at that time when the first M2M applications were set up, nothing else, besides CS data was available.
When considering the communication requirements for various types and classes of machine it becomes obvious that no single Teleservice or Bearer Service will satisfy all their individual needs up to now. Also there are multi-function machines that may need to communicate with different servers/terminals, at different data rates, for different tasks. For example, a network of 'printer/fax/scanner' machines might communicate externally via a master machine/server with a gateway terminal (containing a SIM/USIM/ISIM). Existing master 2G/3G capable terminals might request a CS bearer to send a fax, SMS to report a fault, or GPRS/HSUPA to transfer a large graphics file to a manufacturer.
GPRS and UMTS PS should be the preferred way for transferring data as this would simplify terminals and networks (No CS impacts), and thus reduce costs.
This also facilitates simple writing of M2M applications by the M2M users without having to deal with specialised and proprietary SMS interworking, by simply providing e.g. an IP protocol stack. This will open up new market segments as M2M application can use an IP packet service.
It is assumed that two kinds of machines are deployed within this scenario:
Wireless modulesM2M terminals, connected via a RAN, included in the "machines in the field (e.g. vending machines)" and
Central servers, located behind the GGSN. These servers may be located as follows:
within the operator (MNO) domain, giving the possibility for tight coupling to servers within MNO domain.
connected externally similar to a PDN connection (Packed Data Network as in GPRS standardisation), i.e. with a dedicated connection from GGSN (APN) to the server(s) of the machine operator and thus also routing and access control possibility at GGSN.
- within general Internet, accessible via PDN (and ISP), i.e. without dedicated connection to the server(s) of the machine operator, but transport over the public Internet.
Scenario 1: Many wireless modules communicating with one central server
This scenario applies when one machine operator has many machines at various locations and wants to communicate with these machines in an intermittent way. One Wireless module communicates with one server only. The machines shall be distinguishable from each other, i.e. outgoing messages (as seen by the central server) are not "broadcast", and incoming messages are bound to the particular machine the message was sent from.
Scenario 2: Many wireless modules communicating with many servers
A machine operator may deploy many servers for local diversity or load distribution. This is an extension of scenario 1. The MNO may provide access control to separate the different machine operators' realms.
Scenario 3: Many wireless modules communicating with each other
This scenario is not seen within the scope of 3GPP's work on M2M as the relevant applications only seem to involve module-to-server communication. (FFS)
Further study should determine the relevant communication scenarios. It may be beneficial to limit the scope of M2M communication for the sake of reduced complexity and increased security, but, on the other hand, care should be taken not to exclude relevant scenarios.
Subscription and subscriber management seem to contribute to the inability to provide attractive offerings. For example, requiring the operator to deal with each and every M2M terminal individually - instead of handling the M2M user owning "N" terminals in one step - is considered at least suboptimal. Also, M2M terminals may remain stationary in many applications, thereby reducing the network load and possibly allowing optimisations.
In order to save network signalling overhead for mobiles that are non-stationary and need not to be reachable i.e. use mobile originated traffic only the suppression of location update traffic should be studied.
Furthermore mobility could be de-activated for certain kinds of terminals e.g. mobiles that are stationary.
The following user requirements can be deduced from the use cases:
Tamper Save/Theft proof terminal including a UICC
Possibility to change subscription out in the field e.g. after contract expiry without human intervention
Possibility to allocate the terminals at initial power up to a network operator without human intervention
One of the perceived obstacles to M2M market growth is the difficulty for the M2M operator to change the subscription. Currently, such a change would involve physical maintenance work on all machines in the field, which is seen prohibitive. Therefore, alternatives to realise a dynamic provisioning of USIM/ISIM parameters to a large number of M2M terminals within a short timeframe should be investigated (e.g. UICC OTA update of the MNO data, and transfer of the access right between MNOs). Depending on the business cases deployed in future, the machine operator may have the advantage that he can more easily change the MNO. This may be seen as a disadvantage for the MNO, but on the other hand the MNO may also have the benefit that new customers may switch more easily to his service. In general it is expected that the market for M2M communication may grow faster if the machine operators have more chances to select their favourite operator knowing that they are not tied to this operator forever.
Many of the ideas being developed for Personal Network Management (PNM) (TS 22.259
) and Network Composition (NC) might also be applied to machine network management (MNM) communications. Like humans, machines may also need to communicate in different ways at different times, between themselves and with remote peers. Standardising MNM procedures, and aligning them with PNM, NC and similar specifications, could lead to improve efficiency through optimised communication and better bearer/bandwidth usage, especially for networked machines belonging to a single or partner entity. In addition to industrial and office machines, example networks would include CCTV surveillance cameras, vending machines, gaming and internet access terminals in a shopping mall, or on a train, or perhaps a home network comprising phones, PCs, PDAs, TV set-top box, alarms, domestic appliances, etc.
Depending on the communication task, machines might communicate, via non 3GPP access technology, to the master machine (containing a SIM/USIM/ISIM) or obtain authorisation from the master machine to communicate directly e.g. using the 3G or fixed NGN network, with an external entity.
Reduced number of subscriptions
Reduced number of network authentication
Subscription independent machine replacement/upgrades
Easier subscription upgrade and portability
Communication task prioritisation
Data aggregation and multiplexing e.g. over HSDPA/HSUPA
Better QoS e.g. optimum location of master machine/terminal
Continuation of high-speed data link to sub-optimal locations using M2M single or multi-hop Bluetooth/WiFi /cable
Efficient network management
Ad-hoc and potentially self repairing network
Consolidated charging and billing
Non-3GPP entities having access to the 3GPP network
A potentially reduced security of the 3GPP network if the security level of the slave-master machine communication is lower than the usual 3GPP security.
The communication behaviour of large numbers of terminals also aggravates the efforts for charging in the network. When the traffic volume may vary by several orders of magnitude, e.g. ranging from few bytes once a year to a few kilobytes every minute the traditional charging record generation effectively stops the widespread use of M2M. Especially charging, as it is designed today, in creating detailed charging records, causes unnecessary overhead in creating at least 10 - 100 times longer CDRs than the payload for every few bytes transaction.
Charging record generation as it is done today was designed for the highly regulated H2H market. It should not be applied for M2M. It is considered sufficient to apply per group counters counting the traffic to and from the servers at the network boundary. Detailed tracking of traffic behaviour per terminal should be handled at the M2M user's server(s) if required.
What is additionally required is to take care of M2M terminals usually tied to one location. To enable the operator to provide suitable service offerings for these types of terminals some per group counter should be established counting mobility related network load, i.e. counting the location update traffic. It has to be noted that location update traffic caused by restructuring of the network needs to be taken into account by the network operator.
In order to differentiate machine to machine communications for optimised mobility management, call routing, security and charging purposes, consideration should be given to the use of machine type subscription identifiers. It is envisaged that several types of M2M communication subscriptions/tariffs could be offered by network operators, based perhaps on different classes of machine e.g. always on high security alarm systems and surveillance camera networks, single point of sale card readers, fixed location machines. The subscription information, including the machine class/ terminal type identifier would be distributed to the responsible network elements handling the M2M communication.
Many alarm systems and other fixed geographic location terminals generate very low volumes of chargeable traffic. To be able to offer attractive tariffs in these business sectors, there is a need to reduce or eliminate completely some of these signalling overheads. Even in the case of fixed location machines that generate large volumes of chargeable traffic, it is still desirable to minimise signalling due, in particular, to unnecessary periodic location updates. For static terminals, depending on terminal type, it should be possible to selectively extend the periodic time to 255 (deci-hours), or to instruct individual terminals not to make periodic location updates. Alternatively, to make use of off peak traffic periods, low activity terminals might be instructed to perform a location update at some future date and time e.g. 1st February at 02:45:30, rather than at set periodic intervals.
Terminals intended for M2M communications should not need to support unnecessary functionality and should be provisioned accordingly. This might include a dedicated M2M APN but not any unnecessary services like voice mail or customer care messages that cannot be used by the machine or a maintenance engineer.
Ideally, for any given terminal type, it should be possible to optimise mobility management, re-authentication, subscription maintenance and other operational costs. There are several ways that this might be done but in most cases there is a need to differentiate between mobile UEs, fixed location and low activity terminals. By identifying the subscription and terminal type, e.g. machine to machine subscription, low activity, fixed geographic location terminal, in the subscriber information held in the HLR/HSS, and distributed to the MSC-VLR and SGSN, mobility management and other costs may be reduced.
In addition to reducing the signalling overhead and operational costs, minimising MM and GMM signalling also helps to reduce cell congestion.
Further consideration should also be given to the purging of low usage terminals subscription information from the VLR/SGSN, especially for MO only terminals e.g. domestic alarms. In this case the HLR/HSS would be expected to retain a record of the last reported location and timestamp, received from the VLR/SGSN, when the temporary subscriber information was purged.
The expected large number of terminals and the automated nature of traffic seem to be more prone to Denial of Service Attacks (DoS). These attacks can be either caused deliberately or by bad M2M application design.
A DoS attack is always possible in mobile networks, irrespective of the kind of service offered. The easiest way would be jamming of the radio interface, but more sophisticated attacks are also possible, e.g. with an overload of bogus authentication or mobility management messages. Thus the aim of M2M security is not to open additional channels for DoS attacks. The same applies for degradation of service which may be seen as a weaker form of DoS.
As often, attacks depend a lot on particular properties of a system, a detailed discussion of DoS attacks must be done after selection of a particular architecture for M2M.
In order for the overall risk to remain manageable, there needs to be a finely tuned balance between security provisions on the user side and those in the network: it may be possible to adapt security on the user side for M2M communication to a certain extent, but this would then have to be compensated for by access restrictions on the M2M user enforced in the network. Some of these access restrictions could be realised by dynamically configurable packet filters.
It may be considered whether additional security measure at the application layer may allow to somewhat adapt security at the link or network layer. However, it is questionable whether a requirement on the M2M operator to introduce and manage additional security at the application layer would lead to the cost saving required for a M2M mass market. A re-use and enhancement, where necessary, of the widespread GERAN/UTRAN technology also for security for M2M communication seems the more promising approach.
In contrast to the traditional ME, which is carefully held and protected by a person, the M2M terminals will be placed in more or less accessible locations, and may be tampered with by unauthorised persons. Furthermore, theft or fraudulent modification of an M2M terminal may not be detected and reported as quickly as this is the case for personally owned and held ME. Fraud targets could both be the M2M user (e.g.: fraudster suppresses payment messages) or the PLMN operator (fraudster uses M2M device or its UICC for theft of service). Therefore, requirements for device-based security measures need to be studied. The related work TR 33.905
"Recommendations for Trusted Open Platforms" may be relevant for M2M.
One major challenge is to secure the UICC in such a way that it is not trivial to tamper with or steal. On the other hand making the UICC completely theft proof challenges the flexibility for the M2M administrator/end-user to change subscription if that is desired. To get this contradictory issue solved might be a key factor to open up e.g. Telematics business for mobile industry players.
Furthermore, the M2M ME and the system attached to it (or surrounding it, e.g. a vending machine) often represent a single functional entity. Therefore, the interface between the M2M ME and its surroundings are security-relevant. It must be decided whether this interface is in scope or out of scope of 3GPP standardisation. Regardless of the decision, interface security must be addressed to fulfill the M2M user's security requirements
There are several possibilities which kind of connectivity is needed for M2M terminals - originating, terminating, CS, PS (GPRS), IMS etc. This requires different identities.
IMSI: Required to access a 3GPP network, provides the possibility to perform a CS or GPRS attach and such to send short messages.
IMSI + MSISDN: provides the possibility to originate and terminate CS calls as well as to receive short messages.
IMSI + IP address: provides IP connectivity after PDP Context Activation
IMSI + IMPI + IMPU: provides possibility to originate and terminate IP multimedia sessions via the IMS.
IMSI based addressing provides only limited connectivity in the current systems but could serve as first step to remotely activate a UE, i.e. to initiate a PDP context activation on network request.
According to TS 23.003
the maximum length of a IMSI is 15 digits, consisting of the Mobile Country Code (MCC) with 2 digits, the Mobile Network Code (MNC) with 2 to 3 digits and the Mobile Subscriber Identification Number (MSIN) with up to 10 or 9 digits respectively. In theory this would provide the possibility for addressing up to 10 billion different terminals within one mobile network.
However in practice this may collide with existing IMSIs of the operators. So it seems likely to be necessary for operators to apply a separate MNC for M2M communication which enables the use of nearly all possible numbers.
According to TS 23.003
and the ITU-T Recommendation E.164  the maximum length of a MSISDN is 15 digits, consisting of the Country Code (CC), National Destination Code (NDC) and Subscriber Number (SN). Although the length of the CC and NDC may differ in various countries the majority of the SNs is around 10 digits long. Again, this would provide the possibility for addressing up to 10 billion different terminals.
Due to existing numbering plans the real number is much more limited. A possible way to use nearly the full possible range is to apply a separate NDC for M2M communication.
On protocol level within mobile networks even longer MSISDNs - up to 20 digits in national or international format - are supported.
After establishment of IP connectivity the use of private or public IPv4 or IPv6 addresses is possible, the registration to the IMS enables addressing via SIP URIs or tel URIs. This provides a nearly unlimited number of addresses.
The limiting factor in addressing is the IMSI: Dependent on the length of the MNC only 9 or 10 digits are available for use within one network identified by one MNC. Furthermore it is the pre-requisite to access the 3GPP system via the CS or PS system. The use of additional MNCs may be restricted by regulatory authorities.
For this reason alternative addressing solutions based on IP addresses should be studied.
Depending on the assumptions made in the section on charging (ie. to base charging on per group counters ) the need to individually identify a M2M terminal seems not to be given from the network's point of view. It is assumed that the M2M user, in any case, will have some identification of M2M terminals on application layer. Hence, it should be studied whether authenticating the terminal by just identifying the group it belongs to brings any benefit in facilitating M2M. But it should be studied whether problems may arise when a terminal does not have a unique identity in GPRS: on the one hand, the current mobility management procedures may need to be updated (which may be a serious impact, ffs), on the other hand, it may be desirable to be able to identify a rogue or misbehaving terminal and take it out of service, rather than disabling the entire group. But then it may be possible to use a unique identity of a terminal in GPRS and use a group identity only for charging purposes, i.e. CDRs would be generated only for the group.
For example, many machines could communicate via a master machine/terminal containing a SIM/USIM. As with Personal Network Management (PNM), Machine Network Management (MNM) this would allow a single subscription (MSISDN/Public Address) to serve many devices with Private Addresses. The benefits of such a system are described in section 5.1.2.
Backwards compatible extension of the IMSI address range might also be considered. Special MNC/MCC/MSIN, which are transparent to legacy systems, could trigger a further validation check of the M2M address part of the IMSI.