The last edition of this column talked about subnets and introduced folding paper as an illustration of how subnets can be understood. This will be very useful as we proceed. 

MORE IPv4 SUBNETTING BASICS

Consider an analog clock. Start the second hand at 12:00 and follow it clockwise around the dial. At 12:00, 60 seconds have passed. Zero seconds and 60 seconds are the same place on the dial. When the second hand gets to 60, the minute hand has moved one minute. Since we keep track of time in minutes and seconds, we usually think of seconds from zero to 59, then at 60 seconds we re-set our seconds count to zero and add a minute. It’s like counting from nine to 10, where we increment the tens column when we pass nine. 

It’s like that looking at IP and subnet octets. We can go from zero to 255 in each octet, but 256 means the octet is filled. We don’t have room for 256, because 255 is the limit, i.e. all binary bits are set to 1. When we hit 256, the octet changes to zero and we increment the octet to the left by one. 

At home, your computer might have an IP address like 192.168.1.10. For this address, your subnet mask is probably 255.255.255.0. You decide you want two networks. Doing the mental math, you say “Two networks from one means one fold of the paper.” Each fold of the paper is a bit borrowed from the host address field. Here, you borrow one bit. That means you need to change your subnet mask. Here’s how that works: 

You started off with 255.255.255.0. In binary, that’s all ones in the first three octets. To borrow, you need the first bit in the fourth octet. Here’s how it works: 

11111111.11111111.11111111.00000000 is 255.255.255.0. This is where you start. You borrow the first bit in the fourth octet. The new subnet mask is 11111111.11111111.11111111.10000000. 

Borrowing Table 9 from an earlier article and revising it to show the borrowing, here’s the new fourth octet:

The first bit in the fourth octet has a decimal weight of 128, so the final octet of the new subnet mask changes to 128 in decimal notation. The new subnet mask is 255.255.255.128. The way the computer sees it, this is 11111111.1111111.1111111.10000000. Since the fourth octet is where the edge of the subnet is defined, it is the critical octet here. 

Hint: It is valuable to know the correlation of decimal weights (DW) of eight bit binary numbers with subnet masks (SM) values. To do this, let’s look at another table.

This is a good table to memorize, or to be able to regenerate at will. The SM row shows the succession of subnet mask numbers as each bit is turned on. In subnetting, we’ll be using this table a lot.

Now that we have two subnets, we have to know where each subnet starts and ends. The increment dividing one subnet from the other is the Decimal Weight from Table 11 associated with the subnet mask. In this case, note that with the subnet mask (SM) being 128, the Decimal Weight (DW) is also 128. This is also the increment between the subnets. 

We know the first address in the first subnet is 192.168.1.0. This is the network IP for the first subnet. Let’s write that down as the first “Net IP.” Adding the increment, we get 192.168.1.128, the starting address of the second subnet. Next, we need the “Local Broadcast Address” for the 192.168.1.0 network. The largest number we can use without stepping on the 192.168.1.128 space is 192.168.1.127. This is the Local Broadcast Address, or LBA. For the 192.168.1.128 network, the LBA will be the largest number we can use without stepping outside the original network space. We’ll write down 192.168.1.255, meaning all bits in the fourth octet are full. 

Now, we can do the math to find the available addresses in each subnet. These range from one higher than the Net IP to one less than the LBA, so we write them down in the middle column. Think of the Net IP and the LBA as the cookies and the Valid IP Addresses as the filling.

The valid IP addresses may be assigned to nodes in the network.

Click on the Image to Enlarge
Click on the Image to Enlarge

Even as a mature, diverse and reliable technology—magnetic spinning disk drives (aka hard disk drives or “HDDs”) continue to grow in capacity, performance and cost benefits. Alternative storage solutions, however, continue to evolve. Hot on the HDD heels—as has been the case for more than 10 years running—are a family of solid-state equivalents.

SSDs (solid-state drives) now sit squarely alongside the other legacy nonvolatile memory solutions, and their presence is being enhanced by interface improvements known generically as non-volatile memory express or NVMe. 

Storage media itself, such as Flash Memory, have seen a multitude of improvements centered on many technological advances. My previous columns have outlined those changes over the past decade. Now we see new steps to improving non-volatile memory solutions, which are in the interfaces themselves.

