Dennis Ward, Internet of Things analyst for ACG Research, has twenty-six years of experience in the datacom and telecom industries. He has participated in the design, implementation, interoperability testing and QA Analysis of many device and system protocols. Prior to joining ACG Mr. Ward has held various technical and management consulting positions in the USA and abroad. He has provided services to leading companies as Metaswitch Networks, Cisco Systems, Adaptive, NET, Sun Microsystems, Mitsubishi, CableLabs, Microsoft and Siemens. As an entrepreneur, he co-founded iThinkTest, Inc., a Test Engineering and Consulting firm. This firm successfully designed and implemented a suite of comprehensive protocol analyzers for the IP Communications, IMS and Packetcable networks.
Dennis joined as a guest blogger for the Cisco Service Provider Communities (www.cisco.com/go/serviceprovidercommunity) May 2014.
Internet of Things, Mobility
Dennis Ward, Internet of Things analyst for ACG Research, has twenty-six years of experience in the datacom and telecom industries. He has participated in the design, implementation, interoperability testing and QA Analysis of many device and system protocols. Prior to joining ACG Mr. Ward has held various technical and management consulting positions in the USA
Equipment Providers (EP) realize that they need to truly develop horizontal platforms: The trend is for EPs to have open Internet of Things (IoT) platforms such that Application Programmable Interfaces and services are available to developers from all disciplines. In this way, developers from all verticals can add value to the platform via creating rich applications and services that serve their target customer base. The developer and the platform provider can revenue share the results. Depending on the value, the platform provider can give incentives to the developers or even acquire the firm. EPs found they needed to look within: To hone in on their IoT offerings EPs found that they need to look within their own customer base to find clues to target the right offerings and service centric use cases to deploy; in doing this, they also are able to understand and equip their internal ecosystem better. As a result, they will be able to influence potential service providers (SPs) to partner with them. Once accomplished they can be agile enough to steer their ecosystem communities to serve the SPs’ needs. EPs need to think total end-to-end solutions: SPs realize that to get the most value from the markets they serve they must serve the customer’s entire needs not just simple point-to-point connectivity. Thus, EPs that partner with SPs must anticipate this and backfill their ecosystems to accommodate the end-to-end solutions needed. So tight communications between EP and SP management, staff and business support systems/operational support systems processes is needed. EPs realize that they need subscriber-based billing models to compete: EPs platforms must have a subscription-based billing model to accommodate the hybrid business models (digital and physical) and freemium to micropayment models characterized by the IoT economy. These subscriber models should include big data analytics modules as value-added products to sell to customers. This addition also makes their offerings attractive to prospective SP partners/large enterprises that are thinking about rolling out value-added services to their end users. EPs need to think complete solutions, services, security and outcomes: EPs are realizing that they need to embrace the fact that complete IoT solutions are service centric. Consequently, they have to think digital services first before selling physical appliances. These appliances may include the virtual components such as security elements, functional and analytics applications or even bare metal components to round out the offering. Therefore, they need to be prepared to offer pieces of the solution as well, but with an emphasis on outcomes that enable the customer to make actionable decisions.
... View more
Service Providers are realizing that do-it-yourself horizontal IoT platform solutions are hard to implement and manage. To truly reach the full potential of serving their mulitvertical customer base, Service Providers are partnering with IoT Platform Service Providers to get into the market with plans to own “pieces” of the solution for themselves. For example, AT&T partners with PTC to leverage its IoT development platform API, etc., to address the cross-vertical market but owns a big data solution, M2X, because of the high-value proposition of managing the data. (This is where equipment providers can really add value within the Service Provider 's ecosystem.) Service Providers are realizing the end-to-end solutions are more lucrative than point-to-point solutions. In providing more than just access connectivity Service Providers are seeing up to 10x return on connectivity by offering the end-to-end solution. This includes backend big data/analytics along with full managed services down to the access device (for example, fog solutions where the analytics can occur at the edge and fed back to the core). Service Providers realize that IoT return on connectivity (ROC) is not immediate. On average, Service Providers are estimating it takes about three years to see ROC. This time to ROC factors in the setup, trial period, and actual deployment phases. Confidence in Service Provider security is still the number one inhibitor for large enterprises. Enterprises are still worried about allowing Service Providers to manage their data. This concern is more prevalent with mission critical/life dependent enterprises such as hospitals and the military. This is ironic since Service Providers NEED to gain these customers to realize their true value in the IoT ecosystem. If equipment providers can provide a perception of a secure IoT platform infrastructure, in addition to educating the enterprise as to how to discern between sensitive and dark data (useless), then they can add great value to their Service Provider offerings. Service Providers are realizing their marketing, selling and billing strategies need to be subscription oriented. IoT is essentially a business process because the access devices are actually physical and digital in nature. As such, digital finances, such as Google micropayments, etc., which fit the IoT usage profile, can be real valuable to customers, ranging from retail to big enterprise. Service Providers see that they need to change their BSS systems to fit the new subscription models that IoT requires. In fact, Service Providers are realizing that the business needs to come first before the “things.” Adding “things” is now becoming a business process that must be linked directly into the BSS infrastructure. A new term coined by Devicify as “Connected Product Management” is now becoming a real to consideration.
... View more
Recently, I listened in on an IEEE Standards Association (IEEE-SA) sponsored round-table at the RSA Conference in San Francisco on April 22, 2015. Karen McCabe, IEEE-SA senior director, Technology Policy and International Affairs, lead a discussion on whether Application Programming Interface (API) regulation is necessary for the future of information security. Participants were Bret Hartman, VP and CTO, Security Business Group, Cisco Systems, Inc.; Cooper Quintin, staff technologist, Electronic Frontier Foundation; Monique Morrow, CTO, evangelist, New Frontiers Development and Engineering, Cisco Systems, Inc.; Hadi Narhari, chief security architect, NVIDIA; Rob Zazueta, Director Platform Strategy, Mashery (Intel); Matt McLarty, VP, The API Academy, CA Technologies; and moderator Kimball Brown, Independent Technology Consultant. What is an Application Programmable Interface (API)? In its native form, APIs are building blocks for developers to construct programs. APIs often come in the form of a library that includes specifications for routines, data structures, object classes and variables. In other cases an API is simply a specification of remote calls exposed to the API consumers (for example, JSON and REST). These APIs are used primarily for many of the virtualized functions/service programs we are seeing on the market today. Think of a remote controlled robot on a manufacturing floor, a virtual network function in a switch or your favorite application on your cell phone that accesses the sensor on your wrist that monitors your heart or on a macroscopic scale, the billions of devices that are forecasted to exist via the Internet Of Things (IoT) and the programs to control them. All of these programs will rely on APIs in their development. Imagine if a rogue hacker tried to manipulate these programs via accessible APIs to cause harm? There lies the issue. How can this be avoided? What is the state of protection now? And where does this responsibility lie? The panel agreed that there needs to be more education given to developers on building security into their initial designs, possibly implementing an attack tree or use case security framework from which to build. This framework should be transparent to the consumer because this structure should not impede on the go-to-market strategies that affect the bottom line. Although the panel agreed that this would be a good idea, because there are so many types of APIs, there is no standard way to implement this. As for IoT, the development environment is not like a static information technology environment where the attack points are relatively predictable. IoT environments, in many cases, will be mobile, personal and limited in memory space for which traditional security measures cannot be used. The threat model will have to be redefined, which has yet to happen. Once one is established this model should be communicated to developers as well as consumers. Panel member also discussed a universal consortium establishing standards and if this would help the problem? The answer was a little but it would not fully address the problem, because the market pace and demand will be too fast for standardization groups to react. One thought was to develop an emerging new API platform with proper hooks and external partners buying into the model. This thought spurred an interesting conversation dealing with the integrity of the partners in the joint venture. How credible are they? This led quickly into the examples of Target, Snapchat and J.P Morgan/Chase where the weak link was the integrity of the partner and not necessarily the flaw of an API, underscoring that business partners having a stake in the level of security that is needed. This led to an interesting discussion concerning Person Area Networks (PAN) where the person becomes the API. Would a developer, consumer or human PAN bill of rights help? Again a “one-size-fits-all” constitution would be tough because every person has his or her own view of what personal security means? It would be hard for a government or business to enforce such a constitution. Businesses do not want regulation to hinder innovation or sales. The discussion concluded with the final question of how APIs will look in 10 years? All panelists agreed that presently APIs are in a single-user mode and need to move toward a distributed model. Higher levels of SDKs need to be implemented. APIs should have a different paradigm for deployment such that devices, services and systems govern themselves. For example, applications should automatically inform the API what it can and cannot do during processes. For IoT, this method will allow better integration between devices, reduce human regulation policies and thus optimize security.
... View more
The transportation sector is moving forward with Internet of Things), specifically in the area of telematics. ACG Research forecasts that by 2018 the machine to machine and IoT transportation market will reach approximately $19.4 billion/CAGR 33.2 percent, which will corner approximately 20 percent of the worldwide active wireless connected devices. Telematics was coined by Simon Nora and Alain Minc in “La Documentation Francaise,” in 1978. The word is basically from a Greek term describing the process of long-distance transmission of computer-based information. It evolved into automation in automobiles, such as the invention of the emergency warning system for vehicles. The IEEE standard, 802.11p, also referred to as Wireless Access for the Vehicular Environment, is considered the primary standard that addresses and enhances intelligent transportation systems. Today, with the advancements in hardware and software, telematics service providers (TSP) are enhancing the world of telematics. TSP in Fleet Management Telematics in fleet management can include a range of functions such as vehicle financing, maintenance, tracking and diagnostics, fuel, health and safety management. These functions allow companies such as rental car services, municipal buses, taxis and trucks to minimize the risks associated with vehicle investment, efficiency, productivity and reducing overall transportation costs. Fleet management functions can either be outsourced or controlled in-house. Fleet Management The Association of Equipment Management Professionals (AEMP) was formed in 1982 and represents fleet management professionals who work in construction, government, utilities, energy, mining and all other related industries. In 2008, the AEMP developed the industry’s first telematics standard, which has four aspects: (1) telematics data standard that allows end-users to integrate key telematics data (operating hours, location, fuel consumed, and odometer reading where applicable) into their existing fleet management reporting systems; (2) standardize on an application programming interface to integrate the data from each telematics provider into a common formatted database; (3) standardize on electronic control modules; and (4) standardize an XML format to present key data elements that drive the majority of fleet management reports (for example, hours, miles, location, and fuel consumption). This standardization certainly has propelled the telematics market forward and has made it easier for IoT initiatives to flourish. However, there are some risks associated with connect vehicles that should be considered. Access Security Daniel Bilar, from the IQT Quarterly, TSPs’ issues into “attack surfaces” from the vehicle-to-infrastructure networks and to the internal vehicle networks, such as FlexRay, MOST, LIN and CAN networks that connect to the electronic control units (ECUs) in vehicles. Some ECUs can be accessed remotely via cellular radio, some over shorter ranges, such as Bluetooth, and some require physical access such as On Board Diagnostics-II (ODB-II) or an iPod. These internal networks are usually connected by a gateway and like any network can be hacked. Figure 1: Vehicle Network: CAN, FlexRay, MOST, and LIN Networks Interconnected by a Gateway Some of the access vulnerabilities in vehicles that IoT will need to address: TSP Use Cases Nebula Systems (http://www.nebulasystems.com/), which has embraced the AEMP standards and connected car concepts, has developed a mechanics diagnostics platform in the cloud called MECH 5 (https://www.youtube.com/watch?v=rc1r156Ulgk). MECH 5 offers complete vehicle data bus access with all ECUs, from engines to body controllers to (ABS) brakes and instrument clusters. They provide full diagnostic functionality from within those ECUs, such as error code read/erase, live data, activation of components and programming of those components. The company offers other companies hardware VCIs: telematics GSM embedded devices, ELM327 OBD or J3534 pass-through devices. MECH 5 is HTML based so it can be accessed on any web connected device with any operating system. This is very attractive for third-party IoT application developers. MECH 5 is unique in that, according to Nebula, no other telematics or diagnostic company offers complete vehicle access via the cloud. Nebula Systems’ use cases deploying their solution sets: Telematics companies and fleet clients: AEMP has standards-based metrics that can be obtained by MECH 5, such as actual fuel levels, odometer values from instrument cluster, for more accurate efficiency targeting. Fleet companies also like the idea of performing full remote diagnostics on their vehicles especially for mission critical ones such as ambulances or cargo rigs. Fleet operators: Duty of care may soon require fleet operators to provide evidence of internal health of their vehicles. MECH5 can provide full global ECU reports at any time interval required, wherever the vehicle is located. User-based insurance: Many insurance authorities want accurate odometer readings, not those based on GPS calculations. One application of this function is a reduction of premiums if error- free ECUs are reported at time of vehicle incidents. Roadside recovery: With complete vehicle ECU coverage for diagnostics and remote access, roadside recovery companies would be able to give their operators a complete condition of the vehicle before they even see it. This will be great for pay as you drive insurance companies. Crash data analysis: Provision of vehicle fault codes at the time of incident along with other live data parameters from engine to ABS. For example, wheel speed at each wheel, RPM, Speedometer, etc. Big data acquisition: Many third-party companies want to leverage vehicle data via the cloud. Nebula Systems’ offering, apart from OEM systems, is the only one that can supply any data stream from any part of the car. Thus, new consumption models and value added customer offerings can be created and offered by the TSPs. Nebula Systems’ solution can be sold either as a public or private platform as a service.
... View more
Service providers (SP) have been offering machine to machine (M2M) services for more than a decade, but it was not until a couple of years ago when Internet of Things (IoT) capabilities came to the fore via SP and aggressive equipment provider marketing that businesses and the public took notice. To manage the expected exponential growth of devices and application intelligence SPs have partnered with IoT platform providers. How do these platform providers fit into the IoT ecosystem? What functions do they provide? What pain points do they address? And what does the future hold for such essential entities? Moving to enhanced IoT/M2M platforms Traditional M2M systems were monolithic, purpose-built solutions constructed to scale vertically but not necessarily horizontally, for example, telematics (fleet/asset tracking) use case. Trucks were outfitted with purpose-built GPS devices, and the underlining software applications were hardcoded to address one specific function. The SP’s delivery platforms, OSS and BSS functions were clearly defined and possibly located on clustered servers. If a company wanted to add trucks it could. However, an SP had to build a new process for each company that wanted the same service; consequentially, the SP’s operation expenses, capital expenses, manpower and skill sets increased. To handle the expansion in devices, OSS, BSS, data, application and security management SPs turned to platform providers to provide distributed platforms, which use virtualized software defined network technologies to build horizontally distributed solutions that enables the SPs to exponentially grow their user base and reuse hardware and software assets. In most of the platform solution designs, these key functional blocks are employed: Device connectivity layer: This entity is the link between the core system and the access device at the customer premises. This entity sits behind the OSS provisioning layer of the SP and are secure connects to the customer premises equipment. Some platform providers itemize data flows and perform least cost routing functions at this stage. Several protocol formats are supported at this level: Message Queue Telemetry Transport, Constrained Application Protocol and Extensible Message/Presence Protocol for message transfer. Embedded software stacks will allow local analytics and storage to occur at the edge depending on the IoT Gateway used; therefore, only necessary data and signaling will need to pass through the network, reducing overall data traffic. Application integration/development layer: The entity is used for the distributed applications that can be developed. The software is open web-based APIs, such as REST, XML, JSON, SOAP, Python, Ruby and JAVA. Third-party analytics, data storage applications and backend services such as SIM provisioning and billing functions can be integrated at this level. Platform management layer: Each platform provider includes its middleware of integration code to connect the device and management planes. This interface also includes a real-time management interface such as a web browser for visualization and rules creation for activities. Most of the platform providers to date primarily do not have a SIM provisioning feature; the SP’s OSS provisioning services has that responsibility since the SP actually owns its SIMs and device access to their networks. Jasper, a platform provider is attempting to provide an abstraction between all carriers to produce a global SIM. This is extremely important for IoT deployments because it allows IoT assets to be anywhere in the world. Although Jasper does not have a cloud application platform, it differentiates itself in that it has a cloud solution that focuses on the SPs’ OSS and BSS edge: mobile service management, real-time engagement, support diagnostics, billing and business automation. AT&T has an exclusive strategic partnership with Jasper in the U.S. to handle its IoT provisioning. Dealing with pain points Partnerships between SPs and PPs for the most part work well in addressing most customers’ needs; however, there are still issues with developing applications with the existing tools or integrating an existing application. Because industry standards are fluid there still exists many protocols, custom middleware and software tools to manage. PPs have to administer many device partnerships and revenue sharing models in the value chain. Although some solutions are working, in some verticals meeting the quality management standards, such as Sarbanes-Oxley, may affect the way the SPs/PPs implement their internal and external controls. Providers must also constantly address the issue of security at the edge, core, analytics and data storage plains. Looking to the future As the IoT industry matures the role of platform providers in the ecosystem will become more significant. SPs’ legacy OSS platforms will be more tightly integrated or replaced by platform providers’ offerings. As devices and applications increase in complexity PPs will have more control and be able to dictate better deals for their customers by brokering through numerous SPs. Savvy SPs will either partner with or acquire PPs. Right now, the platform providers’ horizontal services layers are still fragmented. To improve the normalization process between PPs the industry standards bodies will need to converge more quickly. Learn more about Dennis Ward by visiting his community profile here.
... View more
I attended a webinar moderated by Carl Piva, VP, Strategic Programs TM Forum, with panelist Craig Bauchmann, senior director, Industry Initiatives TM Forum and Dan Baker, industry analyst. Though the event seemed to be a plug for the upcoming TM Forum Live! 2014 – Transforming to a successful digital business, it still touched on quite a few key topics affecting service provider business opportunities in IoT/M2M: What is the SP’s role in IoT/M2M? The supplier chain for an actual IoT/M2M solution can be quite complex, and the solution is not sourced by the SP alone but by many suppliers, supporting a full ecosystem of (1) devices/sensors at the CPE, (2) the access point connected to the public network, (3) the owner of the SIM (for example, the SP in the case of wireless solutions), (4) the data and its platform for transport, (5) service/order fulfillment systems with its associated analytics, (6) the service application(s) of interest along with its associated analytics, and (7) the VAR promoting the service. With this cast of suppliers one has to ask, “Who is responsible for the customer?” Is it the carrier SP or the reseller? Some implementers view the SP owning the customer because the SP owns the network. Others view the solution as a system, maintaining that all suppliers should have an equal stake. Since most, if not all, IoT strategies will be built around open systems solutions, the SP will have to look at its role sometimes as a dominant player but and at other times as a mutually equal partner. Different verticals will need to be served, and with no clear standards the SP really has to choose which platform(s) it can support to bring the solutions desired by the consumers to market. Who is making money with IoT/M2M? It will require many types of companies needed (for example, partner SPs, chip vendors, device vendors, VAR applications, support services) to deliver these services, and the SP actually may not be the dominant player in many situations branding the service. So the answer may be who is on top of the business model or deal at the time? Regardless of the answer, the stickiness of the service will always be around the customer’s quality of experience. So the management of the service has to be at the highest quality for all stake holders to make money. Is there monetization within the ecosystem? Now that everyone within the IoT solution has a relatively even stake, they will all have to determine how to make incremental revenue in addition to the overall solution. For example, in a telematics solution, SPs can offer retail coupons of various kinds to consumers to obtain incremental revenue. This is similar to social media companies such as Google and Facebook, which are essentially gouging the SPs of revenue. Because SPs don’t have a lead role in the IP space, they need to insert themselves into the value chain; a different mindset is needed to earn the most margin. With value at stake projected to be ~$14 trillion, everyone in the value chain stands to get a fair share. How can SPs get majority of the margin? SPs that obtain most of the profits in the IoT value chain will be the ones who can display the best quality of service generally and specifically in key verticals. For example, surveys show that SPs that can meet the strict service layer standards in the healthcare verticals will do well. This is because the customer and/or the application service provider will most likely be willing to pay for this level of service. Some winning use cases focus on smart construction sites and wearable services where basic safety and awareness monitoring were important. Nevertheless, use cases in these areas need deeper analysis to understand the total cost of ownership, the gross margin for the service and the revenue split between the suppliers and SP. Regulation and standardization, where do they stand? International standards groups and the TM Forum are discussing digital health programs and implementation standards. However, the SPs have to be aware of the operational expenses incurred in implementing these regulatory practices. Regarding international standards, the panel will discuss this large and important topic at TM Forum Live! event on June 2–5, 2014, in Nice, France. Who is the owner of data? Because the IoT market is still maturing, rules governing data privacy are somewhat elastic but not for long. An example is in the social media sector and the ongoing debate government groups as to who owns the data at certain points in the network (for example, http://www.latimes.com/business/la-fi-lazarus-20140506-column.html). These issues will be discussed in the TM Forum Open Digital Program projects. What are IoT/M2M SP objectives? A refreshing consensus stated by panelists was that the objectives of the SPs were not to look for “killer applications” but how to manage opportunities and vendors in the IoT ecosystem. MVNOs and SPs that own the customer and manage the ecosystem well manage the money, specifically, application offerings, business model to manage many partners and OSS control management to customers. Which company will provide security leadership? AT&T is making strides in security in IoT in the U.S., but data and monetization opportunities vary depending on the country. For example, providers in the healthcare verticals Canada seem to be taking the lead in best practices and security standards in the IoT/M2M space. Internal management systems vs vendors which will it be? The TM Forum is promoting a framework for enterprise IoT/M2M deployment services. This framework is focusing on agility through standardization of open APIs to address the open digital economy. This will be essential for Telcos that want to deploy OTT services faster. SPs offering these services in hotspots and home spots will notice the customer stickiness over time. MSOs already understand this business model so Telcos have to catch up. How will IoT/M2M roll out? IoT/M2M business solutions will enter the market suddenly, similar to the cloud solutions (think Amazon). For SPs, analytics will be part of the backend solutions (for example, backhaul and back office applications). These applications will ultimately be important drivers toward IoT/M2M growth. As far as cities, IoT/M2M growth will occur first in the rural areas then in major cities. The main takeaway for SPs for IoT/M2M: (1) arm yourselves with knowledge of industry trends and open platform solutions, (2) capitalize on use case scenarios that enhance value within the supplier chain, and (3) proactively get involved in evolving industry standards groups to propel this industry forward. About the Author Learn more about Dennis Ward by visiting his community profile here
... View more