Month: August 2019

Recently I had a friend ask me why some things I’d declared as failures were considered successful by the media.  The obvious reason is that something that’s good for publicity is good to the media; their standard of success is different.  The less obvious reason, and one just as pervasive, is what I’ll call “success by subtraction”, and it’s hitting telecom especially hard.  Hard enough, in fact, to make it a big problem.

Everyone knows that developments these days are over-hyped, and that’s been the case for about two decades.  One result of this over-promotion is that expectations for a product are set so high that there’s little chance it can meet them.  NFV is a good example; to succeed in its goal of improving profit per bit significantly, it would have to be widely adopted, and that’s not happening now nor is it likely if we stick to the ETSI NFV ISG model.  However, NFV can be applied in a very limited way to provide edge features for business data services—virtual CPE.  If we look only at that space, we could declare that NFV was “growing”.  It’s not that it actually has a chance of meeting its original goal, but that we’ve removed elements from that original goal to correspond with what can actually be done.  Success by subtraction.

The problem with success by subtraction is that it hides major industry blunders, spending vast amounts of money and time doing something that’s not going to pay off on the investment.  Meanwhile, of course, the problem that was supposed to be solved by our blundering technology remains, and other possible paths to its solution are ignored.

You can see the success-by-subtraction paradigm clearly in 5G too.  OK, we need 5G in that we need the improved efficiency of spectrum use, subscriber density, and so forth.  But is 5G a revolution?  We hear that it lets people download videos much faster, but of course most people watch videos rather than downloading them.  The reason for the 5G-is-faster line is that it’s a better story, but you could argue that what it’s threatening to do is offer some operators a justification for making 5G more expensive.  If the real value of 5G is efficiency, why wouldn’t it make mobile service cheaper?

Where the real subtraction comes in is in the evolution of 5G features—from radio-network-centric first steps to full 5G Core.  We hear about all the stuff 5G Core will do, and we don’t hear much about the fact that the focus of 5G now has nothing to do with 5G Core, and may never have anything to do with it.  We could very well see 5G stall out in the “New Radio” enhancement and yet be touted as a success.  Success by subtraction.

Then there’s IoT.  The “Internet of Things” started (logically) as being about putting “things” on the Internet for exploitation by OTT players.  OTTs were enthralled by the notion that they could exploit these IoT sensor resources, and telcos were enthralled by the opportunity to send monthly bills for all the sensors to be connected.  There are a few examples of cellular IoT (in the transportation and utility industries, for example) and these are touted as the leading edge of a wave that will lead to the full IoT realization.  Except, as we already know, there’s no clear business case for that model and no real chance we’d get it into play.  But never fear, we’ve now declared home thermostats on home WiFi to be IoT, despite the fact that we had home WiFi and home sensors long before IoT came along.  Still, we’ve included this old stuff in the new IoT model, and thus declared our goals met.  Success by subtraction.

These examples demonstrate the problem, but it’s hard to say how much real industry hurt is done by just failing to live up to any of the technology promises we tout.  The real problem I see with this subtracting trend is in the area of service lifecycle automation.  I’ve been tracking operations costs and trends for decades, and one point that’s been clear is that the great majority of “process opex”, meaning operations costs attributable to service and network operations, lies in the network side.  Processing service orders, doing billing, and so forth, are fairly predictable cost elements that don’t account for more than about a seventh of overall opex, and are handled with some efficiency already.  Sure, we could wring out a little more efficiency, but for the most part, they’re efficient enough.  Where we have problems is in handling problems, unusual conditions.  “Lifecycle” automation, in short, has to automate the entire lifecycle.  If you put it that way, most operators agree.

The problem is that whether we’re talking about something like NFV’s Management and Orchestration (MANO) processes or something broader like ETSI Zero-Touch Automation (ZTA) or ONAP, we’ve ended up focusing almost totally on deployment and not on the full service lifecycle.  It’s certainly important to get a service deployed, but that doesn’t address anything like the majority of the opex problem.  We’re seeing a contraction of scope that makes what’s being done the new “goal”, a success by contraction in the making.

Deployment is one state/event set of the many that are involved in service lifecycle automation.  If we were to go back to the old days of protocol handlers, we’d see that there is an “initialization” phase to getting a connection established.  It’s essential that this be there, of course, but if all you can do with a connection is initialize it, there’s little chance you’ll have too many people caring about your capability because the benefits won’t justify the implementation costs.

