The Vault

Standardized M2M/IoT Services Delivery Platform
White Paper / Feb 2015 / M2M, IoT, SDP

Advances in wireless communications, storage capacity, embedded processing power, and IT technologies have led to inexpensive devices, sensors, and actuators with increased computing power and low power consumption. These advances provide a huge opportunity for growth in M2M/IoT applications. M2M/IoT technologies will benefit a broad range of market segments: smart grid, telematics, eHealth/mHealth, vehicular systems, industrial control, home automation, and environmental monitoring to name a few.

Global standards are defining service layer solutions to accelerate the development and reuse of M2M/IoT data and applications. This white paper illustrates how InterDigital’s Standardized Service Delivery Platform (SDP) allows solution providers to capture the full potential of their M2M/IoT businesses.

We found some problems with the form:
To view this content please fill out the form below to tell us about you.
Privacy Policy
SolutionsWhite Paper Standardized M2M/IoT Service Delivery Platform Published January, 2015 Standardized M2M/IoT Service Delivery Platform | 2 Contents 1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Standard End-to-End Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Scalable Service Delivery Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1 .3 RESTful/Resource Based Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1 .4 3GPP MTC-IWF and M2M Cellualr Inter-Working Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5 SDP Configurable Charging Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6 SDP Device Management Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.7 SDP Semantic Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.8 Automated Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.9 Flexible Service and Application APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1 .10 SDP Web Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1 .11 Open Message Bus (OMB) Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1 .12 Future SMART IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1 .13 Pulling it all together ? A real world use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.14 Summary and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 About InterDigital? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Standardized M2M/IoT Service Delivery Platform | 3 1 Executive Summary Advances in wireless communications, storage capacity, embedded processing power, and IT technologies have led to inexpensive devices, sensors, and actuators with increased computing power and low power consumption. These advances provide a huge opportunity for growth in M2M/IoT applications. M2M/IoT technologies will benefit a broad range of market segments: smart grid, telematics, eHealth/mHealth, vehicular systems, industrial control, home automation, and environmental monitoring to name a few. Global standards are defining service layer solutions to accelerate the development and reuse of M2M/IoT data and applications. This white paper illustrates how InterDigital?s Standardized Service Delivery Platform (SDP) allows solution providers to capture the full potential of their M2M/IoT businesses. InterDigital?s Standardized Machine-to-Machine and Internet of Things Service Delivery Platform (M2M/IoT SDP) conforms to oneM2M Release 1 and ETSI TC M2M Release 1 and Release 2 standards. It provides a standard M2M middleware solution with common Application Programming Interfaces (APIs) for scalable and horizontal M2M/IoT services, featuring: ? Standardized End-to-End (E2E) Solution: Integrates all M2M/IoT entities from Applications, Devices, and Gateways to Servers as an E2E and fully standards-compatible solution. An M2M/IoT Gateway facilitates advanced local proxy and bulk management services for devices behind a Gateway ? Scalable Service Platform: A common architecture, provides scalability, extensibility, and distributability for cloud based deployments, as well as configurations for platforms with limited capabilities such as gateways and low- power, battery-operated M2M/IoT devices ? Service-Oriented Architecture: Service entities for Devices, Gateways, and Servers that enable providers to generate new revenues from M2M/IoT via service platforms. Advanced features include platform-agnostic and smooth binding with HyperText Transfer Protocol (HTTP) and Constrained Application Protocol (CoAP) ? RESTful Architecture: Client/Server-based RESTful interfaces and a hierarchical resource tree, simplify and optimize resource manipulations and enable quick and efficient application development for a broad range of devices, especially constrained M2M/IoT Devices ? Efficient Interworking with Cellular MTC: Seamless integration of InterDigital?s Network Service Entity and cellular Machine Type Communications (MTC) functionality ? Configurable Charging: Allows for policy-based configurable trigger functions, record storing to correlate charging records from multiple entities (i.e. cellular and M2M/IoT service platforms), and both offline and online charging ? Interworking Proxy Capable: Can support custom developed interworking proxy modules to facilitate connections to existing or legacy service platforms and devices ? Lightweight M2M: Supports the emerging OMA standard for M2M/IoT device management ? Cognitive Semantic Services: Supports cognitive, non-opaque data management including mining and analytics to enable semantic data services at the M2M/IoT service layer ? Automated Service Discovery: Significantly reduces management costs and automates the deployment process by removing human involvement and offline provisioning ? M2M Cloud Server Development Platform: Cloud-based platform supports virtualized and configurable M2M Server, which can be a private or public cloud ? Web-based M2M/IoT SDP Portal: Supports automated, on-demand SDP generation for different M2M/IoT platforms and facilitates M2M/IoT application development ? Flexible Service Entities and Application APIs: Supports modular design and allows for use of different application protocols (CoAP, HTTP, etc) and different implementations without rework: Standardized M2M/IoT Service Delivery Platform | 4 ? Service Entity Software Platform: Available in binary packages for M2M/IoT Devices, Gateways, and Servers ? M2M/IoT API ? M2M/IoT sample applications ? IoT Feature Support: Supports advanced features that facilitate the evolution to the Internet-of-Things including data analytics, identity management, event management, and service negotiation. Further Information as well as access to InterDigital?s Service Delivery Platform is available on our web portal at: 1.1 Standard End-to-End Solution The End-to-End IP-based architecture provides a complete solution, including M2M Devices, M2M Gateway, M2M Server, and M2M Application APIs. The M2M Server ? the primary component of a provider?s platform ? offers service entities to third- party application providers via the M2M Application APIs, which facilitates application development and interoperability. The M2M Gateway provides hierarchical integration of M2M service entities, allowing the functionality to reside closer to the edge of the network and closer to the entities requiring the services. The M2M Gateway also enables optimization of both network signaling and data storage, by, for example, aggregating traffic from many devices. Figure 1: Standard End-to-End Solution Source: InterDigital IP Network Cellular Core Network Healthcare Vehicular Energy Connected Home Standard APIs, Access, Security & Device Management Features Standardized APIs to Diverse Ver?cals Standardized APIs for Diverse Devices M2M Devices Cellular, WLAN, WPAN (Zigbee, 6LoWPAN, Bluetooth), Wireline M2M Gateway Enables cellular & non-cellular M2M devices to communicate through operator networks. Provides localized Service Capabili?es to o?oad network M2M Server Service Provider?s M2M Service Pla?orm, offering Service Capabili?es to Diverse M2M Ver?cals (Device/Data Access, Device Managment, Security, Billing, Service Discovery, etc.) Standardized M2M/IoT Service Delivery Platform | 5 1.2 Scalable Service Delivery Platform The Scalable M2M/IoT Service Delivery Platform conforms to oneM2M Release 1 and ETSI TC M2M Release 1 and Release 2 standards. It supports Service Entities at M2M Devices, M2M Gateways, and M2M Servers. It also supports all reference points defined by the standards. The Service Delivery Platform is integrated with Service Entity to Service Entity interaction capabilities, which, as a unique feature, enables Device-to-Device, Gateway-to-Gateway and Server-to-Server direct communications and in turn significantly improves system reliability, scalability, and overall performance. The InterDigital M2M/IoT Service Delivery Platform can be configured to support a variety of different deployments and platforms. The Service Layer can be scaled down to a limited footprint for compatibility with devices or gateways with limited processing resources. At the other end of the spectrum, the architecture supports cloud deployments of the network service layer allowing distributed processing of the service entity functions. RESTFUL APPLICATION API CONFIGURABLE CHARGING INTERWORKING WITH CELLULAR MTC CAPILLARY NETWORK INTEGRATION (ZIGBEE) M2M GATEWAY PROXY NEGOTIATION SERVICE SEMANTIC SERVICES SERVICE DISCOVERY DEVICE / EVENT MANAGEMENT CLOUD-BASED M2M / IOT SERVER SCs WiFi802.15.4 802.15.4 M2M / IoT GW 3GPP / LTE M2M Area Networks (Home Automa?on) Heterogeneous Access Networks (Wireless/Wireline) M2M / IoT Server M2M / IoT Applica?on DM Server Mca/mla Mcc/mld Mca/dla M2M / IoT-to-Ver?cal M2M Area Networks (Smart Metering) ZigBee 6LoWPAN M2M / IoT Device Domain M2M / IoT Network Domain Communica?on Networks M2M / IoT Core Networks M2M / IoT Device M2M Device/GW Applica?ons Communica?on Protocols Service Capabili?es Resource Tree M2M / IoT Device / GW Communica?on Protocols Service Capabili?es Resource Tree M2M / IoT Server M2M / IoT Server M2M / IoT Server SCs SCsSCs SCs SCs DA DA DA DA DA SCs MAS ServerDNS Server DNS: Domain Name System MAS: M2M Authen?ca?on System DM: Device Management Figure 2: Scalable M2M/IoT Service Delivery Platform Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 6 Figure 3 Scaling to Support Diverse Deployments Source: InterDigital Non- Resource Constrained IoT Applica ons Scaled Up Cloud-Based IoT Service Layer Deploment Scaled Up API Messaging Scaled Down API Messaging Resource Constrained IoT Devices Scaled Down Gateway IoT Service Layer Deployment Standardized M2M/IoT Service Delivery Platform | 7 1.3 RESTful/Resource Based Interfaces ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? ?a?ribute? group group group subscrip?on subscrip?on subscrip?on subscrip?on subscrip?on subscrip?on subscrip?on subscrip?on subscrip?on subscrip?on container container container scls applica?ons accessRights discovery subcontainers containerInstances subscrip?on subcontainers latest oldest members membersContent accessRights no?fica?onChannels mgmtObjs mgmtObjs accessRights applica?ons no?fica?onChannels m2mPocs a?achedDevices sclAnncs mgmtObjs InterDigital?s M2M/IoT SDP RESTful interfaces are based on a hierarchical resource tree and standard resource manipulation methods, including: CREATE/RETRIEVE/UPDATE/DELETE (i.e. CRUD). It provides the following advantages: ? RESTful interfaces are stateless, based on Client/Server model and provide uniform interfaces ? Clients initiate requests to servers. Servers process requests and return responses ? Requests and responses are built around the transfer of representations of resources. Resource are stored at the Server ? Each resource can have ?unique address,? ?attributes,? and ?sub-resources? ? Each resource can be manipulated by Create/Retrieve/Update/Delete (CRUD) methods as well as Subscription Figure 4: Hierarchical Resource Tree (oneM2M and ETSI M2M) Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 8 1.4 3GPP MTC-IWF and M2M Cellular Inter-Working Service In Release 11, 3GPP added the MTC-IWF to the LTE Evolved Packet Core. The MTC-IWF allows an M2M Server to send ?triggers? to M2M devices. A trigger is a short message from the M2M Server to the device that instructs it to take some action, such as register with the M2M Server. InterDigital?s M2M/IoT SDP supports an MTC-IWF which provides a 3GPP Release 11 compliant Tsp interface to M2M Servers. The Tsp interface is based on the Diameter protocol and is used by M2M Servers to make trigger requests. In Release 11, triggers are transported to M2M LTE devices via SMS. InterDigital has enhanced the MTC-IWF and PDN-GW to allow the network to send triggers to M2M devices over the devices? IP bearers. This approach allows the M2M Server to trigger any application that is running on an LTE device and listening on a UDP port for its trigger. In Release 12, 3GPP created a new ?Power Saving Mode? for M2M devices. This allows M2M devices to transition into a sleep-like state where they can conserve power, thus lengthening battery life. While devices are operating in power saving mode, they do not listen to the network and cannot receive data from the M2M Server. Complications can arise if the M2M Device and M2M Server do not properly coordinate when the device should use power saving mode. For example, data packets from the M2M Server may be discarded while the M2M device sleeps; possibly leading to increased retransmissions and core network load . InterDigital has enhanced the MTC-IWF and MME to allow M2M Servers and M2M Devices to easily coordinate the use of Power Savings Mode. New commands have been added to the Tsp interface that allow the M2M Server to configure the M2M Device?s Power Savings Mode and to receive notifications when the M2M device enters and exits Power Savings Mode. InterDigital?s M2M Server includes a oneM2M compliant service that provides applications and services with an API that can be used to access the LTE Evolved Packet Core. Applications and services can use the API to request triggers, configure a device?s Power Savings Mode, subscribe to notifications about device?s state, and receive notifications about changes in the device?s state. LTE Evolved Packet Core LTE RAN eNodeB M2M System M2M Server Applica?on Servers S-GW PDN-GW SGi Tsp MTC-IWF HSS MME one M2M Services Seman?cs 3GPP Inter-Working Data Base Services Discovery CoAP or HTTP IP one M2M Services Seman?cs 3GPP Inter-Working Data Base Services Discovery CoAP or HTTP IP M2M Applica?ons Cellular M2M Devices Figure 5: Inter-Working the LTE Evolved Packet Core with the M2M System Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 9 1.5 SDP Configurable Charging Service Figure 6 shows a configurable charging service supported by InterDigital?s M2M/IoT SDP . The M2M Server can configure policies to collect statistics for events to be used for charging or other system monitoring purposes. The M2M Server can also provide ?charging as a service? via standardized APIs to applications registered to the Server. Different events can be supported by utilizing the policies to trigger the generation of chargeable events. The M2M Server can collect statistics for its own use, or collect statistics for applications using the charging service. The M2M Server can choose to configure charging policies for nodes at the field domain, such as gateways and devices. The M2M Server can pass the generated records to the billing domain for charging and accounting operations. With a configurable charging architecture, the M2M Server can access charging records generated within 3GPP networks via the Tsp reference point. In addition, charging functions within a 3GPP network can access and leverage charging records generated within the service layer. Both offline and online charging are supported. Standardized charging functions and protocols used by 3GPP networks are supported . Underlying Network Charging System (3GPP Core Network) Applica?ons Services M2M Server Configurable Charging Service Charging Policy #1 Charging Policy #n Chargeable Events Chargeable Events Reference Point (Tsp) Reference Point Reference Point to Field Domain Reference Point to Billing Domain Figure 6: Configurable Charging Service Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 10 1.6 SDP Device Management Service DM Client DM Client DM Server Interface to DM Server MgmtObjs Management Adapter LW DM Server DM Gateway Management Adapter Management Adapter MN-CSE DMG IN-CSE DMG Mca ASN-CSE DMG Mca Mca Mca Mcc Msc M2M Device (oneM2M Applica?on Service Node) M2M Device (oneM2M Applica?on Dedicated Node) Non M2M Device M2M Server (oneM2M Infrastructure Node) M2M Device (oneM2M Applica?on Dedicated Node) M2M Device (oneM2M Applica?on Dedicated Node) M2M Gateway (oneM2M Middle Node) (NoDN) ADN-AE ADN-AE ADN-AE DM Server oneM2M interface oneM2M-DM interface oneM2M en?ty oneM2M CSF DM en?ty DM interface (OMA DM, LWM2M, BBF TR-069, etc.) DM Client LW DM Client MN-AE IN-AE DM Client DM Client ASN-AE Device Management (DM) facilitates firmware/software management, fault management, configuration and performance management for M2M Devices. This includes constrained M2M Devices and M2M Area Networks, and the M2M Gateway is a highly efficient way to manage constrained M2M Devices behind it. The DM features help operators and customers deploy massive numbers of M2M Devices and diagnose and fix problems quickly with greatly reduced management cost. Figure 7 shows the overall device management architecture within InterDigital?s M2M/IoT SDP in which various device management standards can be supported. The architecture allows for performing device management on all types of devices from the latest smartphone to sensor devices with limited resources. The platform can support a device management server residing within the SDP or externally as a remote server. In addition, the platform can support a variety of management systems, such as OMA DM, OMA LWM2M, and BBF CWMP (TR-069). A management adapter is used to translate oneM2M messages to DM messages and from DM messages to oneM2M messages. oneM2M has defined resource mappings between oneM2M resources and the underlying management system resources that offer near seamless integration between the systems. Another benefit of InterDigital?s platform is the added flexibility of the platform providing a common interface to access device management capabilities. The same application can be used to manage devices behind a gateway (e.g., in a home environment) and devices that connect to a cloud server. Devices can be managed at the network or gateway levels and management servers can exist in both levels. For example, an LWM2M Server can be hosted in both the M2M Server and the M2M Gateway to manage LWM2M devices which have cellular or WiFi only capabilities, respectively. This allows the same application to manage both types of devices at the gateway or network levels. Figure 7: Device Management Support within M2M/IoT SDP Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 11 1.7 SDP Semantic Service InterDigital?s M2M/IoT SDP supports semantic services and semantic awareness, so that data flowing through or stored within the SDP is not limited to opaque information. Examples of semantic services of the SDP include the capability to affiliate semantics with resources stored within the service layer as well as the capability to perform semantic querying of these resources. Figure 8 shows the functional architectural of InterDigital?s M2M/IoT SDP semantic service. The major components are: ? Resource Repository stores all resources that are collected from the physical M2M devices and any resources that are relevant to the M2M applications, such as person, devices, etc. involved in the M2M applications. The Resource Repository also allows semantic descriptions to be associated/linked with resources. ? Ontology Processor is in charge of processing, classifying, storing and providing a discovery function of published/ generated ontologies external and internal to the SDP . ? Ontology Repository stores the ontologies. Those ontologies can be used to enable semantics for resources. ? Semantics Repository stores the annotated semantics information, which may have the option of utilizing the Resource Description Framework (RDF). Semantics annotation is a processs of representing a resource?s semantics in a concrete format, such as a binary stream. ? Rule Repository stores the rules that are used to represent new knowledge that often goes beyond the existing semantics that is associated with the resources in the Resource Repository. Rules are typically conditional statements: if-then clauses . ? Reasoner takes input from the Rule Repository and the existing resource semantics information in the Semantics Repository, and generates new resource semantics information if the conditions in the rules are satisfied. New resource semantics information is added to the Semantics Repository. ? Semantic Query Processor handles the queries from clients to search over the resource semantics information stored in the Semantics Repository and returns the results to the clients. Client Seman?c Service Seman?c Query Processor Reasoner Rule Repository Ontology Processor Rule Publisher Ontology Publisher, Requester M2M Devices, other en??es involved in M2M applica?ons Seman?cs Repository Ontology Repository Resource Repository Figure 8 Functional Architecture of M2M Semantic Support Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 12 1.8 Automated Service Discovery Automated Service Discovery allows M2M Service Entities to be dynamically discovered, which is critical for M2M type devices that may have little or no human interaction. It supports: ? A light-weight automated service discovery procedure based on a well-known resource. This is excellent for situations where the network address of the M2M Server, Gateway, or Device to be targeted by the service discovery procedure is known in advance; ? An advanced procedure based on the definition of a new M2M Service Discovery Function (MSDF) which leverages the underlying concepts of the DNS-SD protocol to find available service entities. DA DA SCs SCs WiFi802.15.4 802.15.4 M2M / IoT GW M2M Area Networks (Home Automa?on) Heterogeneous Access Networks (Wireless/Wireline) M2M / IoT Server M2M / IoT Applica?on M2M Service Discovery Server (DNS/DNS-SD) M2M/IoT Server Service Discovery Info M2M Service Discovery M2M Area Networks (Smart Metering) ZigBee 6LoWPAN Communica?on Networks M2M / IoT Core Networks Figure 9: Service Discovery Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 13 1.9 Flexible Service and Application APIs The M2M API is designed to work with ETSI M2M and oneM2M RESTful architectures by providing a uniform interface. The API supports customization of transport layer implementations such as CoAP and HTTP and payload formatting libraries such as XML and JSON to facilitate reuse of preferred libraries. The M2M Service layers use primitives, defined by standards, which are converted to objects ready to use in an application. The API supports all standards defined primitives as well as customization of primitives to support prototyping and value added feature sets. The size of the API can be optimized to reduce the footprint for a final product, as would be required by a constrained device. API logic (within library) Core Applica on Fun onality Applica on Opera ons with API Fun ons/Methods 1) Specify object parameters 2) Specify opera on (CRUD) Synchronous and non- synchronous calls supported 11) Response available 3) Create spec compliant primi ve 4) Bind primi ve to transport layer (HTTP, CoAP, etc) 5) Bind payload format (XML, JSON, etc) 6) Send spec compliant primi ve 7) Receive spec compliant primi ve 8) Extract transport layer header fields 9) Decode Payload 10) Update object parameter from response primi ve Customizable to use any 3rd party implementa ons for the transport layer and payload binding func ons Figure 10: Flexible Application API Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 14 1.10 SDP Web Portal InterDigital?s M2M/IoT SDP Portal facilitates the use of the M2M/IoT SDP and the development of M2M applications to use with it. The portal provides users with access to the following: ? Documentation ? Software Development Kits (SDKs) ? Testing & Integration Tools ? Build Tool for creating customized SDP executables ? Tutorials, FAQs, and Forums Figure 11: SDP Web Portal Home Screen Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 15 The documentation available on the portal includes documents describing the M2M API, the use of InterDigital?s Virtual M2M Server, and documents describing how to use the custom testing and integration tools that are available for download on the site. A number of Software Development Kits (SDKs) are available on the site which provide the user with sample applications that are compatible with the SDP and the needed API libraries bundled with project files for the most popular development environments including Eclipse and Microsoft Visual Studio. Additionally, the sample applications and the API libraries are available in C and Java languages. These SDKs allow users to quickly download and begin running M2M/IoT applications with the SDP . InterDigital has developed a number of customized testing and integration tools that are available on the portal. These tools allow the user to gain insight into the operation of the SDP with the applications by providing visibility into the resource structure and messaging of the SDP. The most compelling feature of the portal is the Build Tool which allows users to create and download their own customized build of the SDP. In this way, it satisfies different user requirements and enables automated on-demand SDP generation and customization. It allows users to customize builds features based on: ? SDP Compliance ? Operating System ? Node Type ? Database Type ? Runtime Environment ? Deployment The build process is reflected in Figure 12 . InterDigital?s M2M/IoT SDP New SDP Configura?on Request New SDP Created Submit SDP Requirement Return Customized SDP Submit SDP Requirement Return Customized SDP User 1 User 2 Web Interface Figure 12 SDP Build Tool Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 16 Taken together, the SDKs, customized SDP, and the supporting tools and documentation allows users to quickly begin evaluating the SDP as well as facilitate the development of compatible M2M/IoT applications. Please note, access to the portal requires the establishment of a Non-Disclosure Agreement (NDA) with InterDigital for access to the documents and an Evaluation Agreement (EA) for access to the complete site including the SDP executables, API libraries, and utilities. 1.11 Open Message Bus (OMB) Architecture The InterDigital IoT Service Platform is built upon the Open Message Bus (OMB) architecture. The OMB provides a flexible and scalable architecture that enables different types of services to interconnect and interoperate with one another in a seamless and generic manner. In this way, oneM2M, ETSI M2M, and third party/advanced services can interface to one another over the OMB. The architecture can be scaled based on the desired deployment so that it can support cloud based services all the way down to device based services. The OMB backbone supports a set of native services which include an OMB Database Service, an OMB Service Directory, and an OMB Administration Console. These native services provide services to those entities connecting to the OMB. All services interface to the OMB via OMB clients which provide a layer of abstraction between the services and the underlying transport. VIRTUAL SERVER Discovery Data Collec?on Service Discovery Device Mgmt Security 3rd Party Services Search Analy?cs Reference Applica?ons Message Bus VA LU E- AD DE D S ER VIC ES STANDARDS BASED SERVICES API s to Da tab as es APIs to Applica?ons Cloud OS (OpenStack) + Virtualiza on Components Pooled Hardware, e.g. Rackspace Analy cs Data Handling Policy Provisioning CRM ERP SecurityDatabase Supply Chain Management Billing/ Clearinghouse VERTICAL/ENTERPRISE SYSTEMS APPLICATIONS Figure 13 Open Message Bus (OMB) Architecture Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 17 1.12 Future SMART IoT Current M2M solutions are focused on communications (i.e. how information is transmitted from one machine to another). Evolution will effectively integrate ?connectivity? and ?content? with ?context,? ?collaboration,? ?cloud,? and ?cognition.? The future Internet of Things will be a global network of interconnected objects, enabling object identification/discovery and semantic data processing via C6 capabilities consisting of ? Connectivity: connection for mobile and constrained objects; ? Content: massive data produced from things; ? Cloud: cloud service and cloud content storage; ? Context: context-aware design to improve performance; ? Collaboration: cooperative communications, inter-things, service sharing; ? Cognition: mine the knowledge from massive data and provide autonomous system adjustment for improvements. In the proposed C6-based IoT model, each C6 capability is not independent of each other rather they interact with each other to enable joint optimization. Such interactions involve various information exchange among these C6 capabilities as illustrated in Figure 14 to enable future SMART IoT system with features such as Scalability, Manageability, Adaptability, Reliability, and Trustworthiness (SMART) . Context Capability COGNITION CAPABILITY Cx CAPABILITY Context Capability Connec?vity Capability Collabora?on Capability (Content, Context, Connec?vity, Cloud Or Collabora?on) databasedatabase Cloud Capability Access informa?on at Cx capability (e.g.,context or capability) Push policies/decisions related to Cx capability Retrieve/report policies, decisions and/or seman?c informa?on related to Cx capability Collabora?ve Content Management Content-aware Collabora?onCo llabo ra?v e Co ntex t Ma nage men t Con text -aw are Coll abo ra?o n Context-aware Content Management Con text - awa re Con nec ?vit y Cloud-based Connec?vity Cloud-based Context Mgmt. Context-aware Cloud Mgmt. Cl ou d- ba se d Co nt en t M gm t. Co nt en t-a wa re Cl ou d M gm t. Content-aware Connec?vity Collabora?ve Cloud Co lla bo ra ?v e Co nn ec ?v ity Inquiry, trigger and/or leverage func?ons at Cx capability Inquiry, trigger and/or leverage Cogni?on func?on Figure 14 Interactions among C6 Capabilities Source: InterDigital Standardized M2M/IoT Service Delivery Platform | 18 Figure 15 illustrated the proposed C6-based SMART IoT architecture, where physical domain, cyber domain, and social domain together form the end-to-end system. Each domain has different IoT entities (e.g. things, devices, gateways, routers, servers, users, etc). Physical domain consists of different IoT things and/or devices which generate raw data; cyber domain consists of IoT network infrastructure and IoT services to collect raw data, process raw data, and provide corresponding services; social domain is about how IoT data and services will be leveraged or manipulated by users where social relations among users may impact how IoT data and services flow among users. C6 capability can reside in different entities in different domains. Figure 15 Future Vision of Internet of Things Source: InterDigital Diverse Ver?cal Applica?ons End-toEnd IoT System RFID Reader Smart Phone Gateway Gateway Wireless Access Networks Fixed Access Networks Core Networks Services and Applica?ons Processed Data RFID Networks (e.g. supply chain management) Wireless Sensor Networks (e.g. environment monitoring) Body Area Networks (e.g. eHealth/mHealth) Vehicular Networks (e.g. smart transporta?on) (e.g. xDSL, Cable, Fiber, etc.) (e.g.GSM, WiFi, 3G/4G, Satellite, etc.) (So?ware-Defined Networks,Content-Centric Networks, etc) Cached Data Raw Data C6 C6 C6 C6 C6 C6 C6 C6 C6 C6 C6 C6 C6 Th in g/ O bj ec t D om ai n (P hy si ca l o r Vi rt ua l) Physical: Thing Domain Physical: Device Domain (Generate Data) Cyber: Network Domain (Collect Data) Cyber: Service Domain (Manage Data) Social: User Domain (Access Data) Servers in the Cloud Providing Various Services Standardized M2M/IoT Service Delivery Platform | 19 1.13 Pulling it all together ? A real world use case To this point, we have been discussing the capabilities and features of the InterDigital Service Delivery Platform and how it facilitates a variety of M2M/IoT applications and vertical markets. In this section we present a use case of how Interdigital?s SDP and its advanced features can be leveraged to improve peoples lives even in their most routine activities. We will describe how the IoT and InterDigital?s SDP can be a integral part of everyday life using a visit to the local gym to workout. For purposes of this use case, we will stipulate the following: ? The user has a smartphone running InterDigital?s SDP and a compatible gym application ? The user has a smartwatch that allows monitoring of his/her vital signs (heart rate and blood pressure) and connects to an application on the users smartphone ? The gym is equipped with WiFi network allowing access to a M2M Gateway running InterDigital?s SDP which is also hosted in the gym?s network ? The gym equipment is WiFi enabled so that it can communicate with the M2M Gateway and other systems on the network The configuration of this use case is shown in Figure 16 . Figure 16 A Visit to the Gym Use Case Source: InterDigital M2M /loT GW Features: ? Service Discovery & Iden?ty Management Server ? Nego?a?on Services ? Seman?c Services SmartPhone Features: ? Device Service ? Gym Applica?on (DA) ? Device Management Client ? Watch Interface Applica?on M2M Service Discovery Server (DNS/DNS-SD) Communica?on Networks Heterogeneous Access Networks (Wireless/Wireline) M2M / IoT Core Networks SCs M2M / IoT Server DM Server Health Insurance Network Applica?on (NA) App Store Network Applica?on (NA) SCs SCs WiFi Bluetooth DA DA 10: 35 Jul 23 Treadmill Features: ? Treadmill Applica?on (DA) Standardized M2M/IoT Service Delivery Platform | 20 This use case leverages a number of the features highlighted in this document as well as some additional features that are also supported by the SDP. At a high level, the use case plays out as follows: 1 . The use case starts by a user arriving at the gym with his M2M capable smart phone and smart watch 2 . Upon entering the gym, the user?s phone automatically discovers the Gym?s network and registers to use its value-added M2M services 3 . Next, the Gym?s M2M services push a list of available gym equipment to a Gym app running on the user?s phone 4 . In addition, a list of suggested apps that the user may be interested in is also pushed to the Gym app on the user?s phone 5 . From this list, the user selects an app that allows him to upload workout information to his health insurance provider in order to receive a discount on his future premiums. The app is automatically downloaded to the user?s phone 6 . 6) Next, the user selects an available treadmill using his Gym app and with a single push of a button on his smart watch, configures the treadmill with his workout preferences 7 . During his workout, the rate of vital statistics reported by his watch to the treadmill is dynamically negotiated to conserve the watch?s battery while still maintaining the minimum update rate required by the treadmill 8 . Throughout his workout the user?s heart rate is monitored and used to automatically adjust the speed of his treadmill to ensure the user has an optimal workout 9 . At the completion of his workout, the user?s workout data is uploaded to his health insurance provider so he can receive his discount To explore some of the operations in greater detail we highlight some of the key features being exploited by this use case in the follow paragraphs . Feature: Sevice Discovery and Identify Management 1) M2M Server publishes service discovery record to service discovery server 2) GW and Device (smartphone Service Capabilites (SC)) query service discovery server to discover M2M Server (i.e. its base URI) and then register to it 3) In advance, the Gym has set up a service discovery and identity provisioning server and provisions it with a pool of identifiers 4) GW publishes service discovery record to service directory in the discovery server (co-located with the GW) 5) Device queries service directory (co-located with the GW) to discover the GW and to also request an identity and credentials 6) Device registers to GW using provisioned identity 7) GW validates Device has a valid identity before allowing it to register Standardized M2M/IoT Service Delivery Platform | 21 Feature: Device Management 1) App Store Network Application (NA) uploads Apps from its store to Device Management (DM) Server (note that this is done ahead of time using a proprietary procedure/mechanism) 2) App Store NA creates containers in M2M Server to store info about it apps and also subscribes to these containers to receive app download requests 3) Gym Device Application (DA) requests download of Watch DA and/or Health Insurance DA by creating contentInstance with its contact info in M2M Server 4) App Store NA gets notification from M2M Server and retrieves contact info of phone (from contentInstance or data entry) 5) App Store NA creates a management object resource with phone?s contact info 6) M2M Server communicates a SW update to the DM Server via the web services interface 7) DM Server sends commands to DM client running on phone to install new app on phone Feature: Semantics 1) Semantic descriptions are created on M2M Server. Semantic descriptions for this use case include English and Metric descriptions for speed and weight 2) Watch configures a ?semantics? attribute in weight and speed container resources with URI linking to seman tic description on M2M Server for English units 3) Treadmill fetches semantic description from M2M Server using URI in semantics attribute and uses it to display weight and speed in English units 4) User decides to switch watch to Metric units. Watch updates semantics attribute with URI pointing to semantic descriptions on M2M Server having Metric units 5) Treadmill fetches semantic description from M2M Server using URI in semantics attribute and uses it to display weight and speed in Metric units Feature: Negotiation 1) Treadmill App creates negotiation policy in GW to define upper and lower bounds of rate of incoming heart rate updates 2) Watch App creates negotiation policy in GW to define upper and lower bounds of rate of outgoing heart rate updates 3) Watch App starts GW-based negotiation between watch and treadmill to select the rate of heart rate updates per minute 4) GW performs negotiation on behalf of watch and treadmill to compute a heart rate update request rate that is agreeable to both treadmill and watch 5) Based on watch?s battery level, watch re-negotiates The use case described above is only one example of how InterDigital?s standards based Service Delivery Platform can facilitate integration of differnet M2M/IoT devices and applications to benefit the user. These same features and capabilities can be applied to use cases including home automation, telematics, smart grid, etc. Standardized M2M/IoT Service Delivery Platform | 22 1.14 Summary and Conclusion Global standards such as oneM2M and ETSI TC M2M accelerate the development and re-use of service solutions. InterDigital?s standards-compliant M2M/IoT Service Delivery Platform provides a scalable IP-based End-to-End horizontal solution, enabling: ? Application developers to develop their M2M/IoT applications more quickly and efficiently; ? Service operators to smoothly integrate different M2M applications and manage the whole M2M system with greatly reduced cost (CAPEX and OPEX); ? Device vendors to expand and improve their M2M/IoT products with value-added features and interoperability with different devices . Beyond compliance with the global standards, InterDigital?s Service Delivery Platform also supports advanced and value added services that are critical for the emergence of the Internet of Things (IoT). InterDigital is focused on supporting the entire eco-system by providing advanced wireless technologies for emerging M2M markets and the Internet of Things. Figure 17 ?Best of Both Worlds? - Standards Alignment and Value-Added Services Source: InterDigital GROCERY APP CAR CHARGING APP ENERGY MANAGEMENT APP MARKET RESEARCH/SEARCH APP APPLIANCE TEST/ TROUBLESHOOT/ UPGRADE APP ZapMyCar.iotiStockIt.iot DataFetch.iot GadgetDetec ve.iot PowerAid.iot Smart Meters Interac?ons between Diverse Devices and Applica?ons- Tradi?onally Silo-ed in Different Ver?cals, but Now Fully Interconnected Discovery Loca on Big/Small Data Analy cs Search Complex Event Management VALUE ADDED SERVICES Security M2MGateway Context Mgmt Data Collec on Device Management Event Mgmt Seman c Data Model Analy cs Billing Data Adapta on,Aggrega on Op mized Connec vity and Transport Raw APIs, Web Service Interfaces Device/Service Discovery Addressing &Iden fica on APPLICATION ENABLEMENT PLATFORM IoT SERVICE PLATFORM Standardized M2M/IoT Service Delivery Platform | 23 Please visit for more information on InterDigital?s M2M/IoT Services Delivery Platform solutions. The site includes presentations and videos of recent events, access to the SDP Web Portal, and other important information about our M2M/IoT solutions. About InterDigital? InterDigital develops fundamental wireless technologies that are at the core of mobile devices, networks, and services worldwide. As a long-standing contributor to the evolution of the wireless industry, we solve many of the industry?s most critical and complex technical challenges years ahead of market deployment. Our advanced solutions support more efficient wireless networks, a richer multimedia experience, and new mobile broadband capabilities. Accordingly, we have established licenses and strategic relationships with many of the world?s leading wireless companies. InterDigital, Inc . 200 Bellevue Parkway, Suite 300 Wilmington, DE 19806 ? InterDigital, Inc. 2015. All rights reserved. This work was prepared and contains information supplied by, InterDigital, Inc. and/or its affiliates (hereinafter, ?InterDigital?). All information, including performance information, contained herein is provided on an AS IS basis without any warranty as to its accuracy or results. InterDigital expressly disclaims any and all liability for any errors or omissions. InterDigital reserves the right to modify this work and the information contained herein without notice. No part of this work may be reproduced, in whole or in part, except as authorized in writing by InterDigital, irrespective of the type of media in which the information may be embodied. ?InterDigital? is a registered trademark of InterDigital, Inc. WP_201501_005Published January, 2015