HDD EVOLUTION

Of the various interface forms for HDDs, those with serial Advanced Technology Attachment (SATA) interfaces

have become the more cost-effective and most prominent of the “everyday application” disk drives. The more expensive serial-attached SCSI (SAS) drives buy the users other capabilities.

When it comes to HDD applications, SAS drives tend to be found more in enterprise computing because of their high speed and high availability, factors crucial for such activities as ATM transactions, stock exchanges and eCommerce. 

Conversely, SATA drives are used primarily in desktops for consumer use and in those less demanding roles such as backups and near-line data storage.

We are omitting Fibre Channel disk drives from this conversation because they are more specialized and less cost effective, but can arguably be justified in high-performance storage applications (such as editing systems) when supported by the appropriate operating and file system technologies.

IOPS AND RELIABILITY

Keep in mind that the best measure for HDD speed is IOPS (inputs/outputs per second), specifically when the drives are in use, under stress and with real applications designed to optimize the drives’ capabilities.

To put IOPS into perspective, industry-accepted averages for 7.2K SATA drives is about 80 IOPS, with the 10K (RPM) devices offering around 120 IOPS and 15K pushing the limits of around 180 IOPS. The equations turn dramatically for solid-state storage devices (SSS), with huge IOPS improvements and no mechanical worries. 

The other factor for SAS v. SATA is reliability. The industry-acknowledged MTBF (Mean Time Between Failure) for SAS HDDs is around 1.2 million hours, compared with 700,000 hours MTBF for SATA drives. This also places SAS clearly into the enterprise space.

Once you move from the HDD world to the SSD world and to other forms of non-volatile memory, the feature sets and interfaces begin to shift. Not only will speed (performance) increase, but the applications for which SSDs can be applied to help increase total system performance—not just from the storage I/O perspective.

Table 1: Some familiar, but less recognized non-volatile memory (NVM) types.

Non-volatile memory (NVM), sometimes called NVS (non-volatile storage), is a classification for a form of digital storage (memory) that retains its state without having power continually applied. Generally, this storage media is without any mechanical components, although that is not necessarily the case.

Optical storage is considered in the NVM classification, as would be any readonly storage that doesn’t require electrical stimulus to retain its state (e.g., a PROM/EPROM). See Table 1 for examples.

Initially, NVS and NVM were intended for secondary storage or for other longterm persistent storage mediums. Today, in its SSD format, it is often used for primary storage to support short-term RAM/DRAM—as in laptops, tablets or mobile devices.

INTERFACE EXPRESS

Besides the physical storage media, electrical and software interfaces are needed to support the “NVM-storage” term. Common interface methodologies include Non-Volatile Memory Express (NVM Express or NVMe) and NVMe over Fabrics (NVMe-oF or NVMeOF). See Fig. 1 for an example of one method for the physical interface.

The “NVMe” term mystifies many, with some feeling these terms are becoming more hype than practicality. We hope to provide some clarification with the following.

NVMe is a host controller interface and storage protocol established to accelerate the data transfer between host/enterprise or client systems and solid-state drives over a computer’s high-speed PCIe (Peripheral Component Interconnect Express) bus. NVM Express (v1.3) is an open collection of standards and information that exposes the benefits of nonvolatile memory (NVM) in computing environments from the mobile device to the data center. The specification, and its registered and trademarked explanations, can be downloaded from the NVM Express Inc. website (www.nvmexpress.org). The term “NVMe” is a trademarked name, which encompasses a solution set designed, from the ground up, to deliver high bandwidth and low-latency storage access for NVM technologies.

The NVMe specification defines a register interface, command set and collection of features for PCIe-based SSDs. Its goals are to enable high performance and interoperability across a broad range of NVM subsystems. Note that, like most “standards,” the NVMe specification does not stipulate the ultimate usage model, i.e., how NVMe is directly associated with a specific solid-state storage, main memory, cache memory or backup memory. 

NVMe is optimized for Enterprise and Client solid state drives, typically attached as a register-level interface to the PCI Express interface. The 287-page specification describes an interface that allows host software to communicate with a nonvolatile memory subsystem. During its development, the specification was referred to as “Enterprise Non-Volatile Memory Host Controller Interface Specification (NVMHCI).” The lengthy name was simplified to NVM Express prior to publication.