You see a lot of OSS/BSS vendors jumping on the ONAP concept, but remember that very few network operators have OSS/BSS systems fielding network events.  Lifecycle automation isn’t happening, isn’t going to happen, in the OSS/BSS.  What’s needed is a different model, one where service data models link events to processes, not to “systems” like OSS or NMS.  The very concept of a “management system” or “support system” screams “monolithic implementation!” for all who listen.  There is no “system” in a distributed cloud-native implementation of lifecycle automation.  The data model systematizes things for us, assembles processes to handle events.

Don’t take this to mean that OSS/BSS or NMS goes away; the concept remains, and there would also be a collection of processes that align with the current systems.  It doesn’t require operators reorganize themselves, only that they build processes around data models, not into systems.  That’s the critical cloud-level innovation, the thing that separates a cloud-native implementation from anything that came before.  But it’s also critical for full-scale, cradle to grave, service lifecycle automation, because it accommodates all service events and states, and is scalable enough to manage the kind of event load we might expect to find if all service events were handled.

We are not going to reform the media.  Ad sponsorship is now almost universal, and it encourages the production of entertainment and ads, not education or truth.  We’re not going to reform vendors either; the nature of the stock market dictates they stand tall during earnings calls.  Read the transcripts yourself and you’ll see what I mean.  What we have to do is reform buyers, and in the telecom space that means the network operators themselves.  They need to back initiatives that are heading in the right direction, both with funds and with qualified software architects.  They need to frame their software and standards around the state of the cloud, not around the structure of software systems that are often older than the current generation of engineers.

We also need to expect more from all these stakeholders, including the media.  Yes, it’s tough to write interesting stuff every day without breaching the boundaries of reality.  Yes, it’s tough to frame a future architecture without compromising the present, and yes, it’s difficult to toss aside decades of a business model.  Refusing to do those things doesn’t make things easy, though.  It only offers a short-term respite in what will be a long-term collapse.  We are seeing open-source software producing almost all the useful innovation in a software-defined age.  Wouldn’t it be better to be a part of this revolution than to be making up stories to promote an unrealistic future vision or a short-term product strategy?  I think it’s time for everyone to accept that only the open-source vision of the future has any chance of really coming true, and working harder to understand what that vision is, and means.

If calling a personal agent a “ghost companion” is fair, then it’s fair to say that adding artificial intelligence to our artificial companion could be a good idea.  It’s also very likely that the concept of information fields could be enhanced through the application of AI.  How much we could expect and how complicated these additions would be depends on just what we mean by AI.  It’s not a term immune to hype, after all.  And please be sure to read the FIRST, SECOND, and THIRD blogs in this series before you read this one!

A perfect personal agent, fed the data needed to share context with us, could be expected to provide the same sort of advice that a real companion could (or perhaps even better).  Obviously both the quality of information and the artificial intelligence available would limit real-world benefits to something less dramatic, so we’d need to have some specific model for AI application to test cost/benefit with.  Getting one could take a bit of experimentation.

There are two conventional visualizations of a contextual personal agent.  The first is a policy model, similar to that used today in presence-based applications and services.  The behavior of the agent is the sum of a series of policies that link conditions and reactions.  Think of this as a bunch of IF-THEN-ELSE conditionals.  The second is a state/event process, where the user is fitted into a series of well-defined states, representing missions and behaviors.  Conditions, in the form of events, trigger process reactions based on state.

One interesting point we can take from this is that if we could define a series of clear missions and associate behavior patterns with those missions (which can be done through analysis of past behavior) we could do a pretty good job of creating a personal agent using either of these conventional technology strategies.  Thus, the benefits of AI would be greatest when we can’t define clear missions or associate behavior patterns.

As I said in prior blogs in this series, contextual behavior is best understood by presuming a user is on a mission, meaning that they’re doing something.  As they do that, they are sensitive to contextual information that relates to their mission and at least somewhat less sensitive to information that doesn’t relate.  Walking down a given street on the way to the office is different from shopping on that street, and both are different from a sightseeing or time-killing stroll.  Mission is the primary contextual key to personalization and relevance.

I cited three examples of mission in my last paragraph, but of course there could be more, and there could be “sub-missions” or refinements of a mission based on specific goals—I’m looking for a specific product or service, or a specific experience or landmark, or simply to check out a new area.  We could, in my personal view, define a pretty effective and limited set of missions.  The problem is when that mission set doesn’t apply closely enough to provide contextual relevance.

