The Sunday Brief: Programming tomorrow’s network

Holiday greetings from sunny and mild Lake Norman, North Carolina (sunrise shown – unaltered photo).  There are a lot of follow-ups to cover, and, if reports are true, there may even be a settlement between the Attorneys General and T-Mobile/ Deutsche Telekom/ Sprint/ Softbank prior to their trial start on Monday (hope springs eternal).

Many thanks for the multitudinous comments on last week’s Thanksgiving book review article.  We are not turning into the New York Times Book Review (won’t even try) but there’s a lot to discover and learn from the activities of our predecessors.  We will have a similar article on Steven Coll’s 1986 classic outlining the events that lead up to the breakup of AT&T on December 29.  Preceding that, we will have a “Three Companies to Watch” special TSB on December 22.

A final thanks for the many referrals that we have had over the past month – over 250 new readers have been added.  If you know someone who could benefit from this column, have them send a request to [email protected] and we will get them on the list.  We are also in the process of revamping the website (end of January) and promise more things in 2020 (including a merchandise fundraiser for the Davidson College Jay Hurt Hub for Entrepreneurship and Innovation).

This week, we will lead with a discussion of a deep topic – rethinking the wireless (and wireline) network operating system.  As mentioned earlier, we have several TSB Follow-Ups.

Programming tomorrow’s network

Within wireless communications networks, there are multiple pieces of hardware, each running its own operating software.  Each needs to operate to a given specification (usually a 3GPP or LTE Release standard), and there are likely additional requirements placed on the suppliers by the local operators.

This model worked reasonably well when voice and text (using the SS7 TCAP standard) constituted the majority of activity.  However, the interest in pushing applications (e.g., WhatsApp owned by Facebook) deeper into the network has created a gap between legacy product development and entrepreneurs.  On top of this, there is a need to cost-effectively provide access to less developed areas.  On top of this, data growth continues to drive up costs, which create pressures on carriers (and, as a result their suppliers) to deliver a better experience and greater profitability.

This has forced two things to occur:

1. Greater network sharing (predominately radios and transport) between network operators.  CBRS is the beginning of this trend in the USA (see TSB on CBRS here); and
2. Separation of hardware (e.g., a shared radio) and operating software (which may be custom to the operator).

Doing all of this in a secure environment is a challenge.  Developing new operating systems amidst a global shortage of software development talent (and recognition of venture capital and other investors that this can be a value-producing endeavor) is an additional challenge.  Integrating any operating system changes into the stream of concurrent innovations (e.g., 5G Standalone equipment development, increased mobile edge computing deployments, etc.) requires coordination.  Creating competitive advantage in addition to achieving cost reduction targets adds to the heap.  It’s like replacing Windows yet expecting no change in how current and future versions of Excel and PowerPoint will work.

We outlined the AT&T efforts in this space in a previous TSB (link is here) but think there’s a few “no brainer” areas where application developers and carriers should come together to improve experience.

1. Voice calling.  This experience is essentially the same across carriers:

• There is a non-real time contact list that is invoked through a clumsy, 1990’s dialer scheme (see nearby picture);
• There is no voicemail ubiquity within the carrier community (there is at the app layer, however, for WhatsApp, Google Voice, and others);
• To the best of my understanding, there’s no way of automatically integrating stored voicemails into CRMs such as Salesforce;
• There is no reminder or follow up function on voicemails (think how Gmail does this with emails); 
• There are inconsistent methods of identifying spam calling (and any other incoming call for that matter);
• There’s no way of knowing any details or status about the party I am calling (such as whether they are on the phone or whether they have made a call in the past five/ten/fifty minutes or even the last day – think the notification scheme for apps such as Skype, etc.);
• For incoming calls, there’s minimal context and no ability to instantly locate/trace the incoming caller (mobile edge computing could fix this pronto and you could see that the call showing 704/Charlotte area code is really originating from Omaha);
• There’s no ability to interrupt a current call (e.g., spouse calling), a call feature common in contact centers (whisper tone);
• There’s no common messaging portal incorporating LinkedIn, Facebook, carrier, WhatsApp and other sources;
• Integration between conferencing services such as Zoom or Skype and the mobile device have not materially changed in 20 years.  Still a phone number plus an access code and an announced name.

Is it any wonder that Google Voice, Facebook, and WhatsApp are succeeding and that carrier voicemail solutions are flat to declining?  Customers are communicating more than ever, but they are just not into that 1990’s dialer.

To change voice, the interaction between a customer’s contact list (directory), the universal contact list (macro directory), storage (voicemail), availability (presence/ proximity) and the network needs to change.  This can all be done faster within the network and is a prime example of how operating systems can and should be rewritten.