Fig. 1: PCIexpress interface card with NVMexpress solid-state drive unit fitted to slot on the interface card. Card uses an M-Key edge socket to attach the SSD to the PCIe form-factor adapter card.

The NVMe 1.3a spec addresses both NVMe over PCIe and NVMe over Fabrics. The later Fabrics specification defines a protocol interface and related extensions to NVMe that enable operation over other interconnects (e.g., Ethernet, InfiniBand, Fibre Channel). Support requirements for features and functionality may differ between NVMe over PCIe and NVMe over Fabrics, rendering different performance parameters based upon the interface application.

NVMe increases support for Enterprise capabilities via enhanced error reporting and virtualization. End-to-end data protection is compatible with SCSI Protection Information, known as “Data Integrity Field” (DIF). DIF (or T10 DIF) is an approach to protect data integrity in computer data storage from data corruption, originally proposed in 2003 by the T10 subcommittee of the International Committee for Information Technology Standards (INCITS). SNIA references this as “Data Integrity Extension” (DIX) in its standards.

KEY FEATURES

The NVMe 1.3a spec interface has many additional key attributes, such as an efficient and streamlined command

set and support for multiple namespaces and namespace sharing. The NVMe Management Interface is the command set and architecture utilized in out-of-band management of NVM Express storage (e.g., discovering, monitoring and updating NVMe devices using a BMC). Typically, the NVM Express controller is associated

with a single PCI function.

In similar fashion to the transitions of HDD interfaces that went through ATA, IDE, SCSI and beyond, now, when you think about solid-state drive technologies, you can add the latest dimensions of the NVMe interface—one of the hotter topics in storage technologies that are growing stronger each day.

Karl Paulsen is CTO at Diversified and a SMPTE Fellow. Read more about storage topics in his book “Moving Media Storage Technologies.” He can be reached at kpaulsen@diversifiedus.com.

This is the third installment in a series of articles about the newly-published SMPTE standard covering elementary media flows over managed IP networks. This month, the focus is again on video transport, specifically the rules that help ensure that high-bitrate video streams are well-behaved and won’t overwhelm the IP networks used to transport them nor overflow receiver buffers.

KEEPING STREAMS FROM OVERFLOWING

The full title of SMPTE ST 2110-21 is “Professional Media Over Managed IP Networks: Traffic Shaping and Delivery Timing for Video.” Both of these terms refer to the same basic topic: how are the packets transmitted over the network, from the perspective of both the sender and the receiver? In other words, how should packet flows be sent into the network “pipes” so as to not cause flooding (of packets)? Answering these questions is crucial for properly provisioning network connections to support as many signals as possible without causing packet congestion, which could lead to packet loss.

To really understand the potential issue, it helps to deal with some actual numbers. Consider a 1080p signal with a 50Hz (European) frame rate that has a bandwidth of 3 Gbps on an SDI cable. At 50 Hz, a new frame of video is created every 20 milliseconds. Using constant-size packets, each with 480 pixels, would result in 4320 packets for each video frame. Using 10-bit sampling, 480 pixels would require 1200 bytes of data, plus 90 bytes of overhead, for a total of 1290 bytes per packet.

One way that this video signal could be transmitted would be using evenly spaced packets. In this case, 4320 packets sent every 20 milliseconds would mean that one packet is sent every 4.63 microseconds. On a 10 Gbps link, each 1290-byte packet would require (1290*8=10,320) bit-times to transmit, or 1.032 microseconds, followed by a gap of roughly 3.6 microseconds.

Another way that this video signal could be sent would be sending all of the pixels within a frame all at once. (This could hypothetically be the case for a device that was, say, generating graphics.) In this case, the sender would generate a burst of packets lasting 4320*10,230 bit times, or 4.419 milliseconds. This burst of packets would be followed by a gap of (20-4.419) 15.581 milliseconds until the next video frame was ready to transmit.

[SMPTE ST 2110-10: A Base to Build On]

