1 | 3gpp2 tsg-x discussion | december 2010 3gpp2 x50-20101206-015r1 title: title: m2m deployment...

1 | 3GPP2 TSG-X Discussion | December 2010

3GPP2 X50-20101206-015R13GPP2 X50-20101206-015R1

TITLE: TITLE: M2M Deployment Scenarios for 3GPP2SOURCESOURCE

Mike Dolan, Alcatel-Lucent, Mike Dolan, Alcatel-Lucent, [email protected]@alcatel-lucent.com Orlett Pearson, Alcatel-Lucent, [email protected] Betsy Covell, Alcatel-Lucent, [email protected]

(Omar Elloumi, Harish Viswanathan)ABSTRACTABSTRACT

This contribution provides discussion points for IP addressing, deployment This contribution provides discussion points for IP addressing, deployment possibilities for IPv4/IPv6, 1x SMS and 1x Packet.possibilities for IPv4/IPv6, 1x SMS and 1x Packet.

RECOMMENDATION : RECOMMENDATION : Discuss and adopt in principle.Discuss and adopt in principle.

© 2010 Alcatel-Lucent © 2010 Alcatel-Lucent

Alcatel-Lucent grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained Alcatel-Lucent grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Alcatel-discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Alcatel-Lucent is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for Lucent is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner's standard which incorporates this contribution. purpose of practicing an Organizational Partner's standard which incorporates this contribution.

This document has been prepared by Alcatel-Lucent to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for This document has been prepared by Alcatel-Lucent to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Alcatel-Lucent. Alcatel-Lucent specifically reserves the right to amend or modify the discussion and is not to be construed as a binding proposal on Alcatel-Lucent. Alcatel-Lucent specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Alcatel-Lucent other than provided in the copyright statement above.material contained herein and to any intellectual property of Alcatel-Lucent other than provided in the copyright statement above.

M2M Deployment Scenariosfor 3GPP2 networks - Prioritization of 3GPP2 work

December 2010


Outline

•Reference from 23.288

•Possible Deployment Scenarios

•Pros and Cons of each Scenario

•Suggested way forward


Reference from 23.288

Source: 3GPP TR 23.888 V1.0.0 (2010-07)

Figure 6.29.2-1: IP address assignment when the MTC Server is owned by the MNO or by a M2M Application Provider using a specific dedicated APN

. . .

MTC Device 1

GGSN/ PGW A

Tunneling MTC server 1

PDN A

MTC server 2

PDN B

MTC server 3

PDN C

Overlapping private IP address pool e.g. (10.0.0.0) MTC

Device i

GGSN/ PGW B

GGSN/ PGW C

MTC Device j

MTC Device k

Source: 3GPP TR 23.888 V1.0.0

(2010-07)


TR- Discussion Points for IP Addressing

NOTE:

Operators may have a choice of two solutions

IPv6

IPv4

Any choice the operator would make using NAT or application routing is an issue if the application puts in the IP address.

If address is embedded, and the address changed from A to B, then there is a possibility of applications failing.

If NAT or application level routing is used, then if the M2M application embeds IP addresses in the data being sent, there could be potential problems.


M2M Deployment Possibilities

We consider only mobile devices that fully support existing 3GPP2 specifications.

1. eHRPD based deployments supporting both IPv4 and IPv6

2. HRPD IPv4 based deployments


4. 1x SMS based deployments

5. 1x packet based deployments


1. eHRPD based deployments supporting both IPv4 and IPv6

eHRPD attaches to the EPC, and so can participate in all of the M2M configurations supported by the EPC.

Multiple APNs, each with an IPv4 and an IPv6 address

Operator Policy via the PCRF

IP address assignment by the operator, or by the PDN

Requires at least basic EPC deployment

Supports multiple M2M clients on the same device attaching to separate M2M servers with private IP address spaces



M2MDevice HAPDSN

Pubic Internet

Private IPv4

Address Space

M2MServer

A

M2MServer

B

M2MServer

C

M2MProxy

Private IPv4

Address Space

M2MServer

X

M2MServer

P

M2MServer

Q

2a

2b

2c

2a – Public IPv4 address

