1.

Device-to-device (D2D) communications

Device-to-device (D2D) communication often refers to the technology that allows user
equipment (UE) to communicate with each other with or without the involvement of network
infrastructures such as an access point or base stations. D2D is promising as it is used to
make ultra-low latency communication possible. But who is using D2D and what are the real
applications behind such technologies? In this white paper, learn about D2D and how it
enables fifth generation (5G) wireless network communication from short-range wireless to
vehicle-to- vehicle.
Dedicated short-range communications (DSRC) is often tied with 802.11p, which is the Wi-Fi
standard specific to the automotive industry that leads the next generation of connected
cars. Recently, Volkswagen announced that it will provide WLANp as standard equipment
on all its cars in Europe starting in 2019 [1]. This announcement could create ripple effects
in the industry to promote accident-free driving and, ultimately, autonomous driving.
However, the challenges with 802.11p is that it will only talk to cars that can transceive its
protocol. Although the technology relays information such as the weather update at the end
of a tunnel and other safety-related messages to promote safe driving, it doesn’t work with
cars that don’t carry WLANp.
To support complete autonomous driving, communications via cellular networks are
essential. This new area is often referred to as C-V2X, where “X” is “everything,” such as
another car (V2V), pedestrians (V2P), networks (V2N), and so on. In this white paper, C-
V2X is mainly used to reference LTE-V2X. A major benefit that C-V2X delivers is it uses the
existing LTE network infrastructure, according to the initial V2V standard completion
announcement by 3GPP [2]. It promotes high data rate, high coverage, lower latency with
5G, and so on. Because of such high promises, now virtually every automotive company is
looking at C-V2X as the next “it” technology that will pave the path to complete autonomous
driving.

Figure 1. eNB communicates with multiple UE. In Figure 1, an LTE BS, eNodeB or eNB,
communicates with two UE’s as you know it today with a cellphone tower communicating
with cellphones. In a scenario where the downlink (DL) communication between eNB and
UE #2 breaks, UE #1 relays information to UE #2 so that UE#2 continues to transceive
information without losing any, as shown in Figure 2.

Another benefit in this scenario is that if UE #2 sits at the cell edge where it receives poor
signals, UE #1 helps to provide better signals, which then extends the coverage of the
cellular services.
 2. Device-to-cloud Communication.
ARCHITECTING DIGITAL HEALTH PLATFORMS: Critical success factors for Medical
IoT and Direct-to-Cloud devices

Sophisticated cloud-based architectures unlock new possibilities for innovative digital platforms
that improve patient outcomes efficiently and cost effectively. With the right blend of expertise
and insight, off the shelf platforms can be integrated to deliver healthcare solutions that meet
stringent regulatory requirements
Their Architecting Digital Health Platforms series explores core segments of this dynamic
environment. They unravel the complexity and identify issues device manufacturers may need
to overcome to gain competitive edge. Here, we look at ways to leverage connectivity and
direct-to-cloud capabilities and earn a slice of the burgeoning digital healthcare market.

The top three cloud providers, AWS, Azure and Google Cloud, all offer powerful toolkits to aid
the management of Medical IoT networks. Authentication and monitoring of devices and their
traffic is relatively straightforward. Diagnostics and data management can also be supported to
some extent with standard tooling. Where standard tools fall short, it’s possible to link up with
other cloud managed products, for instance to enhance processing power or data and
diagnostic capabilities. However, selecting the most appropriate tools and components, then
integrating them in the most effective way, demands both technical expertise and sector insight.
The requirements of a D2C asthma inhaler that conveys usage frequency to a remote host
might be quite different from those of a smart device tracking patients’ mobility levels following
hip surgery.

3. Back-End Data-Sharing Communication

In telecommunications, the primary purpose of a gateway is to provide a bridge between
different types of communication technologies. These technologies can vary in terms of
connectivity types, interfaces, or protocols. For example, your Internet Gateway at home
connects your Local Area Network (LAN) with your Internet Service Provider (ISP). This
gateway links the WAN of the ISP through technologies like PPP or HDLC with your LAN with
TCP/IP.
The IoT Gateway follows the same principle of bridging communications for different
technologies. It creates a bridge between the IoT sensors/actuators and the Internet. The IoT
gateway aggregates all data, translates sensor’s protocols, and pre-process the data before
sending it.
The IoT devices connect to the IoT Gateway using short-range wireless transmission modes
such as Bluetooth LE, Zigbee, Z-wave, or long-range like LTE, LTE-M, WiFi, and then it links
them to the Internet (Public Cloud) through Ethernet LAN or Fiber Optics WAN (HDLC/PPP).
The IoT gateway understands these transmission modes and data (MQTT, CoAP, AMQP, DDS,
Websocket) protocols and can translate them to other protocols that the data system’s needs.