WNY-HPNVI
Western New York High Performance Networked Video Initiative

[WNYPHN Home]
Edited & Last Updated 3/7/2002 by jow

WNYPHN Discussion Starter
& 
Straw Proposal

James O. Whitlock
3/7/2002

BACKGROUND

In my own view, as someone who has been working with regional public sector early adopters of high performance networked video for seven years now, we've been presented with an extraordinary and unique opportunity.  Public health and safety needs for robust and seamless video data network connectivity and functionality appear to be little more than supersets of the needs of our entire regional early adopter constituency throughout the public sectors.  I cannot imagine an effective public health and safety network that did not embrace and include all of the regional schools, colleges, universities, hospitals, community centers, police stations, fire-houses, and public buildings of interest to us for more generalized public benefit networked video applications beyond those associated with immediate public health and safety requirements.  If we succeed at all with the immediate challenges, we will have crafted the very infrastructures necessary to enable the visions of a far larger group.

As many of you already know, IP-video technologies and architectures are evolving rapidly.  They are also complex beyond most people's understandings and require large numbers of educated choices where longer term outcomes and directions are anything but clear.  Several regional groups with overlapped interests are already working towards necessary infrastructure development and promotion and a small number of early adopting institutions are now starting to try to define support requirements and associated costs.  In general, I think we all know what we want, qualitatively at least;  rapidly mapping those desires into practical supportable frameworks in a very fluid context is, however, a daunting task.

We are faced with the immediate job of responding to an opportunity to secure federal funds being offered to strengthen and build public health and safety services and capabilities in response to the 9/11 terrorist attack in New York City.  I'd like to offer a straw proposal as a discussion starter that includes both older and newer technologies and that attempts to state objectives and requirements in a way that allows for fast and easy decomposition and refinement.. 

 Some of you may not believe we can assemble anything meaningful in less than a month.  I disagree.  Some years ago I was tasked with drafting a defensible proposal for what at the time was an equally challenging undertaking: a sensible  fiber distribution plan for a local neighborhood.   That proposal had to be completed over a weekend.  We flew in an appropriate consulting expert by private flight and over the course of a marathon 36 hour session, managed to transform raw visions into specific strategies, recommendations and costs that actually had some utility and meaning.  We have a lot more time than that now and we're armed with a good number of people in the region with relevant experience and expertise.  

MULTICAST BASED CONFERENCING

Those of you who have been working with me for awhile will note the inclusion of relatively unfamiliar multicast based networked video technology in contexts that you may more readily associate with H.323 videoconferencing.  While that may seem new and different, the general approach has been in use for conferencing for many more years than better known H.320 and H.323 technologies.  In that sense it is extremely mature, if not broadly supported, and is seeing active and aggressive development while affording far higher quality levels than can now be supported with traditional conferencing technologies.  Further, since it can be deployed and used in architectures that do not require centralized controlling single-point-of-failure infrastructure components, and, we believe, can be effectively utilized with far less complexity (and consequent support costs) at content-source endpoints, it seems, on surface, to be an extremely attractive candidate for supporting robust high quality audio/video connectivity in chaotic emergency contexts. 

Lower quality multicast conferencing had it's genesis as a collaboration and development support tool on the Internet's original Multicast Backbone (MBone) and is broadly supported on all dominant platforms today without the cost barriers associated with newer conferencing technologies.  A Google Search on "MBone" will yield lots of references.  

What is new about multicast based conferencing today, is the emergence of both commercial product and serious developmental activity at the highest levels of audio and video quality scales.  Commercial low-latency bi-directional MPEG2 appliances now afford DVD television grade multicast conferencing capabilities at audio and video quality levels well over twice as good as those associated with H.320 and H.323 technologies.  IP based HDTV, now a research grade undertaking, is similarly likely to emerge as product in multicast based forms.

The following links may be of value for additional background information on multicast conferencing:

• VBrick Systems Corporate Site:  VBrick Systems manufactures MPEG2 low-latency bi-directional conferencing appliances.  Their technology has been demonstrated several times locally over the last few years and will soon be available on trial status in the WNY-HPNVI Sandbox for our regional early adopter community.  I am completing a donation/purchase package with them at this time.
• Access Grid:  This is a higher-end version of multicast conferencing technology intended to support research collaboration in the R&E community.  UB will be installing an Access Grid node within the next few months.  Access Grid node designs, which simultaneously provide multiple large screen high resolution views from four or more sites can be seen as a possible functional model for public health and safety emergency command and control locations.
• VRVS:  This version of multicast conferencing technology is now being deployed for best-effort production grade suppport in the new Internet2 Commons Facilities, a production test-bed for IP-video technology applications.  The Internet2 VRVS deployment is also being used as a test-bed for integration and inter-operation of multicast based conferencing and H.323 videoconferencing.

STRAW PROPOSAL OUTLINE

Proposal Framework:

1. Keep the network physical transport fabric & topology, the routing facilities, and the endpoint functional & equipment requirements related but clearly separate.  The endpoint functional equipment packages should only need to be connected to the backbone network and the routing equipment packages should be such that they can be physically re-deployed as needed.  Portable backup power is assumed for all network node and endpoint locations.
   
   
2. Strive for decomposable component parts and packages that can be easily defined and refined by working groups with specialized expertise.  For example, endpoint requirements can be broken down to rugged portable packages like those following:
   
   1. A bi-directional MPEG2 multicast conferencing package with basic audio and camera components
   2. An appliance based H.323 IP videoconferencing system package with basic audio and camera components
   3. An H.323 infrastructure component package (Gateway, MCU, Gatekeeper, for example)
   4. A supplemental video production package for command/control locations.  This might include mixers, switchers, a video overlay titler, a video overlay sketch tablet, monitors and so on
   5. An N-channel bi-directional MPEG2 multicast expansion package for enhanced content source site use or for additional or enhanced command/control locations
   6. An enhanced collaboration and conferencing package that might include a document camera, an electronic whiteboard with a companion screen projector, a video overlay sketch tablet, a mic/mixer package for larger groups, additional video cameras, and additional LCD monitors
   7. A high quality weather-protected digital camcorder package with appropriate microphones for on-site field recording away from equipped endpoint locations 
   8. A rugged portable PC package
   9. A video post-production editing package for preparation of news feeds and updates 
   10. A streaming video and VOD package for live IP based coverage, either for public feeds or for authenticated/protected official use
   11. An IP-telephony package with a portable management and conferencing system and enough hardware IP telephones and adapters for each endpoint location
       

Each such package can then be defined and refined with little regard to the others once some straightforward functional and physical interface requirements are defined.

3. While we all latched on to dark fiber as a network backbone reference point, the most important network characteristics are probably not media dependent.  While most of us suspect that dark fiber networks afford the most obvious and optimum solutions, and while we may need to build trade-off models based on some particular media, we may also want to be open to innovative proposals.

Objectives

1. Build a scalable Public Health and Safety video data network with the following characteristics:
   
   1. Designed to deliver a minimum of 100 Mbps of traffic with no significant video impairing IP path impairments to each endpoint location.  Clear and unequivocal bandwidth and impairment tolerance levels can be specified with modest ease.
   2. Based on link technology that can be upgraded at the endpoints to support an order of magnitude increase in bandwidth over the same media, simply by replacing link termination, multiplexing, and possibly switching equipment.  Physical link media must not need to be replaced in order to extend backbone bandwidth.  Glass fiber is the obvious choice but not the only one.
   3. Designed to cover a geographically dispersed set of endpoint locations the first year with maximum area of coverage and with a topology that allows incorporation of additional transport path redundancy at small expense as more endpoint locations are added when additional funding becomes available.  I do not believe that this is hard to accomplish and have at least one preliminary model in mind. 
   4. Designed to support arbitrarily located traffic aggregation points.  In an emergency, these would be command/control sites.  In non-emergency use, they might become carrier neutral co-location facilities for traditional telephony and ISP services.
   5. Designed to maximize the separation of transport and routing functions to achieve the highest degrees of robustness and flexibility.  To the extent possible, data traffic routing technology (traditional routers, for example) should be packaged in rugged portable packages that can be readily deployed to alternate network endpoint locations in the event that the nature of an emergency precludes use of a planned routing center.  A complete spare routing package should be provided and maintained and graceful fail/fall-over techniques must be defined.
   6. Designed to initially support some number, say 20, of endpoint locations in the first funding cycle.  These can be selected from lists of appropriate public buildings and public service facilities.  We should be able to create rough models that will allow decision makers to trade off endpoint counts and locations against network robustness and redundancy for any dollar limit.
   7. Takes maximum advantage of rights-of-way that can be provided without cost by participating local governments in order to reduce backbone network implementation costs and maximize funds available for application support packages. 
      
      
2. Provide rugged packages of functionally self-contained endpoint equipment for each of the initial endpoint locations.  The only external component that any package should require is a network drop or the equipment package that it's related to.  Based on the endpoint package breakdown sketch in Proposal Framework (2) above and an initial 20 endpoints, the quantities might look something like:
   1. 20 bi-directional MPEG2 multicast conferencing packages, one for each endpoint
   2. 20 H.323 appliance conferencing packages, one for each endpoint
   3. Two H.323 infrastructure component packages, one for an assumed command/control center and one for rapid deployment 
   4. Two supplemental video production packages, one for an assumed command/control center and one for rapid deployment
   5. Two 19-channel bi-directional MPEG2 multicast expansion packages, one for an assumed command/control center and one for rapid deployment.  Two 5-channel bi-directional MPEG2 multicast expansion packages, for deployment to 2nd  tier command/control endpoints or those close to emergency sites
   6.  Two enhanced collaboration and conferencing packages, one for an assumed command/control center and one for rapid deployment.
   7. Two high quality weather-protected digital camcorder packages, for deployment to emergency sites.
   8. 20  rugged portable PC packages, one for each endpoint.
   9. 2 video post-production editing packages, one for an assumed command/control center and one for rapid deployment.
   10. Two streaming video and VOD packages, one for an assumed command/control center and one for rapid deployment.
   11. Two IP-telephony packages with one complete set of endpoint hardware IP-telephone sets and/or adapters, one package for an assumed command/control center and one for rapid deployment.
       
       
3. Provide funds to develop training materials for routine endpoint package usage, routine functional testing procedures and predictable procedures for simulated emergency trials.

CONCLUSION

I only mean to provide a starting point for discussion and to suggest some of the attractive aspects of high-quality multicast conferencing technology for the intended applications.  I also believe that there are relatively large numbers of experienced IP-video early adopters in the WNY region and many more in the larger Internet2 community who not only could be would contribute significantly to rapidly refining any visions we settle on as targets.  I strongly urge the group to consider the most open discussions possible in the largest  possible community.   We are obviously not alone in our need to respond to the immediate opportunities and much could be gained from a more broadly collaborative endeavor.

Please feel free to comment either directly to me or to our listserv discussion group.

Thanks & Regards,

Jim Whitlock

Material presented here was written, edited, compiled and produced by me.  The opinions expressed, unless attributed to others, are mine alone and do not represent those of the University at Buffalo or its affiliated institutions.  Neither do they represent, unless so indicated, those of the individual, business and institutional members and sponsors of the WNY-HPNVI.