2b – Private IPv4 address used to access all M2M servers

2c – Private IPv4 address used to access an M2M proxy that forwards M2M communications to M2M servers that could be in other address spaces.


2a. HRPD IPv4 based deployments – Public IPv4

The M2M device has a public IPv4 address and can thus reach all points in the internet.

Flexibility in M2M Server configuration and deployment

Use of large numbers of valuable IPv4 addresses

Some vulnerability to security attacks, depending on the quality of the security at the M2M application level


2b. HRPD IPv4 based deployments – Private IPv4 to All M2M Servers

The M2M device has a private IPv4 address that allows it to directly reach all M2M servers that it needs to communicate with.

The HA may be configured to recognize the device as being M2M and so assign it one of these private IPv4 addresses.

All M2M servers need to be configured into this same address space. If they are from separate M2M providers, this can lead to operational issues.

Use of large numbers of valuable public IPv4 addresses is avoided.

If the private IPv4 address space is managed totally within the operator’s controlled network, security issues are minimized.


2c. HRPD IPv4 based deployments – Private IPv4 access to M2M Proxy

Private IPv4 address used to access an M2M proxy that forwards M2M communications to M2M servers that could be in other address spaces.

M2M proxy provides a NAT-ing function.

The HA may be configured to recognize the device as being M2M and so assign it one of these private IPv4 addresses.

This configuration could be added to 2b to allow access to M2M servers both within and outside of the private IPv4 address space.

Benefit over 2b because all M2M servers do not need to be configured into this same address space.

Use of large numbers of valuable public IPv4 addresses is avoided.

If the private IPv4 address space is managed totally within the operator’s controlled network, security issues are minimized.

If the M2M applications embed IP addresses within their communications, this can cause problems because of NAT-ing.

If those communications are encrypted at the M2M application layer, the M2M proxy must become a forwarding application gateway that has separate encryptions toward the M2M Server, and toward the device.



M2M device obtains an IPv6 address.

M2M Servers can be either in private address spaces, or in the public internet (3a and 3b – next slide).

IPv4/IPv6 address translation may be necessary to an IPv4 M2M server (3c – next slide).

Large IPv6 addresses may require compression over-the-air to avoid heavy impacts on the air interface.

Operator’s infrastructure must be prepared to handle IPv6.



M2MDevice HAPDSN

Pubic Internet

Private Address Space

M2MServer

A

M2MServer

B

M2MServer

C

v4-v6NAT

M2MServer

X

M2MServer

P

M2MServer

Q

3a

3b

3c


4. 1x SMS based deployments

Uses existing SMS techniques to deliver M2M communications over an SMS transport.

Well-known techniques that are easily built into M2M devices.

Impacts the 1x control/traffic channels as the number of M2M devices increases.

As 1x channels become increasingly important for carrying voice while high speed packet data is further deployed, it may be important to operators to keep 1x control channels free.


5. 1x packet based deployments

Uses existing 1x packet data channels.

All 3 configurations for HRPD IPv4 apply equally in this scenario.

Impacts the 1x control/traffic channels as the number of M2M devices increases.

As 1x traffic channels become increasingly important for carrying voice while high speed packet data is further deployed, it may be important to operators to keep 1x traffic channels free.

Locking 1x traffic channel usage in for 10 years of M2M service may not be optimal in an operator’s spectrum plans.


Suggested way forward

3GPP2 needs to focus its efforts on M2M in a way that will provide a step-wise approach.

First, support M2M devices that fully support the existing air interfaces.

Second, consider ways to mitigate congestion and loading problems caused by M2M.

Third, consider additional techniques that provide a significant performance improvement for a minimal network/air interface change.

3GPP2 needs to prioritize the scenarios to be supported as we consider the steps above. Operator preference of deployment scenarios would be helpful.

1 | 3gpp2 tsg-x discussion | december 2010 3gpp2 x50-20101206-015r1 title: title: m2m deployment...

Documents

alcatellucent alcatellucent

alcatel lucent

3gpp2 tsgx discussion

3gpp2 work

3gpp2 x50

existing 3gpp2 specifications

creation of 3gpp2 publications

m2m deployment scenarios