So which of these packet transmission schemes is better? Well, both of the above streams have the same long-term average bit rate, of just about 2.23 Gbps. However, the first stream with evenly spaced packets will be much easier for signal receivers, switches and other network devices to handle. Why? Because the second stream will fully occupy a 10 Gbps data circuit for a significant period of time, forcing any lower-priority data that might need to be transmitted over that link to be placed in a buffer to wait for the link to become free. If higher-priority data came along during the data burst, then video packets would need to be buffered instead. Since network devices typically have a limited amount of buffer space that needs to be shared by multiple physical data channels, any signal that places heavy demands on buffers can cause problems, such as lost or deleted packets when buffers are filled up.

This issue becomes even more of a problem when multiple senders are all trying to transmit bursts of data at the same time, as would frequently occur in applications where several video sources are locked to a common clock. Therefore, to prevent network problems and to make it easier to design signal receivers, it makes sense to set some limits on the size and duration of packet bursts. These limits are often called “traffic shaping” and/or “delivery timing” in networking jargon.

TYPE N, NL AND W VIDEO SOURCES

The ST 2110-21 standard defines three types of senders: N (for Narrow), NL (for Narrow Linear) and W (for Wide). These types define limits for the amount of packet delay variation (i.e. the burstiness) that a sender is allowed to exhibit in its output stream.

Type NL is the easiest to understand, and corresponds to a stream where all the packets for a video signal are evenly spaced across the duration of each video frame (i.e. a stream that is like the first example given in the preceding section). The SDP (Session Description Protocol) for this type of stream must include a parameter “TP=2110TPNL.”

[SMPTE ST 2110-20: Pass the Pixels, Please]

Type N is similar to Type NL, except that the sender doesn’t send packets during the time that would correspond to the VBI (Vertical Blanking Interval) or VANC (Vertical Ancillary data space) of the corresponding traditional SDI video signal. Thus, a Type N sender would be able to send packets in a stream that would have a noticeable gap that occurs during each video frame period. For example, in a 720p signal running at 50 frames per second, and a VANC equal in duration to 30 lines of video, the sender would deliver packets for (720/750*20 milliseconds) 19.2 milliseconds out of every 20 milliseconds, and have a 0.8 millisecond gap when no packets are sent. Note that this would be the behavior that would be the easiest to implement if an incoming SDI signal was simply converted to ST2110 packets whenever active video samples arrive. The SDP for this type of stream must include a parameter “TP=2110TPN.”

Type W senders are allowed to have a significantly greater burstiness. This category was included in the ST 2110-21 standard to accommodate software-based senders, such as a graphics generator. For Type W flows, senders can have at least quadruple the amount of burstiness as a Type N or a Type NL, and in many cases much more. While this looser tolerance should make things better for a sender (particularly one that is implemented on a virtual machine), it does have consequences for receivers, which require a corresponding increase in the size of their input buffers. This can be costly, both in terms of the raw amount of memory that is required as well as in terms of delay for an incoming signal. Type W streams will also tend to consume larger amounts of buffer space within network switches and other devices; applications with significant quantities of Type W senders will need to be implemented using network devices that have sufficiently large internal memories. The SDP for this type of stream must include a parameter “TP=2110TPW.”

Fig. 1

Click on the Image to Enlarge

Fig. 1 shows a comparison of the three different sender types. Each of the three types is shown with a simplified representation of the packet flows along with a moving average of the bit rate. Note that for type NL, the moving average bit rate is flat, showing that these flows are the best behaved. Type N shows an increase in average bit rate during active video and a decline during the VANC. For Type W, the average rate shows even larger flow rate surges and drops.

Receivers are also categorized in ST 2110-21, but this information is not required to be transmitted with SDP. A Type N receiver should be able to correctly receive a flow originating from either a Type N or a Type NL sender(but not a Type W), provided that the receiver is locked to the same clock as the sender and that sender is aligned to the SMPTE ST 2059-1 Epoch. A Type W receiver should be able to receive a stream from an N, NL or W sender, provided the receiver is locked to the same clock as the sender. A Type A (for Asynchronous) receiver should be capable of receiving a stream from any type of sender, regardless of clock source or signal phase.

PRACTICAL CONSIDERATIONS

