1. 1 | 3GPP2 TSG-X Discussion | December 2010 3GPP2 X50-20101206-015R1 TITLE: TITLE: M2M Deployment Scenarios for 3GPP2SOURCE Mike Dolan, Alcatel-Lucent, Mike Dolan, Alcatel-Lucent, Mike.Dolan@alcatel-lucent.com Orlett Pearson, Alcatel-Lucent, Orlett.Pearson@alcatel-lucent.com Betsy Covell, Alcatel-Lucent, Betsy.Covell@alcatel-lucent.comMike.Dolan@alcatel-lucent.comOrlett.Pearson@alcatel-lucent.comBetsy.Covell@alcatel-lucent.com (Omar Elloumi, Harish Viswanathan)ABSTRACT This contribution provides discussion points for IP addressing, deployment possibilities for IPv4/IPv6, 1x SMS and 1x Packet. RECOMMENDATION : Discuss and adopt in principle. © 2010 Alcatel-Lucent 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 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- 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. 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 material contained herein and to any intellectual property of Alcatel-Lucent other than provided in the copyright statement above.

2. M2M Deployment Scenarios for 3GPP2 networks - Prioritization of 3GPP2 work December 2010

3. 3 | 3GPP2 TSG-X Discussion | December 2010 Outline Reference from 23.288 Possible Deployment Scenarios Pros and Cons of each Scenario Suggested way forward

4. 4 | 3GPP2 TSG-X Discussion | December 2010 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 Source: 3GPP TR 23.888 V1.0.0 (2010-07)

5. 5 | 3GPP2 TSG-X Discussion | December 2010 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.

6. 6 | 3GPP2 TSG-X Discussion | December 2010 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 3. HRPD IPv6 based deployments 4. 1x SMS based deployments 5. 1x packet based deployments

7. 7 | 3GPP2 TSG-X Discussion | December 2010 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

8. 8 | 3GPP2 TSG-X Discussion | December 2010 2. HRPD IPv4 based deployments M2M Device HA PDSN Pubic Internet Private IPv4 Address Space M2M Server A M2M Server B M2M Server C M2M Proxy Private IPv4 Address Space M2M Server X M2M Server P M2M Server 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.

9. 9 | 3GPP2 TSG-X Discussion | December 2010 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

10. 10 | 3GPP2 TSG-X Discussion | December 2010 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.

11. 11 | 3GPP2 TSG-X Discussion | December 2010 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.

12. 12 | 3GPP2 TSG-X Discussion | December 2010 3. HRPD IPv6 based deployments  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.

13. 13 | 3GPP2 TSG-X Discussion | December 2010 3. HRPD IPv6 based deployments M2M Device HA PDSN Pubic Internet Private Address Space M2M Server A M2M Server B M2M Server C v4-v6 NAT M2M Server X M2M Server P M2M Server Q 3a 3b 3c

14. 14 | 3GPP2 TSG-X Discussion | December 2010 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.

15. 15 | 3GPP2 TSG-X Discussion | December 2010 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.

16. 16 | 3GPP2 TSG-X Discussion | December 2010 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.