For a long time, professional-grade, real-time media transport, processing and monitoring functionality was provided by dedicated hardware. If additional functionality was required in the network, a “box” would be purchased that specifically performed that task.

This dedicated hardware approach made technical sense because of the amount of processing required, as well as the need for low latency, high reliability and minimum power consumption. However, this was inflexible and not always cost effective.

The trend for high-tech equipment in many industries has been a progressive move from dedicated hardware to specialized platforms running software, and then onto COTS (Commercial Off-The-Shelf) IT hardware, such as servers based on X86 CPU architecture, running software applications. For real-time transport, processing and monitoring of media signals, the concept of software-defined platforms is now becoming established. The question is though: how suitable is COTS for live broadcast production?

Intuitively, a COTS approach makes sense, as IT equipment is ubiquitous, open and proven in many environments. Despite some initial hesitancy in the industry, we are beginning to see media processing products appearing that are based on COTS.

OVERCOMING THE CHALLENGES

Currently, COTS products for live media transport, processing and monitoring still only provide limited functionality compared to leading software defined platforms. Before it is possible for COTS hardware to be used for all aspects of live production there are several technical challenges that the industry must firstly work to overcome.

But what exactly are these challenges and what could overcoming them mean for the role of COTS hardware in live production in the future?

Performance

At this stage, the main obstacle to using COTS hardware is its real-time processing performance. While it can handle applications—such as audio processing—that involve flows under 10Mbs reasonably well, it can be less efficient with higher rate flows, such as those required for real-time video encoding.

However, developments are taking place that will help running video processing applications on COTS platforms. Firstly, we are beginning to see newer generations of standards, such as JPEG XS encoding, that have been designed from the ground-up for software processing. Secondly, and more fundamentally, chip vendors, such as Intel and Xilinx, are launching or already offer new “generic” FPGA acceleration boards.

The NICs (Network Interface Cards) used for stream acquisition can also be a processing bottleneck. To get the performance needed to handle very high volumes of data in real-time, it helps if the NICs can communicate directly with the FPGA, rather than via the CPU and memory. Vendors such as Mellanox have developed NICs designed to optimize the throughput to the processing functions.

It is worth noting though that a contributing factor to some of the perceived inferior performance on COTS is poor programming; for example, it is too easy to add buffering to solve problems rather than address them in a way that keeps latency down. Lean and efficient code is key to powerful and scalable media functions implementation.

Packet Pacing

Traditionally, professional media transport has been linear in nature, meaning that the output of equipment utilizes a constant, defined bit rate. In IP terms, this means that packets are transmitted at a constant and steady pace.

COTS equipment is inherently nonlinear, which is a challenge to broadcast orthodoxy. Typically, the software and hardware—due to the resource scheduler—will natively try and push out as much data onto the network as quickly as possible, without any consideration for pacing.

The problem with nonlinear transmission is that bandwidth usage becomes very unpredictable and timing consistency cannot be maintained. And in real-time applications, where packet delays are unacceptable, there should always be enough bandwidth to accommodate all possible flows and keep an accurate packet pace.

The nonlinearity of COTS devices creates the need for substantial additional bandwidth, which is largely unused most of the time and is not desirable economically.

Consequently, the prevailing view in the industry is that COTS-based media applications should be developed in a way that paces packets more carefully.

Power Consumption

CPU-based COTS devices have noticeably higher power consumption than bespoke hardware or software-defined platforms based on FPGAs. In some production environments, such as OB vans or remote sites, this can prove to be a challenge.

Over time, COTS power consumption is likely to be reduced, as generic systems introduce FPGA acceleration.

It is also likely (though not necessarily desirable) that broadcast environments will become more accommodating of the extra power needed for COTS.

DOES THE FUTURE LIE IN COTS?

There is no doubt that, for most real-time broadcast media transport, processing and monitoring, the best approach currently is to use software-defined platforms, built on hardware optimized for performance.

While truly generic COTS IT hardware running software is not yet a viable option for many applications—especially video processing that requires very high bandwidth—it is already being used successfully for some applications. Therefore, as technology continues to evolve and is capable of overcoming the challenges and limitations outlined above, it is likely that COTS will be suitable for use in all aspects of real-time broadcast production.