For time-sensitive flows within a media facility, such as a live broadcast, Type N or NL senders will tend to dominate, because they are the easiest to multiplex together and require the least amount of buffering in the network and at receivers, and therefore introduce the smallest amount of end-to-end delay. If Type W senders are present in a network, receivers will also need to be Type W to be able to receive these flows. For non-frame-accurate applications, such as monitors and multiviewers, or when synchronization between senders and receivers is not present, Type A receivers can be used to accommodate any type of ST 2110 uncompressed video flow.

Wes Simpson is the president of Telecom Product Consulting. He can be reached via TV Technology.

How many times have you written a file to a directory only to find out, sometimes much later, it was corrupted, lost or improperly archived? None of us are likely immune to this phenomenon and few are aware of how this might be prevented.

The accuracy, quality and consistency of data—regardless of where it is stored—is of immense importance; yet data integrity is often taken for granted by most users. Irrespective of where your data is stored—whether in a warehouse, data mart or some other construct, including the cloud—guaranteeing data integrity may be the most vital parameter in the entire compute chain. 

Data integrity describes a state, a process or a function. It is often used as a proxy for what is sometimes referred to as “data quality.” Data integrity is routinely equated with “databases,” as in “ensuring database data integrity” but it can a mean a lot more, especially when referring to the many actions that might or can occur in manipulating files (data) through various workflows and processes.

Fig. 1: Trusted values for data integrity.

Data integrity is warranted whenever the original data is modified, as in the editing, copying or transferring processes. Another concern is when the data is backed up or archived. The methods practiced by software and hardware storage solution providers need to be “transparently trusted” so that errors or losses of data are prevented. When or if data errors are detected, they should essentially be unnoticed (i.e., “transparent”) and never impact the results of when that data is used for computational, display or delivery purposes.

TRUSTED DATA

Data integrity infers that the data is trusted; that is, the data properties are trustworthy from a technical perspective (Fig. 1). Data must be trusted by the consumer of the data using reliable reports on the data’s state or status, as well as with the applications that will use the data.

Trusted data includes such attributes as “complete data.” This is achieved when the data integration technologies and techniques produce a consolidated data structure. The term “enterprise data warehouse” (EDW)—a term applied well ahead of today’s “cloud services” world—is where organizations could place their data (near term, short term or deep/long term), as a secondary service to on-premises (“on-prem”) storage. Respected and trusted EDWs should be competent enough to provide its customers with a full 360-degree view of users’ data with a historic context of all the real-time data activities. Cloud storage services have effectively replaced the legendary EDWs; with functions and expectations that are essentially the same.

STALE OF CURRENT

Trusted data should be “current data.” Users should be able to query the data system to understand questions such as “how old is the data” via a report?” Trustworthy data is “fresh,” whereas “stale data” is not. Stale data can be contaminated by successive read/write processes (where data is copied or relocated during defragmentation) or by “bit rot,” the slow deterioration in performance or integrity due to issues with the storage medium itself. 

Existing data may be corrupted when there is considerable activity (multiple seeks, reads and/or rewrites) on the actual disk platter or across the physical tape medium due to successive passes and/or writes. On optical drives, if the physical areas of the disc where the current data resides, has been untouched (unwritten to) for considerable time and then the laser writes to an adjacent area (or surrounding tracks); there are opportunities to blur or distort the existing pits making your existing data unrecognizable or questionable.

CONSISTENT AND CLEAN DATA

Another data trust factor deals with supporting the other (i.e., meta) data associated with the main “core” data. Properly maintained metadata management and master data management practices help to ensure that the data you need can be searched, found and retrieved on a consistent and secure basis. Good metadata management includes documenting the data’s origins and meanings, in a reliable and coherent methodology. 

Employing data quality techniques is critical to obtaining “clean data.” Typically, this is obtained by following standardizations in data management, using data verification and matching techniques, and using data deduplication. To maintain operational excellence and to make quality decisions, your data must be clean.

Since data activities often include the aggregation of one data set with other data sets as data traverses workflows, or when data travels across multiple IT systems; it is important to know and trust that the data is technically sound and consistent across the enterprise.

COMPLIANCE AND COLLABORATION

Ensuring you have “regulation-compliant data” is another element of a trusted data scenario. Regulations associated with data compliance come from sources which may be external to your organization, as in federal legislation or your partner connections. They may also come from internal policies such as your own internal IT data architectures, quality assurance, security and privacy. Businesses need to trust that their data has been accessed and distributed in accordance with both external and internal guidelines. 

