Wooshcom acheives record: 14 years without a failure!

Wooshcom acheives record: 14 years without a failure!

White PapersProduct Information

Artificial Network Capacity Inflation

MPEG Null packets which are 188 bytes per packet of wasted filler are regularly added to MPEG streams at times without any concern whatsoever to their impact on bandwidth usage. The current trend to immediately encapsulate the output of satellite receivers with IP encapsulated MPEG, is causing these MPEG Null packets to find their way onto the IP Network. Once there they substantially increase the load on network switches and routers and thereby artificially inflate the demands on these resources. WooshCom's MPA-1212 Null Packet Filter can be used to remove this capacity inflation by stripping out all Null packets before they are converted to IP. This results in a reduced load on switches and routers and a less congested switching fabric.

Current Aggregation Approach

Shown in the Satellite Content Aggregation Diagram is the current trend to convert the output of MPEG Satellite receives immediately from ASI to IP or to take Gig-E outputs out of the receivers directly into the facilities switching fabric.

While MPEG equipment is designed to handle Null packets, and knows to discard them at will, IP networking equipment such as routers and switches treat UDP/IP encapsulated MPEG Null packets as if they are any other piece of valuable data. In other words, the Networking equipment is completely unaware of the MPEG layer and it therefore exerts as much care in handling these 188 byte filler packets as any other data packet. Often, these Null packets are even given preferential treatment by the routers when they have been tagged with QOS that indicates they are sensitive real-time data.

This encapsulation of MPEG into UDP/IP packets has two important effects:

  • these meaningless Null packets are effectively "cast in stone" as they become IP packets and
  • they become essentially invisible as they "blend in" amongst valid IP packets.

The Problem Multiplies

Well how bad can it really get if there is a "little" Null packet overhead? In the case of SPTS (Single Program Transport Stream) receivers that are used to acquire one program from an MPEG multiplex, the video content, depending on the brand of receiver, will bury a 4Mbps SD stream in 54 Mbps of data with 50Mbps of that being Null packets. In the opposite extreme where an entire MPEG multiplex is being acquired through an MPTS (Multi Program Transport Stream) receiver, the multiplexed bouquet will often be formed to exist within 39 Mbps, but once again the overall data will be 54 Mbps, with 15Mbps of that being Null packets.

Some headends and acquisition facilities can have as many as 200 satellite receivers acquiring content. As an example lets take a small facility that is acquiring content from 48 receivers where half are SPTS receivers and half are MPTS receivers. Let's say half of the SPTS receivers are acquiring SD content at 4 Mbps and half are acquiring HD content at 13 Mbps. Here is how the data stacks up:

  • 12 SPTS SD receivers generating 48 Mbps of Information content amidst a 650 Mbps data stream
  • 12 SPTS HD receivers generating 156 Mbps of Information content amidst a 650 Mbps data stream
  • 24 MPTS receivers generating 936 Mbps of Information content amidst a 1.3 Gbps data stream

All together there is 1.14 Gbps of video information being carrier amidst of 2.6 Gbps of data. The video content represents only 44% of the data bytes being routed and switched in the switching fabric. In this case the switching fabric is carrying over double the data that it needs to. If the Null packets were removed before aggregation, network utilization would drop by 56%.

Solving the Problem

WooshCom's MPA-1212 Null Packet Filter can easily be employed to solve the problem and reduce the load being placed on the networking equipment. The Aggregation with Pre-Filtering Diagram shows how this is accomplished by inserting the MPA-1212 to filter out Null packets before converting them to IP.

Looking for more Information?

Contact us for more information.

Contact Us