Olivier Suard is vice president of marketing for Nevion.

At this point in the technical evolution, we’re firmly in what might be called the “cloud computing era.” Yet, there is a somewhat interesting and possibly equally mysterious transition that is changing the location and the value proposition of the cloud.

Many of the new applications thought to be ideal for cloud computing may actually be occurring closer to the source of the data, that is at the “edge.”

At the personal level, many of us use products and services that are powered by intelligence that is found in the cloud. We place content in the cloud and we pull content from the cloud. These well-known products include those from Google (Chromecast), Amazon (Echo) and Apple (TV). Centralized services are familiar to many—those by Gmail, DropBox, Adobe Creative Cloud and Autodesk AutoCAD. These organizations use cloud services to store, backup, protect and interchange data and are always looking into new methods to achieve better security, decrease latency and reduce internet bandwidth traffic.

The “edge” is a relatively recent buzzword; similar in context to the cloud and the Internet of Things (IoT). Maybe “the edge” is not yet as familiar as AI and VR/AR, but it has similar importance to other technological capabilities that circle our universe and impact our lives on a daily basis. And people trust these services—we allow them to routinely collect our data and utilize it in ways that we can’t possibly manage ourselves. We let these companies “own” that data (unless you’re doing the GDRP thing), and we recognize that it’s literally impossible to halt the external/additional uses of our data due to myriad reasons, privileges or end-user-license-agreements (EULAs) that we graciously sign and accept before landing a single piece of data in their repository.

CLOUD DEPENDENCY

A significant number of companies have openly adopted the use of the cloud and rely on the hosting, machine language (ML), infrastructure and the power offered by the cloud. Nonetheless, the use of the cloud—as expected—continues to ebb and flow with the needs and capabilities of the technology ecosystem. Fundamentally, because of evolution, compute and other dependencies, we are beginning to see that certain functionalities and capabilities are now moving from the “public” cloud to what is known as “the edge.”

To see where this is headed, we start by looking at what “the edge” and “edge computing” is about. Basically, edge computing are those computational properties that are performed or “live” as close to the source or information gathering points of the data as is possible or practical.

But why do this when the cloud can do this work, probably faster and more efficiently than at the edge? There are multiple reasons and rationale for this, some influenced by technological evolution and others because the ecosystem, in whole or in part, allows this to happen.

PRIVACY

Families, institutions, enterprises, small businesses and individuals are increasingly more concerned about data privacy (and piracy). Many of you have likely had your credit card hacked at least once. While we may trust the cloud, and the firms providing the service—one can only wonder not if, but when something will be compromised.

If only the least amount and most applicable data needed is sent to the cloud service, then certain (unknown) risks might be mitigated. If only that data that absolutely needed to go to the cloud were encrypted locally, contained a biometric key and was sent over a protected channel—possibly using blockchain technologies—the user could feel better protected. To do this means that some of the compute process should be brought to the edge.

At least one major smartphone manufacturer does just that. They brought what was once only available as cloud-based computing out to the edge, creating a powerful change in how compute power is distributed.

SECURITY

We’ve heard about poorly managed IoT devices because the processing needed at the source was either absent or relegated to a location that passed through other less secure channels (e.g., the public internet) before reaching the cloud service-center destination. Today, browsers located at the edge, which have moved to the “evergreen” model, are finding success when employing edge computing principles in terms of increased security and better use of bandwidth.

“Evergreen” refers to services that are comprised of components that are always up to date. Evergreen IT encompasses services that are employed at the user level and at all the underlying infrastructures, whether localized, at the edge or in a cloud. Edge computing can help manage security by bringing only the needed information to the (public) cloud. Browser and cloud providers are working on OS and certified microcontrollers that will manage the types and depth of information that is cloud-bound.

BANDWIDTH

Proponents of edge services (for computing) believe that bandwidth can also be saved. That is, the bandwidth needed when to get every piece of data from host (user) to the cloud can be reduced if some or much of the compute efforts are done before going to the cloud. Artificial intelligence is helping to enable this. Say for example, in a camera security model, you are monitoring only one source (i.e., one camera) and carried only that full image to the cloud; there might not be much savings by edge “computing.” However, if you have several sites (i.e., multiple cameras), you could gain substantial bandwidth savings by combining the data—as smaller images from each of the individual cameras—into a single multiviewer and then transporting a single “composite” image to the cloud.