Data “collaboration” (also referred to as data “sharing”) is essential to business functionality. Collaboration helps to ensure a strong alignment between data management practices and business management goals. When successful, data collaboration improves trust amongst inter-departmental activities and functions.

Fig. 2: Data quality monitoring, attributes to data integrity.

SOURCE TO DATA INTEGRITY

Data integrity needs to be maximized from the data source to the application and through to the storage medium (disk, tape, optical or cloud). Data integrity (and protection) is made possible by applying multiple mechanisms during the write processes, modification processes and through the management of duplicated data throughout the system (Fig. 2). 

One methodology is to ensure that when original data, stored for example on a disk drive is modified, that the results will always be written to unused blocks on that disk. This practice assures that the old (previously unmodified) data is unaffected on the disk, even if the new data written to the other location is corrupt. Through tracking history, if one data write is found to be in error, you could fall back to a previously written block and recover either the same (or a previous) version of the disk.

Another level of data insurance, the “snap shot”—from the photography term—is the capture (recording) of the state of a system at a particular point in time. Besides protection, this read-only snap shot of data can also be used to avoid downtime. In high-availability systems, a data backup may be performed directly from the snapshot. This method lets applications continue writing to the main data while a duplicate “snap shot” of data becomes that data, which is backed up to another storage resource.

There are many secondary (provided by the storage vendor) and third-party (non-storage vendor) software solutions that can manage both snap shots and backups in real-time.

INTELLIGENT BACKUP

As expected, more organizations are now considering modern intelligent backup practices to protect their data. This means more storage is consumed and that more data system management will be necessary. Intelligent backup solutions may utilize a practice called “deduplication,” which finds all the instances of any data set, establishes pointers to where all those instances occurred relative to the data backup, and then narrows the amount of data down to only a single set of data. Deduplication reduces storage costs, but also increases performance of data backups and restores. 

Data “dedupe” (its shortened name) can be used on main data (e.g., in databases or on transactional data sets) or for backups or archives. However, due to the already highly compressed nature of video along with the unstructured nature of motion imagining data, deduplication does not improve the storage performance in the same was it would for structured data.

Data management technologies, monitoring, and practices continue to evolve. How data is managed on a solid-state storage medium (SSD) versus a magnetic spinning disk or optical disc can vary. Users looking into new archive platforms or backup solutions should absolutely get the full story on how the vendor handles data management, data integrity and resiliency—before making a selection that they will live with for years to come.

Karl Paulsen is CTO at Diversified (www.diversifiedus.com) and a SMPTE Fellow. Read more about this and other storage topics in his book “Moving Media Storage Technologies.” Contact Karl at kpaulsen@diversifiedus.com.

Over the last 15 to 20 years, broadcast audio systems have undergone revolutionary changes—from analog to digital technologies, from manual to computer-assisted workflows, integrating related systems such as telephones and intercom systems, and much more.

One key enabling technology is Audio over IP (AoIP), which delivers a number of significant benefits, including operational flexibility, scalability and lower costs. However, implementing AoIP systems to take advantage of these benefits depends almost entirely on the existence of and support for interface and interoperability standards to ensure that the many elements that make up professional audio systems are capable of working together. To that end, there are several AoIP protocols designed to achieve this goal by easing implementation and integration, including the increasingly popular Livewire+ AES67.

Originally known as Livewire, this pioneering technology was created in 2003 by the Telos Alliance as a means of transmitting low-latency, high-reliability audio over switched Ethernet. Livewire+ AES67 adds full compliance with the AES67-2013 interoperability standard for high-performance AoIP transport over IP audio networking products. This allows devices to seamlessly connect directly to Livewire+ networks for connecting audio streams, regardless of device type or manufacturer. Livewire+ AES67 also offers the flexibility to incorporate and comply with future AES and SMPTE standards as they are approved and released, while simultaneously offering backward compatibility with the RAVENNA networking protocol.

Today, 70,000 connected devices worldwide use the Livewire or Livewire+ AES67 protocols, and 100 companies provide compatible equipment. While these numbers are impressive, adoption continues to grow steadily for a number of key reasons.

EASE OF INSTALLATION AND USE

