References that, like everyone else right now, I’m using to grab a few additional page views. Do I feel as slimy as an Ekans?1 Yes -- but my mother is proud of me. Then again, she is also a proud supporter of the Crystal Palace Football Club, so I generally take her adulation with a grain of salt. Sorry, Mum.2
To be honest, I feel a little oily using the term “IoT” in this post -- especially as I’m going to use it in reference to the types of services and end devices I openly mocked only a year ago in a blog post entitled “The Internet of Turkey Bacon.” You could say I’ve sold out. I’ll own that. But I could argue that, with the addition of a courtesy title prior to that acronym, we can bring a little clarification to the definition of a “thing”: “Industrial,” for the ubiquitous, constrained, sensor grids I lauded in that post, and “Consumer” for the otherwise innocuous home appliances and automation features that will ultimately improve our quality of life.
I will concede that I made a rather sweeping, generalized statement in that post. Shocking to hear, I know, but a fact nevertheless. You see, I stated that (with few exceptions) these “things” reside on the power grid in full view of a Wi-Fi hotspot and behind increasingly broad broadband pipes. Basically, anything but “constrained,” as defined in many Industrial IoT (IIoT) applications. It turns out that this view is a little shortsighted. While I mentioned the fact that something like a home thermostat might also have a connection to a public wireless network, there are other “things” as well, such as home security systems, which are potentially constrained (if the power is cut, in this case) consumer IoT endpoints. What if, though, that home security system also includes a monitoring component, in the form of a video and audio feed – the sort of thing that is very common for local Wi-Fi/broadband and mains-connected solutions but could suffer with a severely degraded quality of service at the exact time it’s required for something other than checking in on the dog or the delivery guy.
At this point, I need to apply another qualifier to make the distinction between IIoT machine-to-machine (M2M) communications and what is essentially machine-to-person and referred to in the industry all too infrequently as… errr… M2P. 3 If my turkey bacon debacle has taught me anything, it is to think outside the classic IoT (refrigerator) box, and others should take note as well. I now even recognize person-to-person (P2P) as a valid IoT application, given that non-classical telephony endpoints, like connected cars, may demand two-way communications for services such as roadside assistance and automatic crash response. Indeed, in April 2015, the European Parliament voted in favor of a regulation that requires all new cars, sold from April 2018 onwards, to be equipped with such technology. This “eCall” mandate will ultimately increase the number of endpoints requiring QoS guarantees for a service, which can literally mean the difference between life and death.
Infographic: The European Union eCall Mandate
Now, I know what you are thinking: “M2P? P2P? Come on, Dredgie. That’s just a voice or video call. It’s hardly what people consider IoT.” That’s fair -- but take the home security and eCall examples, though: Both are calls initiated by something other than a person punching a button, and both are critical lifeline applications that cannot be modeled in the same way classic telephony networks are. Plus, they are operating in potentially constrained environments. They are also offerings that we hope never get used, and we therefore would not expect to pay the same amount for them as we would for monthly cell phone offerings. While it provides a service that is arguably far more vital, the supporting carrier infrastructure must also be more cost effective than it is today. However, unlike IIoT M2M proposals for highly distributed sensor grids -- the kind I’ve talked about extensively in my previous blog posts4 -- the RAN will be the same as that used for classic mobile offerings.
All this is happening while mobile operators are re-allocating circuit switch media spectrum and the move toward packet switched Voice over LTE (VoLTE) is well under way. Fortunately, this means that network operators are no strangers to deploying IP services with strict QoS guarantees. As part of the GSMA IP Multimedia Subsystem (IMS) specifications, the 3GPP went to great lengths to define a granular policy control architecture.5 Within TS23.203, the 3GPP outlines 13 distinct QoS Class Identifiers (QCI) under two resource reservation categories: guaranteed and non-guaranteed bit rate, or GBR and non-GBR, respectively. Every QCI is associated with a priority level, of which 0.5 is the highest. If congestion is encountered, the lowest priority level traffic would be the first to be discarded.
3GPP TS23.203 Standardized QoS Class Identifiers (QCI) and characteristics
Residing in the IP Core network, the Policy and Charging Rules Function (PCRF) operates in near real time, making decisions for each active subscriber and service data flow (SDF). Rules are created based on information pushed to the PCRF from application functions (unsolicited), pulled from subscriber databases or derived from the Policy and Charging Enforcement Function / PCEF, residing in the IP Edge (solicited) -- both via the Gx reference interface employing the Diameter protocol. Individual QCIs are mapped to Differentiated Services (DiffServ) Code Points (DSCPs), allowing the policy to be applied at the relevant Evolved Packet Core (EPC) network nodes, such as the PDN gateway (P-GW) and mobility management entity (MME), along with the radio access network (RAN) elements, like the eNodeB. You will be glad to hear that I don’t plan to continue the acronym barrage any further as much has already been written on this topic. Check your local Internet for details.
If you happen to have skipped the last few paragraphs (and I don’t blame you if you did), let me net it out: If you want QoS guarantees for switched media services deployed on a general-purpose mobile network infrastructure, you need IMS. Is it the same IMS you are currently employing for your VoLTE and rich multimedia communications service offerings, though? Maybe -- but that really depends on how you are currently deploying your IMS core. Before heading through the acronym labyrinth, I mentioned that consumer M2P and P2P IoT services must be modeled and priced differently from classic telephony services, which puts a whole new set of demands on the architecture supporting them.
Fortunately, there are alternatives to classic IMS implementations that can meet these requirements. Avid followers of Metaswitch, in the last three years, will be very familiar with Project Clearwater -- the open source IMS Core implementation that was built, using web design patterns and methods, specifically for cloud architectures like those outlined within the network functions virtualization (NFV) specifications. With highly scalable distributed database techniques, enabling extremely distributed state maintenance and an NFV microservices architecture6 that was developed before there was such a thing as NFV microservices, Clearwater can be deployed for well under two cents per subscriber per year, and can be granularly scaled up or down on demand, eliminating the typical oversubscription models that plague current IMS implementations.
On December 14, 2012, Niantic Labs, a spinoff from Alphabet Inc., the multinational conglomerate controlled by Google, released (albeit on limited platforms) a complex new mobile augmented-reality massively multiplayer online (AR/MMO) location-based game called Ingress. While the actual figure is impossible to ascertain, sources claim that by May 2015, there were in the region of 1 million active players every day. Launched on July 6, 2016, the simple Pokémon-hunting summer sensation is tracking 26 million active users in its first 10 days and rising.
One of the original Ingress Portals now used as a PokéStop
Long before there was a PokéStop or Gym, there were Portals, identified and logged by Ingress players who were employing the same basic game-play concepts and unwittingly developing the geolocation mapping infrastructure now being used to pursue Pikachu. Moreover, in true consumer IoT fashion, new wearables (currently called “Plus”) are in the works to extend game play further.
IMS concepts have been extensively developed and proven in early VoLTE deployments in the same way Ingress proved the viability of mobile AR/MMO. With this foundation, the same techniques can be used for simpler applications requiring massive scale, like Consumer IoT M2P and P2P services. NFV and virtualized network functions (VNFs) like Project Clearwater are critical to making this possible. Fortunately, Metaswitch is your ideal trainer for the IoT infrastructure battle ahead. Let the games begin.
To learn more about Project Clearwater, click here or simply contact us using the button below.
1. Yes – I know. It’s “Snake” spelled backwards.
2. Actually, this is all a lie as my mom still has no idea what I do. Indeed, the only person who asks me to explain my role and purpose more often than her is my boss.
3. In my non-scientific test, “‘internet of things’ M2M” garners 598,000 Google (U.S.) hits while "’internet of things’ M2P” gets just 6,060. 6,061, after this post goes live, which will be a proud moment for me, personally.
4. IoT: The Internet of Turkey Bacon? | Pixie Dust and Unicorn Stuff - The Magic Behind SDN | Deterministic, Time-Sensitive Networking for IoT
5. 3GPP TS 23.203 | Technical Specification Group Services and System Aspects; Policy and charging control architecture. | Release v14.0.0 (2016-06) as of this post
Topics
Related Post