If I set out for a stroll in New York (as I’ve done many times), my behavior might at first mimic behaviors associated with other missions.  I walk north on the Avenue of the Americas, which might be taking me to a familiar store or restaurant, or even to meet someone.  If it’s the latter, it’s possible my calendar or a recent text, email, or call could be a signal that this is a meet-me mission, but it’s also possible the meeting wasn’t triggered by a recent communication or even put on my calendar.  And, of course, it’s possible that’s not even my goal in this stroll.  Where AI comes in is its ability to analyze my behavior pattern independent of my route.  Am I walking purposefully or ambling?  Am I pausing to look into windows or ignoring them?  Is there any specific display that seems to hold my interest?  AI might be able to provide answers to these questions.

Mission, in both policy-based and state-event-based analysis, sets the presumptive state.  If it’s not reliable, then nothing that follows in the way of interpretation is likely to be any better.  AI could infer mission from a broader set of behavior patterns, and by doing so could create that first critical element in contextual analysis.

The critical ingredient here is the ability to infer mission from behavior, rather than using mission to interpret behavior.  AI here would still analyze historical behavior, but with the goal of establishing patterns that could be mapped to presumptive missions.  If I walk a certain way when I’m walking to something, then walking that way implies a destination-related mission.  If, as I approach a known destination, I always slow down or speed up, then my failure to do so would imply that a presumptive destination assignment is incorrect.

In the behavioral-analysis model, the route someone takes is less important than the way they take it, the overall pattern of speed, starts and stops, and so forth.  These factors are complex because they’re “situational”, meaning they have to be related to conditions at the time.  Of course you have to stop at lights, and when you pause to look at something, it’s important to know whether it’s graffiti on a wall or the window of a shop.

This latter point tells me that AI requires better information fields.  What’s in a shop window?  Obviously, the shop’s owner would know, but do they have an incentive to make this information available as an “information field?”  We might suppose that something could regularly run down the streets of a city, taking pictures of shop windows, and using AI and image recognition to classify the items, but that also begs the question of incentive—return on investment.

What could be done more easily?  Well, shops often sell a specific family of goods or services, and so some classification of window contents could be inferred by knowing the kind of establishment involved.  Sales are normally advertised, so it’s reasonable to assume that if sales were advertised online, those sales could become input to an information field.

Information fields themselves could benefit from AI too.  A good example is pedestrian or vehicular traffic.  It’s possible to establish, from the analysis of movement of user devices, the pace of movement and the likely level of congestion encountered.  This would then become an information field element, something that might explain a sudden change of direction in movement.  It’s also possible to anticipate future conditions based on history, and while this could be done by the personal agent, there are times when it would make more sense to have AI linkage in the information fields themselves.

A good example is traffic after a sporting event.  Conditions would impact a large number of people and will generally follow a similar pattern from game to game, depending on things like what time the game is finished, the weather, how close the game is (and thus whether people leave early), and how many attend the game.  All that would be known, so a traffic information field could use this information to guide not only attendees but also those who had to drive through the area impacted by game traffic.

AI differentiation in information fields might become a competitive factor, if information fields themselves became competitive—which they could.  In fact, both information fields and personal agents are most likely to employ AI to gain a following.  Think of it as the search engine of the future.

The net of all of this is that AI could certainly benefit contextualization, but in order for that to happen, we’ll almost surely need richer information fields in general, and probably greater insight into the direct behavior of users.  The more insight we have, the creepier the process could appear, and the more likely it would be to attract the notice of privacy advocates and regulators.  Our ghost companion could easily turn Orwellian on us, and the industry is already under scrutiny over privacy issues.  It will take more smarts than it’s shown so far to stay off the reef on contextualization.

Contextualization has a lot of pieces, but the most obvious is the “contextualizer”, the trusted personal agent process that actually interacts with the information fields that contribute to context, and from them generates contextual results.  This is the third blog in the series; the FIRST and SECOND should be read before you dive in here.

Remember my “ghost” example?  A personal agent is an invisible companion who’s expected to be our window on the virtual world.  As such the agent has to share context with us to make its insights relevant, and that’s accomplished by drawing on the “information fields” that represent contextual inputs (the subject of my second blog).  It’s easy at one level to hypothesize how a personal agent could take requests and juggle information fields, but remember that our goal is to make the interaction with our ghost as natural as it would be with a real human companion.  That’s what “contextualizing” is about.

I submit that there are four steps in making our agent a true virtual companion.  The first and most important is to determine what we’re doing.  You could say that this is an expanded form of presence, which is a term used to describe our online availability.  The second is to gather relevant information based on our “presence”.  This is done through the information fields I discussed in my last blog.  The third step is to assess information against a contextual framework to prioritize presentation.  If I’m sitting in my favorite chair reading, I’m not as likely to be interested in traffic conditions on my street as I would be if I was preparing to drive.  Step four?  It’s to continue to re-evaluate as my behavior changes demand.