In the coming years, studios’ transition to IP will continue, but the number of available protocols, methods, hardware and audio devices can make the process confusing. Livewire+ AES67 cuts through this noise to accomplish interconnectivity more easily at a lower cost.

Using Livewire+ AES67, uncompressed digital audio, device control messages, program-associated data and routine network traffic is carried over a single Ethernet cable in real time. This reduces the number of cables to deploy, significantly reducing the time required to wire an entire facility. All sources and devices connect using readily available Ethernet cables, which can carry up to 250 audio channels each, depending on the network link capacity. This link aggregation eliminates expensive multi-pair cable for interconnecting studios, resulting in potentially significant savings in labor costs alone.

Configuration can also be just as simple. With Livewire+ AES67, every audio source is given a text name and numeric ID, which are transmitted from devices over the network thanks to a built-in device discovery mechanism. All hardware products have built-in web engines that can be accessed via any common browser or by using an Axia program called iProbe. Users simply enter the names of their desired input sources using just a PC and web browser, with a configuration window enabling any necessary parameter changes for the selected sources.

As a result of these capabilities, installation and configuration, which may have taken weeks in the past, can now be completed in hours thanks to Livewire+ AES67.

AUDIO QUALITY AND RELIABILITY

Unlike Internet audio, which suffers from reduced quality as a result of limited and variable bandwidth, Livewire+ AES67 uses Internet protocols but is intended to deliver uncompressed audio over local area networks (LANs). Livewire+ AES67 is the only fully compliant protocol that also features Unicast SIP modes of operation, meaning it is also suitable for VLAN and WAN applications.

The controlled, high-speed Livewire+ AES67 network provides more than adequate bandwidth for large numbers of channels of high-quality uncompressed audio in real time, eliminating the risk of audio drop-outs from network outages and other issues affecting transmission. Long accepted as a reliable means of transporting virtually any kind of data or signal, IP has become a reliable option for telephone, intercom, teleconferencing and many other applications. According to the Telos Alliance, as of April 2015, more than 5,500 studios around the world had been built using the company’s Axia IP-audio infrastructure employing the Livewire+ AES67 protocol for mission-critical broadcast applications in major metropolitan markets.

COST SAVINGS

A key benefit of Livewire+ AES67 is its ability to enable computer data, phone, audio and control to be transmitted on a single network. Naturally, this type of converged networking environment can generate significant cost-efficiencies throughout a broadcast facility.

Further contributing to the cost-effectiveness of Livewire+ AES67 is that the most widely used and highly respected companies in the radio industry have adopted the technology. This allows broadcasters to select best-of-breed solutions and connect as many audio devices as possible directly to their audio network. In addition to simplicity, this removes the need for extra I/O devices, delivering even lower overall system costs.

Livewire+ AES67 allows wiring to be installed in hours, as opposed to the weeks that are often required. Livewire+ also generates savings from the way it handles audio from PCs, which nearly all broadcast stations use as their primary means of playing and editing audio. With a traditional network, PC-based audio is transmitted through a router input card or console module, which adds significant cost when bringing multiple audio channels into the system.

The latest release of Livewire+ AES67 includes a driver that can handle up to 24 bi-directional stereo or mono audio streams directly through a computer’s network card and now features PTP clock synchronization. This allows the computer to be connected directly to the network using an existing Ethernet connection, eliminating the cost of an additional sound card and the port needed to connect it to a console or router. In many cases, this can save broadcasters many thousands of dollars.

Studios’ transition to IP-based broadcasting has been underway for several years, but has been hindered by the sheer number of protocols, integration methods, legacy hardware and advanced audio devices, which can be confusing at best. The advanced capabilities and other key benefits of Livewire+ AES67, on the other hand, simplifies interconnectivity and upgrades, while offering greater flexibility and cost-effectiveness.

By implementing Livewire+ AES67 solutions, studios can take advantage of best-of-breed technologies to satisfy a wider range of applications within network environments. Best of all, Livewire+ AES67 is designed to work with future standards as they are released. This ensures that the Livewire+ AES67 will never be obsolete and continue to deliver quality, reliability, flexibility, cost savings and many more benefits well into the future.

John Schur is the president of Telos Alliance TV Solutions Group.

In the 1957 movie “Desk Set”with Spencer Tracy and Katherine Hepburn, the story line revolves around the introduction and use of a computing machine (EMERAC) at a network broadcaster to help improve efficiencies. In today’s real world of media asset management, workflow efficiency and throughput are still top-tier goals, but are now achieved through innovative Media and Entertainment (M&E) software apps and in cloud computing. The varied and diverse solutions available today enable management to better handle all aspects of MAM. In fact, the more recurrent or complex a given workflow, the more beneficial these solutions become to automate the steps in managing the business of content.

Unfortunately, at some firms, investments are being made at a department level leading to “islands of automation” with duplication of content, huge costs and a lack of agility and collaboration. These poorly integrated technology stacks are insufficient to meet the needs of a rapidly evolving digital media landscape that includes the challenge of managing, producing, repurposing, distributing and monetizing large volumes of content.

In recent years, companies have struggled with conventional OTS (off the shelf) or homegrown MAM software in an attempt to solve these issues, but the solutions lack scalability across diverse departments and locations, and do not support strong upstream and downstream collaboration across the content supply chain. Media enterprises that invested heavily in on-premise MAM software often did so because of a lack of high-speed IP networks, integration with existing legacy production and broadcast systems, and a reduced dependency on internet performance and local area connections. In addition, on-premise deployments were subject to data storage restrictions and had a fixed production environment due to slow software upgrade cycles.

CONSUMER VIEWING HABITS

Stepping back for a moment, the need for improved management of all aspects of the business can be attributed in part to the change in consumer viewership behavior. New behaviors are driving second screen viewing, personalized viewing instead of family viewing and instant gratification through binge watching instead of regular drip-fed consumption of content. These changes shape the need for more high-quality premium entertainment content, increasingly targeted to specific audiences rather than the one-size-fits-all content approach of television. Going forward, personalization will remain the central theme of any TV viewing experience. This will drive innovation in content and ad targeting, especially in the over-the-top multiscreen space. Content creators will be tasked with the need to offer relevant and engaging content like never before.

The changes in viewing behaviors have also driven an increase in third-party content production houses. To best take advantage of these newly available content sources, M&E enterprises need tightly embedded content logistics workflows, with seamless integration across departments within the enterprise—production, marketing, technical operations and multiplatform distribution. Just like other industries, M&E enterprises should adopt an enterprise resource planning (ERP) solution that can act as a one-stop-shop to manage, review, process and publish content across all the platforms and devices of the broadcast universe.

More specifically, what they need is a media ERP suite that automates the content supply chain and builds a connected enterprise using both cloud and on-premises resources. An automated content supply chain is different from a conventional content supply chain as it can more quickly cope with changes and enables stakeholders to collaborate anytime, anywhere, on any device.

In the hybrid cloud model, the application software (MAM, database, BPM and enterprise service bus) and metadata are on the cloud while content storage, streaming, transcoding, auto QC and accelerated file delivery applications are on premise. Designers can partition workflows across the private side and the public side—based on a variety of drivers—and achieve the security, reliability, performance and reach that are needed for each function.

ENHANCING WORKFLOWS

In essence, hybrid cloud technology brings content to the center of the business, automates business processes and ensures concurrence and mobility of workflows using the same virtual resources. It provides strong integration with legacy systems and enables workflow orchestration across enterprise, supply chain and partner ecosystems. This in turn helps organizations enhance efficiencies and reduce costs.

Other advantages of SaaS (Software as a Service) based ERP are many. For instance, end users pay only for the services they use and the scale they need, knowing they can move up or down the functionality/scale ladder as necessary. Moreover, centralized software execution and management requires no end user software patching/upgrading; it can be deployed for small, medium or large systems and has rich APIs available for customization as needed.

Moving MAM to the cloud with solutions like Prime Focus Technologies CLEAR Media ERP vastly improves throughput and workflow efficiencies for every aspect of the content production, management and distribution while lowering total cost of operations (TCOP). As viewing behaviors continue to evolve, broadcast and production facilities will inevitably require new MAM solutions to remain competitive and relevant in the market. Prime Focus Technologies' CLEAR Media ERP with Hybrid Cloud infrastructure just may be the perfect solution they’ll be looking for.

T Shobhana is vice president and head of global marketing & communications for Prime Focus Technologies.