Syllabus Day one : Business and ArchitecturesIntroduction to M2MWhat is M2M?The Business of M2MAccelerating M2M MaturityM2...
7 April 20137 April 2013Day two: DeploymentDay two: Deployment
Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optim...
M2M Optimizations in Public Mobile Networks• Many M2M applications use publictelecommunications networks to transfer data ...
Device-to-server and device-to-device communication scenarios
M2M communication path via M2M server
M2M gateway scenario
M2M via mobile networks creates independence from operators
Different M2M applications have different communication needs
Data connection establishment in a cellular mobile network
Different M2M applications with different communication patterns
Network Optimizationfor machine-type communicationfeatures in 3GPP Release 10 and Release 1
Machine Type Communications• M2M is recognized as a key segment in futurecellular mobile packet data networks• Initial 3GP...
3GPP MTC Architecture
Cost OptimizationsCost drivers for an M2M applicationin a mobile telecommunications network
Traffic OptimizationsQoS traffic classes in UMTS
QoS parameters applicable to the different UMTS traffic classes
Numbering and Identifiers Optimizations• E.164 number format for telephone numbers• Format for the International Mobile Su...
Numbering and Identifiers Optimizations• Format for the International Mobile EquipmentIdentity (IMEI)• Format for the Inte...
Numbering and Identifiers Optimizations• Format of the International Circuit Card Identifier(ICCID)
The Basics of Triggering (1/3)When the M2M server decides to trigger an M2Mdevice, it generally includes the followinginfo...
The Basics of Triggering (2/3)• (optionally) the IP address (or FQDN) and/or portnumbers of the application server that th...
Triggering Optimizations (3/3)Before the M2M server can send the trigger message, it needsto determine where to send the t...
Triggering Optimizations:Overview architecture with different triggering solutions.
Triggering Optimizations:Triggering Mechanisms• triggering using mobile-terminated SMS;
Triggering Optimizations:Triggering Mechanisms• triggering using IMS messages;
Triggering Optimizations:Triggering Mechanisms• triggering using cell broadcast;
Triggering Optimizations:Triggering Mechanisms• triggering via HSS and non-access stratum (NAS) signaling;
Triggering Optimizations:Triggering Mechanisms• triggering via network-requested PDP contextestablishment
Closing• For M2M application owners, mobile networksare often more suitable as they offer betterpossibilities for controll...
Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optim...
The Role of IP in M2M• Very few computer network protocols lasted as long as the IPv4protocol. Even if, at the outset, IP ...
Internet Protocol (IP) version 6
IP Addresses Optimizations• M2M communication scenario using IPv6 addressing• M2M communication scenario using IPv4 addres...
IP Addresses Optimizations• M2M communication scenario using privateIPv4 addressing only
Network Applications• Network applications cannot rely on thedevice being constantly available and able tosend or receive ...
Constrained but still Internet• Today - a complete IP based Web stack can be run on smalldevices with microcontrollers.(Co...
IETF 6LoWPAN• The 6LoWPAN WG group has defined encapsulationand header compression mechanisms that allow IPv6packets to be...
6LoWPAN: Why IPv6?• Long-lived technology (20 years+)• Ability to connect heterogeneous networks• Existing worldwide free-...
IPv6 Problems• Bandwidth and Energy efficiencyStandard protocol: IEEE 802.15.4 L1/L2 (low bandwidth:250 kbps, low power: 1...
IPv6 Problems• Mobility:Node Mobility and Network Mobility• Review of Transport Layer Protocols:TCP inefficient for wirele...
6LoWPAN (IETF RFC4944)• IPv6 over Low Power Wireless Area Networks• Level 2/3 Protocol (OSI)• Enables usage of IPv6 by wir...
6LoWPAN: Protocol Stack
6LoWPAN: Architecture
Header compression
IEEE 802.15.446Within the broad organization of the Institute of Electrical and ElectronicsEngineers (IEEE), the 802 group...
IEEE 802.15.4 Device Definitions• Full function device (FFD)– Any topology– Network coordinator capable– Talks to any othe...
Adaptation of IPv6 to LoWPAN environmentSeveral constraints require an adaptation of IPv6 toLoWPAN environment:• Layer 2 f...
Adaptation of IPv6 to LoWPAN environment• Neighbor discovery messages should not befragmented. If some fragments are lost,...
OrganizationA 6LoWPAN network can be organized around threetopologies:• Star topology: All sensor nodes can reach and are ...
Organization• Routed: Nodes act as routers and forward packetstoward the destination. A routing protocol must berunning on...
Scenarios6LoWPAN architecture covers two scenarios:• The first, called mesh-under, supposes that anL2 relaying strategy is...
Network Architectures• Several routing protocols have already beendefined for fixed and ad-hoc IP networks.• In the series...
Routing Protocol for Low-Powerand Lossy Networks (RPL)• The protocol defined by the Roll workinggroup is called RPL.• It i...
Routing Protocol for Low-Powerand Lossy Networks (RPL)• RPL must also remain flexible in the definition ofrouting strategi...
RPL Galaxy
ROL Topology• The RPL topology is based on a direction orienteddirected acyclic graph (DODAG).• The DODAG is used to allow...
DAG and DODAG• Directed Acyclic Graph (DAG) - a directedgraph with no cycles exist.• Destination Oriented DAG (DODAG) - a ...
DODAG with multiple DAGs
ICMPv6 message• RPL defines a new ICMPv6 message with threepossible types:• DAG Information Object (DIO) - carriesinformat...
Metrics and Constraints• RPL intends to use different metrics andconstraints to build the topology.• The metrics used can ...
Metrics and ConstraintsMetrics or constraints can be also related to thenode:• energy: how the node is powered and percent...
Multicast• Multicast may be a useful feature, for example, whenswitching on several lights in a building at the sametime.•...
REST• REST is widely known as being the architecturalmodel of the web through the HTTP protocol.• As for the web, the REST...
InteractionsREST defines four interactions between the clientand the server:• GET (code 1 in the CoAP header): The clientr...
CoAP• The CoAP (constraint application protocol)protocol is a way of structuring the exchangeof information based on the r...
Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optim...
M2M Security• he M2M market is highly fragmented with many playersacross numerous vertical domains.• On the other hand, th...
Security Characteristics of Cellular M2M• Cellular M2M differs from current cellular networks in threeimportant ways, whic...
Trust Relationships in the M2M Ecosystem• Traditional network services, such as cellular voice anddata services, are provi...
Trust Relationships in the M2M Ecosystem• M2M operators negotiate network services in bulk from multiplenetwork providers ...
Business relationshipsbetween the main entities in smart metering service
Security Requirements• The M2M security requirements are drawnfrom the need to protect the various entitiesin the end-to-e...
Customer/M2M Device User• Devices can be hijacked for the data they provide or fortheir actuation capabilities by adversar...
Access Network Provider• Unlike the case of consumer electronic devices, inmany cases M2M devices are owned by the applica...
M2M Service Provider• The threats to an M2M service providerinclude all those applicable to a networkoperator.• In additio...
Application Provider• Adversaries may benefit from modifying thedata transferred from the device to the back-end applicati...
Common requirements (1/2)Common requirements for any security solution.• Mutual authentication: Only authenticated M2M dev...
Common requirements (2/2)• Integrity: Application servers should be able to verify theintegrity of the data originating fr...
Bootstrapping Requirements• Within the M2M ecosystem, we are dealing withan explosion in the number of devices (perhapsrun...
Complex ecosystem• We should expect a multitude of device vendorsparticipating in a relatively open ecosystem, selling low...
Scalability• M2M services typically involve a large number ofdevices, each sending a small amount of data.• The revenue pe...
Bootstrapping requires network authentication• More importantly, it is highly likely that the network operator (whoprovide...
Which Types of Solutions are Suitable• Various attack detection and preventionschemes for other types of deployments havea...
Approaches Against Hijacking• Encryption and Integrity Protection: A large body ofresearch and standardization studies hav...
Public Key Solutions• One well-known method for bootstrapping keys involvesprovisioning a private-public key pair along wi...
Smart Card-Based Solutions• The use of smart cards (SIM cards for GSM systems orUICC in general) is a very attractive opti...
Standardization Efforts on SecuringM2M and MTC Communications• Recently, there has been an increasing interest instandardi...
ETSI M2M Security• The ETSI M2M Standards Group is focused ondesigning the functional architecture of the M2Mservice provi...
3GPP MTC Security• Standardizing machine-type communications (MTCs)has received a lot of interest from the 3GPP.• The 3GPP...
Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optim...
M2M Terminals and ModulesM2M: Architecture and ApplicationsBTP, Bandung, 6-7 April 2013.Muhammad Ary Murtim_ary_murti@ieee...
• M2M Module Categorization• Hardware Interfaces• Temperature and Durability Services• Temperature and Durability Services...
Access TechnologyWireless or Wired ?• Wired access technologies require a physicalconnection to a cable such as a telephon...
M2M End-to-End Networkm_ARy-murti@ieee.org, 6-7 April 2013
M2M Access Networksm_ARy-murti@ieee.org, 6-7 April 2013
M2M Access Networks• Wired Solution – dedicated cabling between sensor - gateway:•  pros: very, very reliable; very high ...
Timeline of M2M• Nokia M2M Platform Family [2002] = Nokia M2M Gateway software +Nokia 31 GSM Connectivity Terminal + Nokia...
Wireless Link Distance• WPAN (wireless personal-area networks)• WLAN (wireless local-area networks), and• WWAN (wireless w...
WWAN technologies• frequency division multiple access (FDMA),e.g., AMPS;• time division multiple access (TDMA), e.g.,GSM;G...
Classifying WWAN by “Generation”• 1G (first generation) includes technologiessuch as AMPS, TACS and NTACS;• 2G includes te...
2G M2M modules are still beingdeployed in 2012• lower module cost• seen as more mature, that is, more reliable, low power,...
WAN Dominates the Wireless Connection SpaceMobile networks areexpected to hostroughly 86 millionconnections• Fixed install...
M2M Module Price ComparisonSource: Harbor Research, Inc., September 2010m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
Physical Form Factors M2Mmodule classificationsSolder-Down ModuleSolder pads are used with :a. line grid array (LGA)b. bal...
Physical Form Factors M2Mmodule classificationsPCI Express Mini Card (Peripheral ComponentInterconnect)• supports two opti...
Physical Form Factors M2Mmodule classificationsHighly Integrated• having a commercial housing and astandardized host inter...
Physical Form Factors M2Mmodule classificationsProprietary• since the M2M module vendor is not constrained in any way,the ...
Hardware Interfaces• Power Interface : 3.0 and 4.5 V• USB (Universal Serial Bus) Interface• UART (Universal Asynchronous R...
Temperature and Durability• Most modules provide an operating temperaturerange of −30 to +70°C, which is satisfactory form...
Software Interface (1/3)AT Commands• seven-bit ASCII character string commands.The interface was originally designed to be...
Software Interface (2/3)SDK Interface• Provides many function calls, methods,classes, and objects• Corresponds well with m...
Software Interface (3/3)An SDK provides many advantages over the AT command interfacesuch as:• excellent event-notificatio...
Cellular Certification• Beyond regulatory certification, which is requiredby all transmitting devices, cellular products a...
Telecom Industry Certification (1/3)• For GSM-based modules, the telecom industrycertification is controlled via two assoc...
Telecom Industry Certification (2/3)Telecom industry certification typically requires:• testing against some technical spe...
Telecom Industry Certification (3/3)Even if an integrated module has “module-certification,” the integrator can be expecte...
MNO Certification• MNO certification is not standardized, so the amountof testing, the test limits, and the test cases var...
Need To Be Optimizedm_ARy-murti@ieee.org, 6-7 April 2013
Need To Be Optimizedm_ARy-murti@ieee.org, 6-7 April 2013
Challenges for Capillary M2M• Core Challenge #1 – Delays: Connection Delay: optimize L2/L3 node discovery protocols Comm...
Challenges for Cellular M2M• Core Challenge #1 – Complexity & Power: Modulation: simple to detect in DL; constant envelop...
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
m_ARy-murti@ieee.org, 6-7 April 2013
M2M Companym_ARy-murti@ieee.org, 6-7 April 2013
The EndThe EndThank YouThank You
Upcoming SlideShare
Loading in...5
×

M2M Day Two

629

Published on

M2M Optimizations in Public Mobile Networks
M2M Over a Telecommunications Network
Network Optimizations for M2M

The Role of IP in M2M
IPv6 for M2M
6LoWPAN
Routing Protocol for Low-Power and Lossy Networks (RPL) CoRE

M2M Security
Trust Relationships in the M2M Ecosystem
Security Requirements
Which Types of Solutions are Suitable?
Standardization Efforts on Securing M2M and MTC Communications

M2M Terminals and Modules
M2M Module Categorization
Hardware Interfaces
Temperature and Durability Services
Software Interface
Cellular Certification

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
629
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

M2M Day Two

  1. 1. Syllabus Day one : Business and ArchitecturesIntroduction to M2MWhat is M2M?The Business of M2MAccelerating M2M MaturityM2M StandardsThe Business of M2MThe M2M MarketThe M2M Market Adoption: Drivers and BarriersThe M2M Value ChainMarket Size ProjectionsBusiness ModelsM2M Business MetricsMarket EvolutionEarly M2M DeploymentsM2M Requirements and High-Level Architectural PrinciplesUse-Case-Driven Approach to M2M RequirementsSmart Metering Approach in ETSI M2MSyllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optimizations for M2MThe Role of IP in M2MIPv6 for M2M6LoWPANRouting Protocol for Low-Power and Lossy Networks (RPL) CoREM2M SecurityTrust Relationships in the M2M EcosystemSecurity RequirementsWhich Types of Solutions are Suitable?Standardization Efforts on Securing M2M and MTC CommunicationsM2M Terminals and ModulesM2M Module CategorizationHardware InterfacesTemperature and Durability ServicesSmart Metering Approach in ETSI M2MeHealth Approach in ETSI M2MHigh-Level Architecture Principles for M2M CommunicationETSI M2M Services ArchitectureHigh-Level System ArchitectureETSI TC M2M Service Capabilities FrameworkETSI TC M2M Release 1 ScenariosETSI M2M Service CapabilitiesIntroducing REST Architectural Style for M2METSI TC M2M Resource-Based M2M Communication and ProceduresTemperature and Durability ServicesSoftware InterfaceCellular Certification
  2. 2. 7 April 20137 April 2013Day two: DeploymentDay two: Deployment
  3. 3. Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optimizations for M2MThe Role of IP in M2MIPv6 for M2M6LoWPANRouting Protocol for Low-Power and Lossy Networks (RPL) CoREM2M SecurityTrust Relationships in the M2M EcosystemSecurity RequirementsWhich Types of Solutions are Suitable?Standardization Efforts on Securing M2M and MTC CommunicationsStandardization Efforts on Securing M2M and MTC CommunicationsM2M Terminals and ModulesM2M Module CategorizationHardware InterfacesTemperature and Durability ServicesSoftware InterfaceCellular CertificationArief Hamdani GunawanArief Hamdani Gunawan
  4. 4. M2M Optimizations in Public Mobile Networks• Many M2M applications use publictelecommunications networks to transfer data fromM2M devices to an M2M server.• These telecommunications networks will have to beadapted to cope with the traffic generated by theprojected growth of M2M applications.projected growth of M2M applications.• In the near future, many more devices will beconnected to the existing networks, as more and moreM2M applications are introduced.• These M2M devices will have a very different effect onthe telecommunications network compared to human-oriented devices.
  5. 5. Device-to-server and device-to-device communication scenarios
  6. 6. M2M communication path via M2M server
  7. 7. M2M gateway scenario
  8. 8. M2M via mobile networks creates independence from operators
  9. 9. Different M2M applications have different communication needs
  10. 10. Data connection establishment in a cellular mobile network
  11. 11. Different M2M applications with different communication patterns
  12. 12. Network Optimizationfor machine-type communicationfeatures in 3GPP Release 10 and Release 1
  13. 13. Machine Type Communications• M2M is recognized as a key segment in futurecellular mobile packet data networks• Initial 3GPP efforts have focused on the ability todifferentiate MTC -type devicesdifferentiate MTC -type devices– This allows the operator to selectively handle suchdevices in congestion/overload situations• Low priority indicator has been added to the relevant UE-network procedures• Overload and Congestion control is done on both corenetwork and radio access network based on this indicator
  14. 14. 3GPP MTC Architecture
  15. 15. Cost OptimizationsCost drivers for an M2M applicationin a mobile telecommunications network
  16. 16. Traffic OptimizationsQoS traffic classes in UMTS
  17. 17. QoS parameters applicable to the different UMTS traffic classes
  18. 18. Numbering and Identifiers Optimizations• E.164 number format for telephone numbers• Format for the International Mobile SubscriberIdentity (IMSI)
  19. 19. Numbering and Identifiers Optimizations• Format for the International Mobile EquipmentIdentity (IMEI)• Format for the International Mobile EquipmentIdentity and Software Version Number (IMEISV)
  20. 20. Numbering and Identifiers Optimizations• Format of the International Circuit Card Identifier(ICCID)
  21. 21. The Basics of Triggering (1/3)When the M2M server decides to trigger an M2Mdevice, it generally includes the followinginformation in the trigger message:• the identity of the target M2M device;the identity of the application• the identity of the application• a request counter associated to this requestallowing for the detection of duplicated requests,for the correlation of requests with theiracknowledgment, and to allow the application tocancel a request;
  22. 22. The Basics of Triggering (2/3)• (optionally) the IP address (or FQDN) and/or portnumbers of the application server that the UE has tocontact;• (optionally) an urgency request indication;• (optionally) a validity timer, allowing for the removal oftriggers that are stored in the network when the device• (optionally) a validity timer, allowing for the removal oftriggers that are stored in the network when the devicecannot be reached, for example, with SMS;• (optionally) the area where triggering needs to be sent;• (optionally) a limited amount of application-specificinformation, for example, to instruct the M2M deviceto do something before establishing communicationwith the M2M server.
  23. 23. Triggering Optimizations (3/3)Before the M2M server can send the trigger message, it needsto determine where to send the trigger request. 3GPP isdefining a machine-type communication gateway (MTCGW) that will act as an entry point in the mobile networkfor control messages from the M2M servers.The MTC GW may be pre-provisioned in the M2M server inThe MTC GW may be pre-provisioned in the M2M server incase the M2M server only communicates with one networkoperator.Otherwise, the M2M server first needs to determine to whichoperator a trigger request needs to be sent. Based on thedevice ID or IMSI, the M2M server should be able to findthe correct mobile operator network.
  24. 24. Triggering Optimizations:Overview architecture with different triggering solutions.
  25. 25. Triggering Optimizations:Triggering Mechanisms• triggering using mobile-terminated SMS;
  26. 26. Triggering Optimizations:Triggering Mechanisms• triggering using IMS messages;
  27. 27. Triggering Optimizations:Triggering Mechanisms• triggering using cell broadcast;
  28. 28. Triggering Optimizations:Triggering Mechanisms• triggering via HSS and non-access stratum (NAS) signaling;
  29. 29. Triggering Optimizations:Triggering Mechanisms• triggering via network-requested PDP contextestablishment
  30. 30. Closing• For M2M application owners, mobile networksare often more suitable as they offer betterpossibilities for controlling the subscription andhave end-to-end visibility of the data connection.• From an operator point of view, mobile networks• From an operator point of view, mobile networkscreate more challenges whereby optimizationsare needed to cater for large volumes of M2Mtraffic. Nevertheless, a lot of the issues,problems, and solutions discussed are genericand will also apply to fixed networks
  31. 31. Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optimizations for M2MThe Role of IP in M2MIPv6 for M2M6LoWPANRouting Protocol for Low-Power and Lossy Networks (RPL) CoREM2M SecurityTrust Relationships in the M2M EcosystemSecurity RequirementsWhich Types of Solutions are Suitable?Standardization Efforts on Securing M2M and MTC CommunicationsStandardization Efforts on Securing M2M and MTC CommunicationsM2M Terminals and ModulesM2M Module CategorizationHardware InterfacesTemperature and Durability ServicesSoftware InterfaceCellular CertificationArief Hamdani GunawanArief Hamdani Gunawan
  32. 32. The Role of IP in M2M• Very few computer network protocols lasted as long as the IPv4protocol. Even if, at the outset, IP was never designed to becomethe universal protocol we know nowadays, it was made versatileenough to evolve and cover an ever-increasing number ofapplications.• IPv6 protocol is a simplification of the IPv4 packet and retains thesame principle. Fields that proved to be unused after years ofsame principle. Fields that proved to be unused after years ofexploitation have been removed.– The first of these, the option field leading to a variable header size, hasbeen withdrawn and replaced by extensions. An extension can beviewed as an intermediary protocol between Layer 3 (IP) and Layer 4(UDP, TCP), except for the hop-by-hop extension that must beprocessed by each router on the path. Other extensions are invisiblefrom the core network and only processed by the final destination.
  33. 33. Internet Protocol (IP) version 6
  34. 34. IP Addresses Optimizations• M2M communication scenario using IPv6 addressing• M2M communication scenario using IPv4 addressing
  35. 35. IP Addresses Optimizations• M2M communication scenario using privateIPv4 addressing only
  36. 36. Network Applications• Network applications cannot rely on thedevice being constantly available and able tosend or receive data.• Examples of IP-based communication protocol• Examples of IP-based communication protocolevolutions to cope with constrained devicesinclude the work done in the IETF 6LoWPAN(IPv6 over low power and lossy networks)Working Group.
  37. 37. Constrained but still Internet• Today - a complete IP based Web stack can be run on smalldevices with microcontrollers.(ConstrainedApplicationProtocol)
  38. 38. IETF 6LoWPAN• The 6LoWPAN WG group has defined encapsulationand header compression mechanisms that allow IPv6packets to be sent and received over IEEE 802.15.4-based networks. IEEE 802.15.4 maximum transfer unit(MTU) is limited to 127 bytes.• Taking into account frame overhead and optional• Taking into account frame overhead and optionalsecurity headers, very little is left for upper layers, thatis, TCP/IP and application payload, unless protocoloverhead is optimized.• In essence, the 6LowPAN work allows IP to be used allthe way to constrained devices, a desirable feature toallow for an end-to-end IP-based communication.
  39. 39. 6LoWPAN: Why IPv6?• Long-lived technology (20 years+)• Ability to connect heterogeneous networks• Existing worldwide free-to-use infrastructure• Global scalability• Global scalability• 2^128 Bit (16 Byte) Addressing = Enough forInternet of Things• Great number of tools (diagnostic,management etc.)
  40. 40. IPv6 Problems• Bandwidth and Energy efficiencyStandard protocol: IEEE 802.15.4 L1/L2 (low bandwidth:250 kbps, low power: 1mW)• Fragmentation:IPv6 minimum frame size (MTU) = 1280 bytesIPv6 minimum frame size (MTU) = 1280 bytesIEEE 802.15.4 frame size (MTU) = 127 byte (higher bit errorrate, failure proneness)• Header compression:IPv6 headers (40 bytes) reduce payload53 byte payload in 127 byte 802.15.4 frame
  41. 41. IPv6 Problems• Mobility:Node Mobility and Network Mobility• Review of Transport Layer Protocols:TCP inefficient for wireless embedded devices (wireless packet lost)• Handle offline devices:• IP assumes devices are always on, but embedded devices may not(power and duty cycles)• Multicast support:IEEE 802.15.4 & other radios do not support Multicast (expensive)
  42. 42. 6LoWPAN (IETF RFC4944)• IPv6 over Low Power Wireless Area Networks• Level 2/3 Protocol (OSI)• Enables usage of IPv6 by wireless embedded devices• Dedicated to specific task/ not general purpose like PC• Limited hardware resources:• Limited hardware resources:– Low processing power (microcontroller/ dsp)– Little memory– Low power• Limited networks capabilities:– Short range– Low bitrate– Message-Size
  43. 43. 6LoWPAN: Protocol Stack
  44. 44. 6LoWPAN: Architecture
  45. 45. Header compression
  46. 46. IEEE 802.15.446Within the broad organization of the Institute of Electrical and ElectronicsEngineers (IEEE), the 802 group is the section that deals with networkoperations and technologies.Group 15 works more specifically with wireless networking, and TaskGroup 4 drafted the 802.15.4 standard for a low data rate wirelesspersonal area network (WPAN).
  47. 47. IEEE 802.15.4 Device Definitions• Full function device (FFD)– Any topology– Network coordinator capable– Talks to any other device– Talks to any other device• Reduced function device (RFD)– Limited to star topology– Cannot become a network coordinator– Talks only to a network coordinator– Very simple implementation
  48. 48. Adaptation of IPv6 to LoWPAN environmentSeveral constraints require an adaptation of IPv6 toLoWPAN environment:• Layer 2 frame size may be limited compared to the IPv6specifications with a minimum mandatory MTU of1280 bytes. Fragmentation is required to provide the1280 bytes. Fragmentation is required to provide theframe lengths specified by IPv6• Energy can be drastically limited in some nodes. Forinstance, some metering devices may run for severalyears (up to 15) on the same battery. Unnecessaryexchanges and multicast traffic must be avoided inorder to save power.
  49. 49. Adaptation of IPv6 to LoWPAN environment• Neighbor discovery messages should not befragmented. If some fragments are lost, theprotocol becomes inefficient.• Radio range may be reduced and the IPv6• Radio range may be reduced and the IPv6packet will have to be relayed from node tonode to reach the destination or an LBR.• The neighborhood is not as well-defined as inwired or WiFi networks and radio rangevariation causes the neighbor list to change.
  50. 50. OrganizationA 6LoWPAN network can be organized around threetopologies:• Star topology: All sensor nodes can reach and are reachablefrom the LBR.• Meshed: Nodes are organized at Layer 2 in order to relayframes toward the destination. Algorithms to organize theframes toward the destination. Algorithms to organize theinterconnection are not defined by 6LoWPAN, which simplyoffers generic support to manage broadcast and hop-by-hop bridging. From the point of view of the Internet, ameshed network is similar to an Ethernet network whereevery node shares the same prefix. 6LoWPAN refers to thattechnology as mesh-under (MU).
  51. 51. Organization• Routed: Nodes act as routers and forward packetstoward the destination. A routing protocol must berunning on some nodes in order to constructforwarding information. Nodes acting as a routerinside the LoWPAN network and not directlyinside the LoWPAN network and not directlyconnected to the Internet are called LoWPAN routers(LRs). 6LoWPAN refers to that technology as route-over (RO). The best candidate is the RPL protocol, asdefined by the Roll working group
  52. 52. Scenarios6LoWPAN architecture covers two scenarios:• The first, called mesh-under, supposes that anL2 relaying strategy is defined, resulting in themesh network acting as a link for the IP layer.mesh network acting as a link for the IP layer.• The second, called route-over, supposes thatsome nodes have routing capabilities and areable to forward packets toward thedestination.
  53. 53. Network Architectures• Several routing protocols have already beendefined for fixed and ad-hoc IP networks.• In the series of RFCs, the Roll working grouphas defined the requirement for differenthas defined the requirement for differentnetwork architectures:– urban networks;– industrial networks;– home networks;– building networks.
  54. 54. Routing Protocol for Low-Powerand Lossy Networks (RPL)• The protocol defined by the Roll workinggroup is called RPL.• It is based on distance vector algorithms, suchas routing information protocol (RIP), and isas routing information protocol (RIP), and isdesigned to correct performance issues due tobad loop detection.
  55. 55. Routing Protocol for Low-Powerand Lossy Networks (RPL)• RPL must also remain flexible in the definition ofrouting strategies.• An urban network will not have the sameconstraints as a home network, and also, withineach network type, the applications do noteach network type, the applications do notalways share the same objectives.• An alarm system may try to reduce propagationdelays, and an application generating periodicmessages will try to select routers with thehighest level of energy (powered).
  56. 56. RPL Galaxy
  57. 57. ROL Topology• The RPL topology is based on a direction orienteddirected acyclic graph (DODAG).• The DODAG is used to allow the upward traffic toleave the LLN, but can also be used afterwards tobuild a reverse path toward the nodes and leaves.build a reverse path toward the nodes and leaves.• One difference compared with RIP, whichmaintains a single path toward a destination, isthat the DODAG may contain more loop-freepaths toward the destination, which increasesreliability and speeds up recovery in the event ofa route failure.
  58. 58. DAG and DODAG• Directed Acyclic Graph (DAG) - a directedgraph with no cycles exist.• Destination Oriented DAG (DODAG) - a DAGrooted at a single destination.rooted at a single destination.
  59. 59. DODAG with multiple DAGs
  60. 60. ICMPv6 message• RPL defines a new ICMPv6 message with threepossible types:• DAG Information Object (DIO) - carriesinformation that allows a node to discover an RPLInstance, learn its configuration parameters andInstance, learn its configuration parameters andselect DODAG parents• DAG Information Solicitation (DIS) - solicit aDODAG Information Object from a RPL node• Destination Advertisement Object (DAO) - used topropagate destination information upwards alongthe DODAG.
  61. 61. Metrics and Constraints• RPL intends to use different metrics andconstraints to build the topology.• The metrics used can be additive (i.e., pathquality), can report a minimum or a maximumquality), can report a minimum or a maximum(i.e., the energy of node on the path) andfinally can be multiplicative (i.e., error rate onthe path).
  62. 62. Metrics and ConstraintsMetrics or constraints can be also related to thenode:• energy: how the node is powered and percentageof remaining energy;• hop count: number of crossed hosts;• hop count: number of crossed hosts;• throughput, latency;• link quality level: from 1 (highest) to 7 (lowest);• ETX (expected transmission): number oftransmissions required to successfully send apacket
  63. 63. Multicast• Multicast may be a useful feature, for example, whenswitching on several lights in a building at the sametime.• RPL routing protocol may be used to implementmulticast in a LoWPAN, but the group managementmay require significant amounts of energy to flood themay require significant amounts of energy to flood thewhole network.• The CoRE working group is currently defining a methodfor implementing multicast at the application level in aproxy gateway.– CoRE: Constrained RESTful Environments– REST: Representational State Transfer
  64. 64. REST• REST is widely known as being the architecturalmodel of the web through the HTTP protocol.• As for the web, the RESTful architecture is well-suited to most types of M2M applications.• It is based on the client-server paradigm.• It is based on the client-server paradigm.• The server contains information that can besaved or retrieved by clients.• In this instance, a sensor or an actuator can beviewed as a server and the application or thegateway is treated as the client.
  65. 65. InteractionsREST defines four interactions between the clientand the server:• GET (code 1 in the CoAP header): The clientrequests the information located on the server.• POST (code 2): The client creates and stores the• POST (code 2): The client creates and stores theinformation on a resource located on the server.• PUT (code 3): The client stores information on aresource based on the server.• DELETE (code 4): The client removes a resourcefrom the server
  66. 66. CoAP• The CoAP (constraint application protocol)protocol is a way of structuring the exchangeof information based on the representationalstate transfer (REST) paradigm but optimizedstate transfer (REST) paradigm but optimizedfor M2M applications.• The HTTP protocol is the most famousexample of REST architecture.
  67. 67. Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optimizations for M2MThe Role of IP in M2MIPv6 for M2M6LoWPANRouting Protocol for Low-Power and Lossy Networks (RPL) CoREM2M SecurityTrust Relationships in the M2M EcosystemSecurity RequirementsWhich Types of Solutions are Suitable?Standardization Efforts on Securing M2M and MTC CommunicationsStandardization Efforts on Securing M2M and MTC CommunicationsM2M Terminals and ModulesM2M Module CategorizationHardware InterfacesTemperature and Durability ServicesSoftware InterfaceCellular CertificationArief Hamdani GunawanArief Hamdani Gunawan
  68. 68. M2M Security• he M2M market is highly fragmented with many playersacross numerous vertical domains.• On the other hand, the industry has reached a point wherethe value of M2M services for improving productivity in theenterprise, as well as convenience and comfort forconsumers, is broadly understood.consumers, is broadly understood.• Given the increased focus on M2M applications by largenetwork operators with a view toward leveraging theirexisting assets, coupled with the opening up of theirnetworks and devices, M2M communications is poised totake off in an unprecedented fashion.• The communication security is a critical enabler for themass market adoption of M2M.
  69. 69. Security Characteristics of Cellular M2M• Cellular M2M differs from current cellular networks in threeimportant ways, which suggests that the current securitymechanisms in place today for mobile devices in such networks arenot appropriate for M2M.• First, cellular network services today are typically provided by asingle service provider that typically owns the device distributionalong with the SIM card distribution, device provisioning, networkalong with the SIM card distribution, device provisioning, networkinfrastructure, and service delivery for voice and data services.• In some cases, the device distribution, device provisioning, andservice delivery are owned by a mobile virtual network operator(MVNO), while the underlying network infrastructure is owned by adifferent network provider.• On the other hand with cellular M2M, multiple players exist withlimited business relationships among them.
  70. 70. Trust Relationships in the M2M Ecosystem• Traditional network services, such as cellular voice anddata services, are provided by operators that deployand operate the network, market the services, certifyand channel the devices to end-users, and manage theend-user subscriptions and billing.• Essentially, a single entity is involved in all aspects of• Essentially, a single entity is involved in all aspects ofeach service.• On the other hand, M2M services typically involvemultiple entities in the delivery of each service.• The entities most commonly involved are the end-user,the network provider, the M2M service provider, theapplication provider, and the device manufacturer.
  71. 71. Trust Relationships in the M2M Ecosystem• M2M operators negotiate network services in bulk from multiplenetwork providers and manage the network access subscriptions onbehalf of many application providers.• Application providers, as the name suggests, are the entities thatprovide the end-user application, such as collecting and processingthe data.• An end-user may buy a device that incorporates the network• An end-user may buy a device that incorporates the networkconnectivity module directly from the manufacturer (through aretail distribution network) or from the application provider. Hence,the ecosystem is much more complex than a traditional networkservice.• This renders the design of efficient end-to-end security solutionsquite challenging
  72. 72. Business relationshipsbetween the main entities in smart metering service
  73. 73. Security Requirements• The M2M security requirements are drawnfrom the need to protect the various entitiesin the end-to-end solution from perceivedthreats.threats.• We will provide examples of the threatsexperienced by each of the players identifiedin the previous section and then summarizethe security requirements
  74. 74. Customer/M2M Device User• Devices can be hijacked for the data they provide or fortheir actuation capabilities by adversaries pretendingto be the back-end application servers.• A scenario where such an attack could be of someeconomic value to the adversary is the remote controlof home automation devices, such as alarms andof home automation devices, such as alarms andgarage door openers.• By pretending to be the network-based homeautomation server, attackers can deactivate the alarm,and open doors to enter the house. Devices must beprotected from unauthorized entities trying toestablish communications to and from the devices
  75. 75. Access Network Provider• Unlike the case of consumer electronic devices, inmany cases M2M devices are owned by the applicationproviders and deployed in premises that are notconstantly physically monitored or protected.• For example, in the case of smart metering, the metersare typically owned by the utility companies andare typically owned by the utility companies anddeployed in homes and small business locations.• These devices are thus more susceptible to theft.• Misuse of stolen communication modules found inthese devices for the purpose of regular Internetcommunication, such as web-browsing, should not bepermitted.
  76. 76. M2M Service Provider• The threats to an M2M service providerinclude all those applicable to a networkoperator.• In addition, it is the responsibility of the M2M• In addition, it is the responsibility of the M2Moperator to ensure service availability toapplication providers and guarantee that thedata sent to application-provider data centersis not tampered with.
  77. 77. Application Provider• Adversaries may benefit from modifying thedata transferred from the device to the back-end application server or vice versa throughman-in-the-middle attacks.man-in-the-middle attacks.• It should thus be possible to verify theintegrity of data transferred between theentities
  78. 78. Common requirements (1/2)Common requirements for any security solution.• Mutual authentication: Only authenticated M2M devicescan access the network and M2M system, and converselyany M2M device should authenticate the server beforeaccepting any data, such as commands or management-related updates. This will ensure that data collected by therelated updates. This will ensure that data collected by theback-end-server is coming from a legitimate device, andthe device is assured that it is communicating with alegitimate server. The mutual authentication procedureshave to be completed between the M2M device and theM2M operator network before initiating data transfer.• Confidentiality: Data transfer between the M2M device andthe application server should be protected fromunauthorized eavesdropping.
  79. 79. Common requirements (2/2)• Integrity: Application servers should be able to verify theintegrity of the data originating from an associated device.Similarly, devices should be able to verify the integrity ofthe data sent by the affiliated servers. This protects thedata from unauthorized modifications or manipulations.• Exclusivity: Communication devices in the machine module• Exclusivity: Communication devices in the machine moduleshould not be capable of being used for other applications.When the network provider entity is separate from theapplication provider entity, this requirement implies thatthe network provider has to deny service to a tampereddevice.• Anonymity: The identity of the device should not berevealed to an eavesdropper in the network.
  80. 80. Bootstrapping Requirements• Within the M2M ecosystem, we are dealing withan explosion in the number of devices (perhapsrunning into the billions, if widely adopted) andhundreds of applications provided by a fewvirtual operators using a mix of access networks.virtual operators using a mix of access networks.• Therefore, several constraints are imposed on thebootstrapping of security keys:– Complex ecosystem– Scalability– Bootstrapping requires network authentication
  81. 81. Complex ecosystem• We should expect a multitude of device vendorsparticipating in a relatively open ecosystem, selling low-costdevices directly to consumers.• For instance, as described earlier, the complex ecosystemmay involve device manufacturers selling on an openmarket while service providers may not have a businessmarket while service providers may not have a businessrelationship with the device vendor or reseller.• Alternatively, in residential applications such as metering,the end-user (home-owner) may not even know the virtualnetwork operator who is providing the service on behalf ofthe owner of the organization which owns the application,but yet securing the application is critical to all players inthe chain.
  82. 82. Scalability• M2M services typically involve a large number ofdevices, each sending a small amount of data.• The revenue per device is generally small for any of theplayers in the value chain. Thus, it is important tominimize expenses incurred in deploying andminimize expenses incurred in deploying andmaintaining these devices.• One of the key steps in the deployment of devices isthe provisioning of the device in the appropriatedatabases of the network and application provider. Inparticular, provisioning of keys or other information forthe security solution should be simple and scalable.
  83. 83. Bootstrapping requires network authentication• More importantly, it is highly likely that the network operator (whoprovides bandwidth to the M2M operator) will not be able to tellwhen a device is executing a bootstrapping application.• For instance, this constraint requires that a device authenticateitself with the mobile data network using a network access identity,which allows the network operator to “recognize” the device and“authorize the data transaction,” despite the device not yet“authorize the data transaction,” despite the device not yetpossessing security keys or other access credentials.• In other words, bootstrapping protocols for M2M devices shouldassume that the M2M system is an overlay over existing (anddeployed) networking systems, thereby requiring devices tosuccessfully register with the access network before thebootstrapping application is invoked, and such registrationprocedures should clearly comply with existing networkingstandards
  84. 84. Which Types of Solutions are Suitable• Various attack detection and preventionschemes for other types of deployments havealready been proposed.• We develop them further below.• We develop them further below.– Approaches Against Hijacking– Public Key Solutions– Smart Card-Based Solutions
  85. 85. Approaches Against Hijacking• Encryption and Integrity Protection: A large body ofresearch and standardization studies have proposedthe use of cryptographic operations in order to detectand prevent hijacking attacks.• IP Address-Based Filtering: The idea here is to checkthe source IP address of packets at intermediatethe source IP address of packets at intermediaterouters along a routing path in order to detectimpersonation, reflection, and hiding attacks. Suchtechniques involve checking incoming packets usingrouting tables and looking up the return path for thesource IP address, as well as comparing the IP addressthat has been allocated to a specific MAC address,potentially through IPCP or DHCP
  86. 86. Public Key Solutions• One well-known method for bootstrapping keys involvesprovisioning a private-public key pair along with a certificate of apublic key.• This pair can be individually generated during manufacture and canbe pre-installed along with the corresponding certificate.• Following this, during installation, the device could execute a well-known public-key-based key-agreement protocol (such as internetknown public-key-based key-agreement protocol (such as internetkey exchange – IKE) to bootstrap a root key.• While this sounds straightforward (and uses known techniques),some of the issues with this method include the need for a large-scale public key infrastructure (PKI) that can potentially handle abillion devices
  87. 87. Smart Card-Based Solutions• The use of smart cards (SIM cards for GSM systems orUICC in general) is a very attractive option for scenarioswith M2M deployments over cellular networks. Sincethe late 1990s, SIM cards have been widely used bycellular network operators in mobile phones and othercellular network operators in mobile phones and othermobile devices that attach to cellular base stations.• Hence, for certain cellular M2M cases where devicesare by default equipped with smart cards, such cardscould provide the necessary key material for use by theM2M service or the application layer, based on policiesand relationships .
  88. 88. Standardization Efforts on SecuringM2M and MTC Communications• Recently, there has been an increasing interest instandardizing various aspects of M2M security.Such interest is aligned with parallel efforts onstandardizing functional architecture settings.standardizing functional architecture settings.• In what follows, we discuss the current state ofsuch efforts for different standardization bodies.– ETSI M2M Security– 3GPP MTC Secturity
  89. 89. ETSI M2M Security• The ETSI M2M Standards Group is focused ondesigning the functional architecture of the M2Mservice provider.• It considers that the M2M provider is a service-layerentity, which logically resides above the access layer,entity, which logically resides above the access layer,and which is independent of (but may be collaboratingwith) the access network operator(s), as well as theM2M application provider(s).• The establishment of secure data sessions betweenM2M devices (or gateways) and the ETSI M2M servicecapabilities is based on the existence of a key hierarchy.
  90. 90. 3GPP MTC Security• Standardizing machine-type communications (MTCs)has received a lot of interest from the 3GPP.• The 3GPP security group, SA3, has been guided by thegroup requirements and the network architecturegroup (SA1 and SA2, respectively) toward designingand standardizing security procedures related toand standardizing security procedures related tonetwork improvements for MTC.• Since 3GPP is predominantly interested in operationsexclusively involving the deployed 3GPP network,architecture, and thereby security support for M2Mcommunications is tied to the existing 3GPP networkdesign.
  91. 91. Syllabus Day Two : DeploymentM2M Optimizations in Public Mobile NetworksM2M Over a Telecommunications NetworkNetwork Optimizations for M2MThe Role of IP in M2MIPv6 for M2M6LoWPANRouting Protocol for Low-Power and Lossy Networks (RPL) CoREM2M SecurityTrust Relationships in the M2M EcosystemSecurity RequirementsWhich Types of Solutions are Suitable?Standardization Efforts on Securing M2M and MTC CommunicationsM2M Terminals and ModulesM2M Terminals and ModulesM2M Module CategorizationHardware InterfacesTemperature and Durability ServicesSoftware InterfaceCellular CertificationMuhammad Ary MurtiMuhammad Ary Murti
  92. 92. M2M Terminals and ModulesM2M: Architecture and ApplicationsBTP, Bandung, 6-7 April 2013.Muhammad Ary Murtim_ary_murti@ieee.org
  93. 93. • M2M Module Categorization• Hardware Interfaces• Temperature and Durability Services• Temperature and Durability Services• Software Interface• Cellular Certificationm_ARy-murti@ieee.org, 6-7 April 2013
  94. 94. Access TechnologyWireless or Wired ?• Wired access technologies require a physicalconnection to a cable such as a telephone line (e.g.,RJ11) or the cable companys coaxial cable (e.g., RG-6).• Some of the more popular wired access technologiesfor M2M include powerline communications (PLC)• Some of the more popular wired access technologiesfor M2M include powerline communications (PLC)(connection to AC mains), Ethernet (RJ-45), and xDSL.• The use of wired-access technologies is not commonfor M2M for several reasons, namely the inability tosupport mobility, the high infrastructure costs of layingnew cable (PLC excluded), and the comparativecomplexity of maintenance.m_ARy-murti@ieee.org, 6-7 April 2013
  95. 95. M2M End-to-End Networkm_ARy-murti@ieee.org, 6-7 April 2013
  96. 96. M2M Access Networksm_ARy-murti@ieee.org, 6-7 April 2013
  97. 97. M2M Access Networks• Wired Solution – dedicated cabling between sensor - gateway:•  pros: very, very reliable; very high rates, little delay, secure, cheap tomaintain•  cons: very expensive to roll out, not scalable• Wireless Cellular Solution – dedicated cellular link:•  pros: excellent coverage, mobility, roaming, generally secure•  cons: expensive rollout, not cheap to maintain, not power efficient,•  cons: expensive rollout, not cheap to maintain, not power efficient,delays• Wireless Capillary Solution – shared short-range link/network:•  pros: cheap to roll out, generally scalable, low power•  cons: not cheap to maintain, poor range, low rates, weaker security,large delays• (Wireless) Hybrid Solution – short-range until cellular aggregator:•  pros: best tradeoff between price, range, rate, power, etc.•  cons: not a homogenous and everything-fits-all solutionm_ARy-murti@ieee.org, 6-7 April 2013
  98. 98. Timeline of M2M• Nokia M2M Platform Family [2002] = Nokia M2M Gateway software +Nokia 31 GSM Connectivity Terminal + Nokia M2M Application Develop.Kit (ADK)m_ARy-murti@ieee.org, 6-7 April 2013
  99. 99. Wireless Link Distance• WPAN (wireless personal-area networks)• WLAN (wireless local-area networks), and• WWAN (wireless wide-area networks)m_ARy-murti@ieee.org, 6-7 April 2013
  100. 100. WWAN technologies• frequency division multiple access (FDMA),e.g., AMPS;• time division multiple access (TDMA), e.g.,GSM;GSM;• code division multiple access (CDMA), e.g.,UMTS;• orthogonal frequency division multiple access(OFDMA); e.g., LTE (long-term evolution)m_ARy-murti@ieee.org, 6-7 April 2013
  101. 101. Classifying WWAN by “Generation”• 1G (first generation) includes technologiessuch as AMPS, TACS and NTACS;• 2G includes technologies such as IS-136, GSM,and most commercial deployments of 1xRTT;and most commercial deployments of 1xRTT;• 3G includes UMTS, TD-SCDMA, and EVDO;• 3.5G includes technologies such as HSPA(high-speed packet access);• 4G includes UMB (ultra-mobile broadband),WiMAX (802.16e), and LTE.m_ARy-murti@ieee.org, 6-7 April 2013
  102. 102. 2G M2M modules are still beingdeployed in 2012• lower module cost• seen as more mature, that is, more reliable, low power, andhave more features and services• seen as superior—since most 2G was initially deployed inthe lower bands (cellular 800 and 900 MHz GSM band), and3G in the higher bands (1800 MHz DCS and 1900 PCS), 2G3G in the higher bands (1800 MHz DCS and 1900 PCS), 2Ghas a natural advantage of better coverage, especially forindoor penetration.• seen as good enough—since it is possible and even likelythat the module will have to operate in 2G mode in ruraland indoor areas (see the previous bullet-point oncoverage), the M2M application needs to be designed for2G throughputs and latencies.m_ARy-murti@ieee.org, 6-7 April 2013
  103. 103. WAN Dominates the Wireless Connection SpaceMobile networks areexpected to hostroughly 86 millionconnections• Fixed installations• Fixed installationsare usually shortrange to a home hub• Greater demand formobility, faster dataspeeds and remotemonitoringSource: Machina Researchm_ARy-murti@ieee.org, 6-7 April 2013
  104. 104. M2M Module Price ComparisonSource: Harbor Research, Inc., September 2010m_ARy-murti@ieee.org, 6-7 April 2013
  105. 105. m_ARy-murti@ieee.org, 6-7 April 2013
  106. 106. Physical Form Factors M2Mmodule classificationsSolder-Down ModuleSolder pads are used with :a. line grid array (LGA)b. ball grid arrays (BGAs)b. ball grid arrays (BGAs)m_ARy-murti@ieee.org, 6-7 April 2013
  107. 107. Physical Form Factors M2Mmodule classificationsPCI Express Mini Card (Peripheral ComponentInterconnect)• supports two options for host interface connectivity—PCI express and USB 2.0—most M2M module vendorsonly support USB 2.0 connectivity.• defined as 30 × 50.95 mm with a maximum thickness• defined as 30 × 50.95 mm with a maximum thicknessof 5 mm.• PCI-SIG has also defined a half-length card that isspecified at 30 × 26.8 mm press Mini Cardm_ARy-murti@ieee.org, 6-7 April 2013
  108. 108. Physical Form Factors M2Mmodule classificationsHighly Integrated• having a commercial housing and astandardized host interface : USB, RS232, orRJ45RJ45m_ARy-murti@ieee.org, 6-7 April 2013
  109. 109. Physical Form Factors M2Mmodule classificationsProprietary• since the M2M module vendor is not constrained in any way,the vendors can often innovate beyond the other form factorsto produce a module that is smaller or less costly or morereliable or has better heat-dissipation properties or is morereliable or has better heat-dissipation properties or is morespecialized to a particular M2M application.m_ARy-murti@ieee.org, 6-7 April 2013
  110. 110. Hardware Interfaces• Power Interface : 3.0 and 4.5 V• USB (Universal Serial Bus) Interface• UART (Universal Asynchronous Receiver/ Transmitter) Interfacebaud rate supported by the module is 1200–115,200 bps• Antenna Interface• UICC (Universal Integrated Circuit Card) Interface• UICC (Universal Integrated Circuit Card) Interface• GPIO (General-Purpose Input/Output Port) Interface• SPI (Serial Peripheral Interface) Interface• I2C (Inter-Integrated Circuit Bus) Interface : 400 Kbps• ADC (Analog-to-Digital Converter) Interface• PCM (Pulse Code Modulation) Interface• PWM (Pulse Width Modulation) Interface• Analog Audio Interfacem_ARy-murti@ieee.org, 6-7 April 2013
  111. 111. Temperature and Durability• Most modules provide an operating temperaturerange of −30 to +70°C, which is satisfactory formost industrial applications,• but the automotive, metering, and some otherindustrial applications are demanding higherindustrial applications are demanding higheroperaTng ranges of −40 to +85°C.• The thermal shock cycle is another importantparameter, and module vendors typically provideas many as 1000 thermal shock cycles on somemodules.m_ARy-murti@ieee.org, 6-7 April 2013
  112. 112. Software Interface (1/3)AT Commands• seven-bit ASCII character string commands.The interface was originally designed to besent over a serial link but can also besent over a serial link but can also becommonly used over USB• The oldest, best-known, and thus mostcommonly used• 3GPP has standardized a broad set of ATcommands in the TS 27.707 specificationm_ARy-murti@ieee.org, 6-7 April 2013
  113. 113. Software Interface (2/3)SDK Interface• Provides many function calls, methods,classes, and objects• Corresponds well with more powerful OS-• Corresponds well with more powerful OS-based environments• OS-dependent (e.g., Windows, Linux, Android,WinCE)• Programming-language-dependent (e.g., C,Lua, Java)m_ARy-murti@ieee.org, 6-7 April 2013
  114. 114. Software Interface (3/3)An SDK provides many advantages over the AT command interfacesuch as:• excellent event-notification support;• it encourages the use of standard programing practices;• concurrent access: the single common API can be used by multiple• concurrent access: the single common API can be used by multipleconcurrent applications;• SDKs tend to be more responsive;• binary data support: binary data can be sent natively without firsthex-encoding.• One of the issues with SDKs is that they are currently all proprietarym_ARy-murti@ieee.org, 6-7 April 2013
  115. 115. Cellular Certification• Beyond regulatory certification, which is requiredby all transmitting devices, cellular products alsorequire telecom industry and MNO certification.• very large burden to the module vendors and the• very large burden to the module vendors and theM2M application developers (or integrators).• The industry is continuously trying to minimizeburden by modifying processes and testingprocedures, all the while trying not to affect thequality of interoperability.m_ARy-murti@ieee.org, 6-7 April 2013
  116. 116. Telecom Industry Certification (1/3)• For GSM-based modules, the telecom industrycertification is controlled via two associations,that is, GCF (global certification forum) andPTCRB (PCS terminal certification review board).PTCRB (PCS terminal certification review board).• For CDMA-based modules, a new forum calledthe CDMA certification forum (CCF) has beenestablished.• Telecom industry certification typically requires:m_ARy-murti@ieee.org, 6-7 April 2013
  117. 117. Telecom Industry Certification (2/3)Telecom industry certification typically requires:• testing against some technical specification,such as TS 51.010, using an accreditedlaboratory;laboratory;• field testing, e.g., drive testing;• proof of a quality assurance programme, e.g.,ISO9001.m_ARy-murti@ieee.org, 6-7 April 2013
  118. 118. Telecom Industry Certification (3/3)Even if an integrated module has “module-certification,” the integrator can be expected toperform the following types of tests (dependingon the module form factor and the integratorsimplementation):implementation):• radiated spurious emissions;• measurement of radiated RF power and receiverperformance, e.g., total isotropic sensitivity (TIS)and total radiated power (TRP);• UICC/SIM electrical test cases;• man-machine-interface-related test cases.m_ARy-murti@ieee.org, 6-7 April 2013
  119. 119. MNO Certification• MNO certification is not standardized, so the amountof testing, the test limits, and the test cases varybetween MNOs.• MNO certification is focused on the equipmentdeployed in the MNO network, where the field testingand IOT (interoperability testing) is conducted on theand IOT (interoperability testing) is conducted on theMNOs network and not on test equipment, such asAgilent test equipment.• MNO certification only deals with complete products(not modules) but a module can be precertified, similarto telecom industry certification, to reduce the burdenof testing required by the integrator.m_ARy-murti@ieee.org, 6-7 April 2013
  120. 120. Need To Be Optimizedm_ARy-murti@ieee.org, 6-7 April 2013
  121. 121. Need To Be Optimizedm_ARy-murti@ieee.org, 6-7 April 2013
  122. 122. Challenges for Capillary M2M• Core Challenge #1 – Delays: Connection Delay: optimize L2/L3 node discovery protocols Communication Delay: ultra reliable & time-critical MAC urgently needed• Core Challenge #2 – Security: Requirements: room for efficient end-to-end security solution Extras: fit security into standards, allow for aggregation, etc.Core Challenge #3 – Standards:• Core Challenge #3 – Standards: so far: too many proprietary solutions on market need for: truly standardized embedded architecture• Core Challenge #4 – P2P Traffic: Traffic Pattern: a lot more P2P traffic is emerging than initially thought Protocols: without jeopardizing converge-cast protocols, find solutionm_ARy-murti@ieee.org, 6-7 April 2013
  123. 123. Challenges for Cellular M2M• Core Challenge #1 – Complexity & Power: Modulation: simple to detect in DL; constant envelope in UL Processing: currently total over-kill; get it down by orders of magnitude• Core Challenge #2 – Data Rates: uplink: allow for more UL traffic without disturbing current traffic downlink: mostly query; maybe embed into control plane downlink: mostly query; maybe embed into control plane• Core Challenge #3 – Delays: Connection Delay: e2e delays need to be improved by orders of magnitude Communication Delay: generally solved; however for high rate only• Core Challenge #4 – Architectural Elements: Technical: handling many nodes, group management, HOs, etc, etc. Billing: who and how pays the bill; compete with LAN/WLAN/WSNsm_ARy-murti@ieee.org, 6-7 April 2013
  124. 124. m_ARy-murti@ieee.org, 6-7 April 2013
  125. 125. m_ARy-murti@ieee.org, 6-7 April 2013
  126. 126. m_ARy-murti@ieee.org, 6-7 April 2013
  127. 127. m_ARy-murti@ieee.org, 6-7 April 2013
  128. 128. m_ARy-murti@ieee.org, 6-7 April 2013
  129. 129. m_ARy-murti@ieee.org, 6-7 April 2013
  130. 130. m_ARy-murti@ieee.org, 6-7 April 2013
  131. 131. m_ARy-murti@ieee.org, 6-7 April 2013
  132. 132. m_ARy-murti@ieee.org, 6-7 April 2013
  133. 133. m_ARy-murti@ieee.org, 6-7 April 2013
  134. 134. M2M Companym_ARy-murti@ieee.org, 6-7 April 2013
  135. 135. The EndThe EndThank YouThank You

×