For the purposes of the present document, the following terms and definitions apply. H2H M2M User M2M Terminal

For the purposes of the present document, the following abbreviations apply: M2M

It appears that there is market potential for M2M beyond the current "premium M2M market segment" i.e. the market segments that are currently using M2M. In particular it is possible to identify potential applications for mass M2M service, e.g. consumer products manufacturers could keep in touch with their products after they are shipped - car manufacturers could serve as an example for that. Another example is in the home environment where remote maintenance of heating and air condition, alarm systems and other applications can also be identified. In addition to identified applications, it can be expected that if there was an easy to use M2M service offering other applications for M2M would be forthcoming. At present structures that have been optimally designed for H2H may be suboptimal for M2M and therefore structures designed for M2M need to be investigated.

Machine to Machine (M2M) Communication is seen as a form of data communication between entities that do not necessarily need human interaction. It is different to current communication models as it involves:

• new or different market scenarios
• lower costs and effort
• a potentially very large number of communicating terminals with
• to a large extent little traffic per terminal

This new type of M2M communication may in future become more relevant as

• M2M in GSM/UMTS is a future growth sector in particular in mature markets, and the ubiquitous coverage of mobile networks is one main enabler
• Potential enhancements of 3GPP standards may be a stimulator; as such business could be addressed more cost efficiently.

The study shall investigate on the improvements how standards can be enhanced to provide network operators with lower operational costs when offering M2M services. It shall lower the M2M users' effort associated with handling large M2M groups. The study shall look at the trade-off between the effort and the benefits associated with the improvements

M2M bears enormous application diversity, hence it is difficult to devise comprehensive use cases. Areas in which M2M right now is used:

Security	Alarm systems Backup for landline Access control Car/driver security
Tracking & Tracing	Fleet Management Order Management Pay as you drive Asset Tracking Navigation Traffic information Road tolling Traffic optimisation/steering
Payment	Point of sales Vending machines Loyalty concepts Gaming machines
Health	Monitoring vital signs Supporting the aged or handicapped Web Access Telemedicine points Remote diagnostics
Remote Maintenance/Control	PLCs Sensors Lighting Pumps Valves Elevator control Vending machine control Vehicle diagnostics
Metering	Power Gas Water Heating Grid control Industrial metering

  In the following a few already existing use cases covering the most important user requirements and the areas of improvement are outlined.

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.

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.

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.