Voice application (the dialer provider) should be a choice.  It should be portable and interoperable.  It should be driven by a microphone and intelligence, not by typed search strings into contact list applications.  And the private directory should have live updates (if allowed by the directory listing).  The integration of applications functionality deeper into the network can do this, and advancements will occur a lot faster than we see today from the carriers.

2. Predictive Analytics (and Customer Care).  One of the eye-opening experiences I had with my Flash Wireless experience concerned troubleshooting device issues (Flash had a heavy Bring Your Own Device base).  As an MVNO, we tried when possible to go the extra mile if the issue was device-related as opposed to a network issue.  We formed a checklist which could easily be databased in today’s environment.  Some of the important topics included:

a. IoS or Android version

b. Recent activity (e.g., voice over Wi-Fi connectivity issue vs the network, messaging activity, new apps downloaded, Wi-Fi vs network data access, location)

c. Port-in provider (experience expectations)

d. Phone age (and purchase source if it came from one from a known vendor)

e. Customer lifecycle age (pre-first bill; first 90 days; over 180 days; etc.)

The number of possible iterations quickly grew, especially since we were in a 3-carrier MVNO environment (location in section b. above really mattered for some of our network providers).

A system that continually interacts with the network could do a better job of measuring data and device quality.  If a customer had a service need, problem identification could be instant and highly accurate.  Success would not be determined by the smartest care expert, but by the network (and the collective experience of all previous users who had ever used the network in that location at that specific day/time).  The cost of caring for older devices could be calculated with high confidence.

To make predictive analytics work, measurement software needs to be pushed further into the network core.  Economics aside, if the problem can be remedied by a carrier sharing partner, that can be done instantly through the operating software (not through a SIM setting).  Anomalies can be detected for individual users and alerts can be delivered.  If the problem was with the provisioning process, for example, the device could be re-provisioned right away (in a nearby store or over the air) or overnight.

The network can be the service expert if issues can be detected quickly.  With the consolidation of device models (e.g., more iPhone 8, X, XR, XS, and 11 models in service than ever before), there’s plenty of correlations to be determined (e.g., Sprint iPhone XR users living in Somerset, Kentucky that have activated service in the last 90 days).  The result of greater analytical capabilities built into the core could result in dramatically lower cost for customer care.

These are two of probably ten or more use cases that demonstrate the value of rewriting equipment operating systems.  This will be an evolution, but not one that is done simply to lower costs – there are many product and customer experience benefits that could create competitive advantage.

TSB follow-ups

Qualcomm Snapdragon 865 chipset specifics revealed.  Increasingly, what’s contained in Qualcomm’s chipsets finds its way into the subsequent generations of smartphones.  If that is true, we should expect to see more camera focus (new chipset accommodates up to 200 MP cameras), 5G networks (full support), and faster displays (supporting up to 144 Hz).  It was also interesting to learn that the Snapdragon 855 would also support Dual SIM/ Dual Standby (more details on that finding from this XDA Developers report here).  As we discussed in last week’s TSB, the Apple XR/XS/ XS Max was the first lineup to support Dual SIM/ Dual Standby – Android development efforts in this area have been slower to emerge.  The Qualcomm 855 should be the turning point and we should see the capability available on new devices in 2020.  According to the XDA Developers article referenced above, they worked with Gemalto to enable eSIM support within the Qualcomm Secure Processing Unit. 

One additional note about the Snapdragon 865 is its support for the Android 11 IdentityCredential API.  This would allow, among other things, the ability to store your driver’s license in Android and it would be accepted as a proper form of identification.  The complete video of Day 2 which has the details on the 865 are here – the discussion of Dual SIM/ Dual Standby starts at minute 31.  The Snapdragon 865 spec sheet is also available here.

DOJ calls out carriers on Remote SIM Provisioning (RSP) collusion

The day before Thanksgiving, the New York Times ran an article describing the settlement between the Justice Department, the GSMA (standards body) and some US wireless carriers (presumably including AT&T and Verizon) over possible collusion surrounding the development of eSIM device locking. 

The Times article is sparse on details – Assistant Attorney General Delrahim’s letter (here), however is not.  Here’s what was found concerning the current RSP process (actual findings – emphasis added): 

First, RSPv2 requires consumer-users to express affirmatively their intent to switch profiles each time the eSIM toggles between profiles or networks, thereby preventing the eSIM from automatically switching (or optimizing) between profiles. Dynamic or automatic switching is a potential competitive threat because it could lead to a service where a device efficiently selects, on behalf of the user, which profile to use in any given situation. For example, the eSIM could switch services if it detects stronger network coverage or a lower cost network, providing consumers with better or less expensive service. The prohibition on automatic switching would tend to prevent at least one existing operator from offering a new innovative service using an eSIM. That is, in order to offer the new service, the operator would have to convince smartphone manufacturers to forego complying with the RSP Specification.