You can’t be helpful as a companion (visible or otherwise) with no sense of what you’re supposed to help with.  There are situations where mission is explicit, as when a user asks for the location of some retail outlet or restaurant, or shops for a specific item.  In other cases, mission can be inferred by a combination of time of day, the user’s movement vector, and history.  If driving to work is the regular action at 7:15 AM, and if the time is a match and early movement conforms to history, you can infer the user is driving to work.  It may also be possible to inspect the movement vector and infer an activity like “window shopping” by matching stops to shop locations.

The mission or expanded presence is essential in what’s likely to be a process of successive approximation, based on information gathered.  It’s 7:15 on a work day, so we infer that the human whose “ghost” our personal agent represents is on the way to work.  There would likely be other things our user would do in this situation, such as checking business email or stopping at a regular shop for coffee and a pastry, and if these things are done, it reinforces the presumptive mission.  The certainty inherent in the mission presumption is then critical in our next step.

Reading someone their calendar for the morning is a logical step if the person is on their way to the office, but intrusive if they’re not.  For a given mission, we could presume a “certainty score”, and for each piece of contextual information we (as the ghost companion) might deliver in association with each possible mission, we would have a threshold value.  We’d deliver any information whose threshold score was higher than the certainty score for the mission it was associated with.

And obviously, if there were to be a behavioral deviation from the profile of the mission, we would presume that the mission was now less certain, reduce the score, and perhaps start looking for clues as to the real mission.  One likely clue is recent stimuli, in the form of a call or text, a web search, or even a stop to look at something.  It’s likely that this process, which feeds back things that could change the focus of human attention into our virtual/ghost agent, will be the technical key to the success of contextualization.  It’s also perhaps the biggest reason why contextualization risks violation of our First Law.

A ghost agent that lives entirely in a ghost world isn’t likely to be on track with human behavior.  People tend to move between a series of “missions”, each of which command their attention for a period of time.  They transition between missions because something happens to knock them out of their current framework, that outside stimulus.  Because it’s critical that we know what the current mission is, it’s critical we know when it changes, and that means drawing in more knowledge about things that have happened, like calls or texts or web searches.

Most online users today have come to terms (some more reluctantly than others) with having their search history used to frame the ads they see.  My straw poll suggests that there’s growing acceptance of having a minimal awareness of email, voice, and SMS communications, but resistance to having the provider actually “read” the content.  However, if we’re going to recognize mission changes, we may have to do that, which is one reason why a trusted agent is critical.

There are two technical options for trusted agent hosting—in the user’s device or in the cloud.  The security/privacy of these options don’t really differ much, because the key to both is having a framework that doesn’t let the outside look into it.  There are, in fact, five technical requirements for a trusted agent, wherever it runs.

The first requirement is that it represents its user anonymously.  The user’s identity cannot be exposed by the agent when it makes requests on the user’s behalf.  Since many of the stimuli that would signal a mission change are channels of personal communication, that means that the device has to be able to act as a local “information field” to provide that information, even if the trusted agent actually runs in the cloud.

The second requirement is that trusted agent communications must be fully secured.  This has to be true between the agent and the information fields, and between any cloud component of the agent and the user’s device.  Information can’t be subject to intercept, nor can it be possible to make inquiries of the agent from the outside or push information to it, except from the device.

Requirement number three is that the trusted agent must be the element that recognizes stimuli to signal a mission change.  Since you can’t “push” information to the agent except from the device, (based on the last requirement) in order to avoid playing the agent process with false stimuli, the agent has to be alert for changes in mission.  It’s my view that when the agent does believe a mission change has occurred, it should be a “notification” event to the user, subject to the normal device rules on whether the event would result in a visible/audible notification.

The fifth requirement is that the trusted agent must explicitly manage the information field relationships, extending trust to those relationships, providing users a list of the information fields they depend on, and allowing users to select their own information field providers, subject to a warning about trust level.  I expect that trusted agents will be a competitive product, that “lock-in” will be attempted by many trusted agent providers who want to build their own private ecosystems, and that an open model will be critical for user success.

The final requirement is that elements of the trusted agent must be portable between the cloud, the user’s mobile device, and a designated set of systems under user control.  Think of the agent as a series of processes that cooperate with each other but might be hosted in multiple places and move among the list of hosting candidates as the situation dictates.

The trusted agent is the face of contextualization, the link with the user that either justifies everything or acts as a boat anchor.  Is it also the logical place to apply artificial intelligence?  We’ll see in the next piece.