Case Study
1&1 vs DISH Case Study
In 2021, major announcements were made about greenfield networks being built on Open RAN technology. In this case study, we look closely at two examples.
Blog
Coding with connectivity: Using the new DISH network APIs
When was the last time a Mobile Network Operator (MNO) let you freely code with its connectivity? That’s right: NEVER.
DISH Wireless CNO Marc Rouanne has a vision to change that by creating an open set of Network APIs that lets anyone—from a single developer or startup all the way to large enterprises—add connectivity to anything, for any reason, with unfettered access. It plans to monetize its network by charging by the API call. Sound familiar?
We’re doing the same thing at Totogi. Creating smart, telco-specific APIs that deliver valuable services, all charged by the use. We think it’s a great idea to create new services, open new revenue streams, and deliver more value to DISH Wireless.
There will be many new ways to “code with connectivity” and a great place to start is in the health industry. Recent years have seen significant growth in both innovation and investment in this field, giving rise to new digital healthcare solutions, platforms, services, and artificial intelligence (AI) to solve medical problems and improve patients’ lives.
Analysts expect better collaboration between CSPs and the health tech ecosystem to accelerate this growth and fuel new healthcare products and services through, in part, the network programmability enabled through API exposure.
Historically, this has been difficult to achieve; while network APIs are not new, they’ve been closed, requiring a big commitment from the buyer to get direct access to the network. Another problem has been concern that a buyer might “go wild” on the network, disrupting the quality of service of the network for other subscribers. As such, it’s made it nearly impossible for developers or startups to add connectivity to a device or service easily. DISH Wireless is looking to change that.
This article details what information these new network APIs expose and how application developers can use them. It also illustrates a healthcare use case where network APIs improve both provisioning and daily usage.
Network programmability features
Some of the most important features becoming available through APIs are service provisioning, location reporting, session quality management, and enhanced monetization and cost controls. Let’s look at each one in turn.
Service provisioning
Activating a new device on a carrier network, or service provisioning, may seem like a basic capability, but it hasn’t been easy to do. Enabling provisioning dynamically through APIs will give application developers much greater flexibility than they would otherwise have, such as:
- Subscription management: The ability to activate, update, or disable a subscription can be used to manage accounts dynamically, and save account balance by provisioning the subscription at a specific time. For example, if a remote monitoring device uses a cellular subscription, the device can be enabled only when it is activated for an end user.
- Subscriber profile management: With the ability to retrieve information related to a user profile, an application can make better logic-based decisions. Available information might also include SIM, device, or number management.
- Network coverage: This type of information can be very relevant to application providers that need connectivity with the end user device at specific times—a critical app that needs constant connectivity, for example. App developers can use information about the network coverage in specific locations to facilitate decision-making or route planning.
Location reporting
Healthcare application developers use location reporting to link a location with the measurements taken by remote monitoring devices, such as oxygen monitors or glucose monitors, or to retrieve the last-known location for unreachable patients.
Additionally, services could be dynamically adapted based on a device’s location. For example, if a patient wearing a health monitoring device left a designated area, the movement could trigger a notification to caretakers, or different behaviors in the device itself.
An application could take health measurements more often when outside of a patient’s home because their situation could be considered more at risk. Subscribing to the network’s location reports, rather than installing a global positioning system (GPS) chip in the device, simplifies the hardware architecture, saves energy, and keeps costs low.
Session quality management
Many use cases in health tech require reliable network connectivity with low latency and some minimum throughput requirements, i.e., anything involving a live procedure, such as taking measurements and instructing specific actions. A standard connection might not meet these conditions, especially in crowded urban areas. Network APIs would allow health tech service providers to programmatically adjust the priority of their connections via an API call. CSPs have the ability to insert quality-of-service profiles that adjust speed and latency at a device or subscriber level. The new APIs put this control into the hands of developers, which they’ve never had before.
Monetization and cost controls
New connected devices are being bundled with the network connectivity required to deliver service, and some developers are metering usage on each device for accounting purposes. Carrier networks use charging engines to track usage of network resources attributed to devices and subscribers. Health tech developers interested in metering network usage at a device level based on the plan their customers have subscribed to should look for charging APIs, like the ones offered by Totogi, that enable them to add charging to their account. Once in place, developers can configure different data plans, assign customer devices to the plans they’ve purchased, and offer differentiated plans for additional revenue streams.
A real-life scenario: remote glucose monitoring
To illustrate the benefits of using network APIs, let’s consider a real-life scenario. Remote patient monitoring has increased dramatically in recent years due to advancements in technology and the challenges brought by the COVID-19 pandemic. The most common devices are blood pressure monitors, pulse oximeters, scales, and glucose monitors. Remote monitoring services are now more accessible to the general public and are also part of medical reimbursement programs around the globe.
For this example, we’ll focus on continuous glucose monitors, as they’re increasingly common for diabetes, obesity, and weight-loss management. Tracking glucose levels and having real-time results gives both patients and medical providers the information they need to assess the body’s response to different activities and treatments. We’ll also use a 5G-enabled device to better illustrate how having data from the network can make these devices easier to provision and use.
Bluetooth devices versus 5G-enabled devices
There are two types of solutions for connecting the device to the internet and the health tech application that manages the remote monitoring.
- Bluetooth devices must be paired with a patient’s smartphone and use the phone’s connectivity to send data. Usually managed through a mobile app installed on the smartphone, these devices have benefits and drawbacks. On the plus side, they can add information from the smartphone, such as location information, along with measurement data. Conversely, provisioning the device and app in the smartphone often isn’t straightforward and might prove difficult for elderly or disabled patients.
- 5G-enabled devices have their own connection to the cellular network and should have a SIM or even better, an eSIM, making them essentially ready to use immediately after patients receive them. Having an independent measurement device makes it easier to use and allows you to send measurements to an app even when the smartphone battery is dead. By using network programmability features, health tech application providers can mirror some of the advantages of Bluetooth devices and even build on them to offer more complete services.
User onboarding: Easy, cost-effective provisioning
For our purposes, we’ll make the healthcare application provider the owner of the mobile subscription for the glucose monitor. This setup allows the company to offer “monitoring as a service” with instant availability for the patient. Subscription activation is a very good example of how, by using the available APIs, the healthcare application can optimize both the customer experience and overall costs.
Jane visits her healthcare provider and receives a glucose monitoring device with a SIM, onboarded to the healthcare app for her by the healthcare provider. By using network APIs, the app provider can include subscription activation as part of the patient onboarding process, saving costs by not having to activate the subscription any earlier than necessary. The app provider can also update or disable the subscription easily from the healthcare app.
Let’s look at the flow of the provisioning process.
First, the application will need to authenticate with the API gateway (GW). Applications usually authenticate by using the application ID information and a secret key generated by the API GW during app registration. After authentication, the API GW sends an access token to the app that it can use to authenticate the subsequent API calls.
For the provisioning call, the app sends the API request for activating the subscription together with parameters like subscriber ID, application ID, the products to be activated, and, of course, the access token for authentication and authorization.
Next, the API GW authenticates the request, verifies that the app is authorized to send the request for that specific subscriber, and forwards the request to the business support system (BSS). The BSS transparently manages the subscriber’s activation and then confirms it to the API GW, which sends the confirmation to the application.
Daily usage: Adding location information via a network API
After provisioning, the application will be able to interact with the network to retrieve information relevant to the service. Since our example uses a cellular-enabled device that is not tethered to a smartphone, there’s no way to augment the medical data together with the location information from a nearby smartphone’s GPS. Adding a GPS tracker to the device would solve the problem, but that upgrade would also add to the cost and battery consumption needs, making it bulkier and more expensive.
A network API can elegantly solve the dilemma, securely offering this important location reporting to an app—a new, potentially life-saving feature—without adding cost or weight.
Part of the onboarding includes entering Jane’s home address, so that the app can subscribe to a location report and receive a notification each time Jane goes out. The app can remind Jane to “grab a banana—you’re looking low” or “remember your insulin—you’re trending high” as Jane leaves her home. Or if the measurements warrant immediate medical attention, Jane’s emergency contacts can be alerted with her current location, regardless of her phone’s battery state.
The flow for requesting location reporting is similar to the one for provisioning.
If you want to learn more about the DISH Wireless network API offerings, sign up for the DISH Wireless Alpha Developer Engagement Program to take them for a test drive!