Second, RSPv2 prevents an eSIM from actively using profiles from multiple carriers simultaneously. Multiple active profiles is a potential competitive threat because it would allow a user to divide usage across operators. For instance, the user could actively maintain two profiles on one device if he or she wanted to receive work-related phone calls to one profile and personal phone calls to another profile, all while carrying only one phone. The user could also actively operate profiles optimized for different coverage areas or for international travel. Although there appear to be technical challenges to allowing multiple active profiles at present, the single active profile requirement in RSPv2 serves as a roadblock to additional disruptive innovation that could solve these technical challenges.

The DOJ’s issue was not only with these two outcomes (which are unmistakably anti-competitive), but with the entire approval process used by the GSMA.  Everyone agreed to comply with  new process, and, with the advent of the new Qualcomm 865 chipset described above, it’s likely that switching between networks will be placed as a consumer choice with the opportunity to mute future notifications (similar to the roaming notifications process followed for over two decades) and also to allow multiple networks to be accessed simultaneously (making data network selection easier for cable MVNOs and others while potentially keeping voice on the MNO network). 

Adam Koeppe takes the stage in Vegas (while his boss is on a separate stage in Vegas)

 Given space constraints in this week’s TSB, I am going to keep this excerpt short (perhaps we will cover in another TSB this month), but, if you want to know what Verizon is doing with respect to network deployment, listen to his Well Fargo talk with Jennifer Fritzsche here or read the transcript here.   Adam covers the AWS 5G Edge announcement, fiber deployment strategy, CBRS (and Enterprise LTE solutions pairing CBRS and millimeter wave spectrum bands), Broadband to the home and relationship to cable MVNO, and a few other topics.  Less spin is good for Verizon, and Adam is a “balls and strikes” interview.    

What markets will see the greatest improvement to Sprint/ Boost if New T-Mobile actually occurs?

We had been thinking about this topic for a while, and accessed publicly available RootMetrics data (2H 2019 measures only to be most current in our assessment) to see where the current gap between T-Mobile and Sprint exists. 

To no one’s surprise, Sprint tends to solely occupy fourth place in nearly each of the 125 markets that RootMetrics measures every six months.  How would that performance improve once that Sprint/Boost customer (current device) could access the T-Mobile network? 

To determine the greatest impact, we looked at the difference between Sprint and T-Mobile’s Overall Score (perhaps in a future TSB we will dive into the components).  As of Wednesday, RootMetrics had published the results of 96 out of 125 markets (77%).  The results break down as follows (100 pt scale):

While there may be debate about the impact to customers for the first two levels (device age could play a significant role in a market where both T-Mobile and Sprint are relatively strong), there’s little debate when there’s a spread in excess of 10 points and the market is not one of the previously announced 5G markets.  Here’s a sampling of where Sprint has fallen behind: 

1. Oklahoma.  Below are the most recent charts for Tulsa and Oklahoma City.  ‘Nuf said.

2. Florida.  These are legacy MetroPCS markets for T-Mobile and have very dense coverage.  Miami, which was once a priority market for Sprint (non-executive Chairman Marcelo Claure has close ties to the area), has fallen off considerably and is no longer a competitive market for Sprint.  Other markets with more than a 10 point spread to T-Mobile include Port St. Lucie (12.2) and Sarasota (11.1).  Orlando, Kissimmee, Tampa, and Jacksonville have a 5.1 – 10.0 spread.  The other markets are waiting to report.

The remaining markets are both big and small metro areas:

• Atlanta (fast growing area, large market, 5G market)
• Baton Rouge, LA (been a weak network for Sprint for many years)
• Charlotte, NC (fast growing area and second home to most of the financial services industry)
• Denton, TX (North Dallas suburbs)
• Kansas City, MO (very odd as it’s Sprint’s current HQ and a 5G market)
• Louisville, KY
• Memphis, TN
• Nashville, TN (fast growing area)
• San Antonio, TX (Sprint PCS dominated this market because of its design; large market)
• Wichita, KS

Interestingly, no Northeast, Northwest, Southwest or California markets with large gaps.  We will update this list in January once RootMetrics has completed their 2H 2019 metro studies.

That’s it for this week.  Next week we will begin our discussion of 2020 trends unless events dictate otherwise.  Until then, if you have friends who would like to be on the email distribution, please have them send an email to [email protected] and we will include them on the list.

Have a great week… and GO CHIEFS!