If you added AI at the edge to detect, for example, any movement—as in a motion detection security function—and only then switch the camera from one of several images on a screen to a single, full-screen size—then you’ve eliminated issues with having to continually look at every image as well as send only what is needed to the cloud for storage or other functions. Once any movement stops, the multiviewer reverts to all the cameras on a single raster. The AI function might also cache the other non-active images to a local (memory) store and hold it until reviewed by the user later.

LATENCY

Issues associated with bandwidth utilization may also be equated to minimizing latency. Major data information companies such as Google and Apple are working hard to localize the compute issues using AI to help control bandwidth and data-traffic demands. Furthermore, if you use “off-line first” techniques—i.e., you open the app on your mobile device without first connecting to the internet—then you conserve bandwidth without compromising performance.

Pay attention to these up and coming active changes when you consider IoT for your home security system or other monitoring features including thermostats, fire detection, etc. When appropriately managed, edge computing solutions aided by AI can help control security and return answers faster and more reliably.

Karl Paulsen is CTO atDiversifiedand a SMPTE Fellow. He is a frequent contributor toTV Technology, focusing on emerging technologies and workflows for the industry. Contact Karl atkpaulsen@diversifiedus.com.

ALEXANDRIA, VA.—Broadcast facilities are now commencing what many believe will be a global transition from current digital (SDI) infrastructures to an all “IP-based (network)” facility. Not since the migration from analog to digital in the 1990s, has the industry experienced such a change.

On the surface, the transition seems logical, expected, and maybe even straightforward, given the level of IP/IT-integration already present at many facilities. Yet under the hood, both IT and broadcast technical professionals are in for a paradigm shift in concept, facility design and support practices.

This two-part article discusses the issues associated with next-generation IP-based facility design. The topics are not going to detail the transport of media over long distances nor the practices involved with file-based workflows, storage transfers or even OTT—which all use components of IP in an IT-domain. Instead, this article explores what broadcast and IT professionals will need to know about their future commitments to next-gen network-centric infrastructures.

CURRENT IP MEDIA PRACTICES

Professional media environments provide multiple means for moving video (i.e., compressed-files or streaming media) from point A to point B. Those points might be across the campus, between cities, to arbitrary distribution points—or anywhere between. In most applications, signal transport of the audio/video is a compressed video format of which there are dozens available. Some formats are highly compressed for Internet delivery and others are mildly compressed contribution- quality, e.g., from sporting venues to studios or for production integration prior to broadcast.

Manufacturers’ products for compressed media transport prepare the data for the subsequent stages in the content production chain. Few (if any), provide a means to transport uncompressed, high-bit rate content end-to-end over the network. This article doesn’t address the discussion for the absence of this form of transport.

With that preface, we’ll focus on the latest applications for high bandwidth, real-time, live broadcast production using IP over a media-centric network.

HIGH BIT RATE–UNCOMPRESSED VIDEO TRANSPORT

Broadcast production is beginning to use new capabilities for the transport and manipulation of high bit rate (HBR), uncompressed (UC) signals over an IP-network topology. These applications are specifically for live/real-time production activities. Recent SMPTE standards (ST 2022-6 & -7 and ST 2110 published year-end 2017), alongside industry forums and initiatives are driving new technological efforts that will reshape the broadcast facility.

“Internet Protocol” (IP) network technologies are already in use at many media facilities. The approaches are applicable to file-based workflows, data migration, storage and archive, automation and facility command-and-control. Previously, these weren’t necessarily called “IP.” Once the capabilities for UC/HBR video transport came about; that nomenclature evolved. Now, it seems, “everything” is IP, irrespective of how that terminology is applied to which application.

With that said, we’ll set the stage for what is happening in the future, and that ‘future’ is now.

RULES OF ENGAGEMENT—IT CHANGES EVERYTHING

IP is a “set of rules (“protocols”) which govern the format of the data sent over the internet.” For broadcast or studio facilities, “internet” is more appropriately called the “network.” Essentially, the application of certain constrained IP technologies will fundamentally address the facility infrastructure changes associated with studio/ live media-production and their content-chain processes going forward.

Designing and building an IP facility will require a renewed technological approach to IT-networking accompanied with a new mindset compared to those for traditional SDI-facilities. To comprehend what it takes to design, build and operate the IP-based professional media facility, an understanding of what “real-time” (RT) IP is and how it is differentiated from conventional SDI implementations (including file-based workflows or data storage) is necessary.

One key-target in this will be to keep “audio and video (over IP networks) acting precisely the way it does in an SDI-world” without the burdens or constraints of traditional SDI infrastructures. Fundamentally, facilities will leverage the advantages of network-based IP/IT structures for agility, flexibility, cost, and extensibility/expandability.

WHERE ARE THE DIFFERENCES?

SDI, born out of standards from the 1980s, was intended to permit transport and synchronously switch audio/video from source to destination without disturbances and to mitigate the generational quality issues associated with analog video and audio. The isochronous nature of SDI is straightforward for live, continuous video inside the studio and for long distance transport. However, these capabilities are not as easily accomplished in a file-based, non-real time, or streaming media environment.

Frame-accurate (undisturbed) transitions with compressed video, while somewhat possible in streaming media, is generally accomplished using peripheral equipment which essentially receives compressed video, then decompresses it to a “baseband” (SDI) form, where then seamless transitions from A-source to B-source are completed (Fig 1). Resulting signals may again be compressed to another format depending upon the application.

[Read: SDN: Not Just Another Three Letter Acronym]

These processes each take time, adding latency to the non-real-time chain. It is impractical for most live applications to cleanly switch sources and maintain timing and synchronization.

Program videos on YouTube or Netflix leverage sophisticated receiver buffering techniques or will make use of adaptive bit-rate (ABR) streaming functions to keep their “linear delivery” as seamless as possible to viewers. However, the ability to provide live and glitch-free source-by-source video possible is curtailed due to GOP (group of pictures) issues and compression/decompression latency.

For professional media IP systems—real-time/live signals, on a network, are transported over isolated, secondary or virtual networks (VLANs). For live and real-time, HBR signal transport, new network topology and timing rules must be adhered to. These “rules” (protocols) are defined in SMPTE ST 2110 and/or ST 2022 which include applications of IETF RFCs as defined in the new standards.

DIFFERING DATA TRAFFIC STRUCTURES

Another key point in understanding next-gen facility design is that differing data traffic types are not (generally) mixed on the same VLAN/network. Packet structure and formatting is different per each data type’s intended uses.

Real-time transport networks are conditioned to carry HBR traffic. Packets from senders (transmitters) are constructed based on IETF RFCs (Fig. 2) such as “real-time transport protocols” (RTP) and “session description protocols” (SDP); and supporting IEEE and SMPTE standards. Coupled with conditions identified in the SMPTE ST 2110 or ST 2022 standards— timing, synchronization, latency and flow control is managed so that the transport of media packets over professional media networks is possible.

One differentiator from previous IT-like network designs is that HBR traffic must run continuously at non-wavering data bit rates. File-based and streaming media is intended to, or can run at variable data rates. The data is likely to be randomly delivered and is often “bursty” in nature. In file-based transport, data from senders need not “arrive” at receiver input(s) in an isochronous (time bounded) nature. Streaming media acts in a similar fashion with fluctuating rates that are stabilized at the receiver end. Buffer sizes, connectivity bandwidth and variable file-data rates are accepted in these applications—but cannot be tolerated in real-time HBR applications.

In streaming media delivery, occasional interruptions or “buffering” is expected. That is a non-starter for live real-time video which must be synchronously time-aligned to allow for real time seamless switching.

Thus, a major difference in facility design is in how the various “network” segments are thought of. With that said, we’ll set the stage for what is happening in the future, and that “future” is now.

System designs now include distinct considerations for real-time and non-real time signal flows. Real time management and flow control associated with the endpoint peripheral devices must be “orchestrated” and will differ from non-real time delivery. File-transfer, storage and/or file-based workflows will likely reside on a different, less constrained network (segment).

Part one has now introduced broadcast and IT professionals to the differences and conditions associated with IP-centric professional media transport for studio and live operations. In part 2, we’ll discuss how next-gen design for IP-facilities differ and what engineers will need to know about their future in a multicast IP world.

Karl Paulsen is CTO at Diversified and a SMPTE Fellow. He is a frequent contributor toTV Technology, focusing on emerging technologies and workflows for the industry. Contact Karl atkpaulsen@diversifiedus.com.

In an era of cybersecurity intrusions, Next Gen TV developers are looking at how to secure the all-IP ATSC 3.0 signals, which are a potential delivery vehicle for Internet of Things (IoT) services. Whether to fixed devices in the home, smart cars in transit, wearable products, public-space advertising or “smart city” capabilities (such as transit routing and in-vehicle infotainment), local opportunities abound, as IoT enthusiasts continue to demonstrate.

Although the emerging fifth-generation (5G) wireless technology is angling for a dominant role in IoT applications, some broadcasters see significant roles for Next Gen TV—and they recognize that security and privacy are crucial to establishing IoT services.

In addition to the wireless telco visions for IoT, Dish Networks is expected to use its spectrum assets by building a dedicated IoT network. When Dish Co-founder Charlie Ergen resigned as CEO in late 2017, he said he’d concentrate on building a NarrowBand IoT (NBIoT) network using spectrum Dish acquired in a $6.2 billion spending spree that created a near-nationwide footprint in the 600 and 700 MHz bands.

Kevin Gage, executive vice president, strategic development and chief technology officer at Sinclair-owned ONE Media LLC, told TV Technology that medical data companies have approached ONE Media “looking to pair with 3.0 to develop hybrid solutions” for keeping in touch with IoT sensors, monitoring devices and other applications. He said it was especially encouraging that new ventures are looking to broadcast bandwidth for spectrum solutions.

“We haven’t had a robust start-up community in broadcasting,” Gage observed about the legacy relationships of TV stations. “Our goals with 3.0 are to support the security needs of any new business or industry that wants to make use of 3.0 as a delivery or communications service.” He emphasized that ONE Media’s objective is to “adapt already proven and approved security solutions from new industries to 3.0.”

‘INTERNET OF THREATS’?

At the same time that the IoT business cases are being built, legislators and regulators—from Capitol Hill to the Federal Trade Commission to the National Institute of Technology and Standards, among others—are accelerating their efforts to figure out how and what they should do to assure secure use of IoT systems. On overlapping days, NIST ran its second annual workshop on “enhancing resilience” of IoT and other parts of the “communications ecosystem” while the FTC’s third annual PrivacyCom conference again featured warnings about smart TVs in the privacy/security scenario, Barely a week earlier, Sen. Ed Markey (D-Mass.) and Rep. Ted Lieu (D-Calif.) were talking up their Cyber Shield Act of 2017 (S.2020 and H.R.4163) at a Capitol Hill seminar sponsored by the American Enterprise Institute.

Collectively, the policymakers explained that they want to make sure consumers can trust IoT products and services. Markey and Lieu’s legislation would create a voluntary cybersecurity “seal of approval” (probably administered through the Commerce Department) for IoT devices; one objective is to create product labels (physical or digital) to show consumers that products—ranging from baby monitors to phones, laptops and other networked items—are safe from intrusions.

At the AEI event, Markey warned that every IoT device (which he repeatedly called “Internet of Threats”) is “something that can be compromised ... in ways that people don’t think about but they should.” He said the proposed legislation would “create a roadmap of improvements for manufacturers and their devices.”

SPECTRUMCO AFFIRMS NEED FOR SECURITY

SpectrumCo LLC President John Hane acknowledged that “some IoT applications require extremely high levels of security.”

“We expect to support industry standard security and authentication protocols, and proprietary solutions of our customers,” said Hane, who in February was hired to run Spectrum Co., LLC, the ATSC 3.0 spectrum consortium founded by Sinclair Broadcasting Group and Nexstar Media Group.

Hane said SpectrumCo’s platform will be able to enhance security in several ways. “One of the biggest challenges of IoT security is updating the firmware of so many devices in so many locations,” he said. “As vulnerabilities are found, they have to be patched, and fast. SpectrumCo’s low-band broadcast platform will allow our customers to update devices at a small fraction of the cost of cellular updates. Even where wireless or wired connections already exist, a redundant path can provide an additional layer of security.”

READY FOR IOT CYBERSECURITY CHALLENGES

Against this backdrop and the growing promise for IoT systems, ATSC 3.0 developers believe the new standard is ready to handle security challenges, according to technologists who have worked on Next Gen TV.

“ATSC 3.0 specifies use of encrypted data on the internet," said Adam Goldberg, principal of AGP, LLC and chair of the Technology Group 3 Specialist Group on ATSC 3.0 Security. “It also specifies use of cryptographic code signing which allows devices to verify that software updates (or other software) was created by trusted parties and not by hackers.”

Goldberg also pointed out that the 3.0 standard’s A/360 (“Security and Service Protection” layer) calls for use of Transport Layer Security for encrypted internet communications, “with an eye toward greenfield implementations.”

“This is useful for IoT,” Goldberg added because A/360’s code signing “is rather vital for IoT” implementations such as online updates.

Dr. Richard Chernock, chief science officer of Triveni Digital and chair of Technology Group 3, which guided 3.0 creation, also acknowledged the potential massive scale of IoT.

“IoT implies the need to communicate with a very large number of devices,” Chernock said. “When the same information needs to be sent, then broadcast economies-of-scale come into play. Sending common information to millions of devices takes no more resources than sending to hundreds of devices. This is useful for things like firmware updates.”

CHALLENGES EXPECTED

At the NIST workshop, Lisa Carnahan, Manager-Interoperability Group at NIST’s Information Technology Laboratory, urged the IoT industry to identify a model to manage and reduce cybersecurity risks, focusing on the need to align IoT security with consumer expectations and other market considerations. Warning that “the alternative is regulation,” Carnahan emphasized the value of inter-industry collaboration to understand and agree upon the approach to security protection.

Overall the NIST workshop focused on botnet threats and was part of a “conformity assessment process” as the agency prepares a report to the White House on automated threats to IoT and other systems. Other NIST speakers emphasized that the government prefers voluntary industry protections rather than regulatory mandates.

Chris Boyer, assistant vice president for global public policy at AT&T, urged the industry to create security guidelines for IoT devices, modeled on another NIST framework for cybersecurity standards. He cited the “need to do something similar to what we did for the NIST Framework for IoT, that we can promote internationally.”

“I think it’s very important to get our arms around how we deal with IoT in the U.S., because other countries are aggressively pursuing IoT standards and guidelines,” Boyer said.

As with many IoT conferences, the NIST program eventually moved toward the “liabilities”—that is, who in the value chain would bear the burden of problems created by IoT flaws or security intrusions.

[Disney Studios Partners With Accenture to Assist With StudioLAB]

Meanwhile, the Consumer Reports/Consumers Union presentation focused less on IoT than on other data-related aspects of TV technology. The presentation repeated the CU mantra that there should be greater protections from the data-collecting capabilities of smart TVs.

Katie McInnis, Consumers Union’s Washington office, explained that, “as more consumer devices contain smart or connected functionality, these devices may collect or share information in ways consumers may not expect — or otherwise limit or compromise a consumer’s control over their purchases.”

She also offered a peek at the results of the television study that Consumer Reports Online will publish later this year.

“While we will not be scoring the televisions using traditional Consumer Reports ratings,” McInnis said in prepared remarks, “we will indicate which televisions performed generally better or worse according to our metrics.”

At the AEI seminar, Rep. Lieu also called for a cautious approach to IoT regulation.

“The reason we’re not very specific in this statute is [because]... when it comes to technology, government should have a very light touch,” Lieu said, emphasizing his expectation that that industry will “self-regulate.” He explained that the voluntary program established by the proposed legislation would rely on a commission of diverse experts to set standards.

Gary Arlen is president of Arlen Communications LLC, a research and consulting firm. He can be reached atwww.ArlenCom.com

For a comprehensive list of TV Technology’s ATSC 3.0 coverage, see our ATSC3 silo.

: