Comments on Nationwide Interoperable Public Safety Broadband Network NOI

dr.myers@me.com
Thu 10/11/2012 10:45 PM

Thank you for the chance to provide information to such a great national program. Attached you will find my response to the questions relating to the rollout of the Nations Broadband Network for First Responders. This document is by no means complete, but rather touches on a few important topics.

Sincerely yours,

Dr. Michael Myers

Dear FirstNet:

Attached is a white paper from Lemko Corporation that offers a different network architecture than the traditional centralized core architecture. It is revolutionary and game changing. It can be deployed at less than half the cost (considering Cap Ex and Op Ex expenses) as a centralized core network. It eliminates single point of failure issues and is the most redundant and robust approach available. The paper discusses disasters of the past and compares the failures of the networks versus what could happen with a Lemko based network. Thank you for your consideration.

Dave

WE HAVE MOVED! Please note as of 8/28/12 NEW contact info will be:
David M. Kauppi
Director, Lemko Strategic Alliances
Lemko Corporation
One Pierce Place, Suite 700
Itasca, IL 60143
D 630 225-7693
O 630-948-3025 X 327
630-948-3030 Fax
Cell: 630-215-3994
email: dkauppi@lemko.com
Corporate Site: www.lemko.com

Attached is my response to:

National Telecommunications and Information Administration Docket No: 120928505-2505-01

RIN: 0660-XC002

Development of the Nationwide Interoperable Public Safety Broadband Network

--

Rex Buddenberg

To whom it may concern,

I have been one of the main system engineers on the UK Airwave Tetra system (2000-2005) and the now defunct New York Statewide Wireless System (SWN: 2005 – 2008) and I have some comments, lessons learned, and observations that I would like to provide:

·        I agree: It is wise to work with the cell phone operators especially with respect to digital data. The data feeds available through the trunked radio are very limited ( a few Kbits/sec) and will never provide the bandwidths that are required for some of the nice-to-have applications. In the UK packet data (GPRS) from commercial cell phones was encrypted and “tunneled” into a secure subnet within the IP network. Within this subnet there were servers available that would permit warrant, CAD, and other types of direct searches. Access to these servers systems is available only if the user can be sufficiently authenticated. The authentication and the access to nation databases will likely be an issue that needs to be worked on from the beginning, since many older rules still apply from mainframe days. Encryption standards were equivalent to FIPS II in the UK. The ground rules for the trunked native classified voice and data also enter into the equation here since secure access by federal services will likely be required at some point. Will voice and data be rated at a secret level or potentially higher? The UK wanted military access at the secret level, and hence radio basestations had their own keys that reported to encryption servers. Will there be similar requirements on FirstNet? Voice and data integrity needs some deep though for this new system, and will likely require packet switching, labeling, and prioritization. In the UK data from the police/fire radios also tunneled into the same subnet within the system. This IP data from the radios could also access the national databases via a reduced graphic interface. The suggestion is that the radios have the ability to roam to the data network with the most available bandwidth. This would include the tunked radio bands, the commercial data networks, and WIFI networks. For example fire may need to download maps  of building. This might be done at lease partially by WIFI before the crew leaves the building and might be able to require WIFI at the local destination. Police cars might have a WIFI link that broadcases locally in the vicinity of their car so that a portable table can be taken into the house or locality to do reporting and requests searches. The car then uploads the buffered results into the network. Bottom line: the basic bandwidth is sufficient for voice and very limited data, the future data expansion needs to come from the radios roaming to other networks when they are available. One of the major benefits of central application infrastructure is that CAD systems and access to national, state, and local resources can be cost shared.

·         Caution: one of the reasons that SWN failed was that the radios attempted to download user talk groups and other local site information before the radio could effectively be used. This resulted in some radios not being “on-line” for  a few minutes while this data became available in low signal areas.  This was totally unacceptable since officers going to a bank robbery, for example, were unacceptably delayed. The Tetra radios on the other hand had a built in chip that supplied user talk group, encryption, and personal information.  The problem with the tetra radios was that the radios became user or user group specific and the chip was too fragile to be put in and out on a daily basis by specific user. Good radio requirements make a difference here.

·        The major issue with a large police radio networks is availability and reliability. It’s very hard to take down individual radio system that are scattered around a very diverse area. A national system must have multiple redundancies: multiple trunking lines, multiple redundant servers, switches, and server sites. The big issue with the associated commercial vendors is going to deal with the details of how reliability is implemented during normal and emergency situations. Who gets the bandwidth when something important is happening? How will the basestations implement emergency level priorities on the sites switching? How will the firenet developers know that sufficient testing of these emergency protocols is implemented correctly in a network that is shared? What is to stop them making a change in the basestation and network code after the testing is complete? Who will approve code changes? How will an industry that is known for its speed to deploy new features deal with the need for increased security, availability, and reliability? …which takes much more time. The main argument is that police and fire radio systems must be always up and always available because people’s lives are at stake. I am not saying that such a shared system cannot be deployed but the system engineering and operational concepts are going to be very important and everyone is going to have to buy into the agreed concepts. They need to be written down (see my bullet on requirements below).

·        Systems and applications need to be tested before being deployed with a new change. That is, applications for radios or tables and the radio code itself must be tested before it is upgraded or patched in a separate independent facility. Changes to servers or other part of the infrastructure need to also be tested before going live – too many lives at stake.  This is done in the UK and it is effective.

·        UK tetra provided coverage via satellite feeds in areas where it was difficult to connect a basestation into the voice and data backbone. The users suffer from a ½ second delay due to the radio propagation times to the satellites. Communication was still possible within these limitations.

·        The requirements and political will for the UK tetra system took on the order of 10 years to manifest and agree. Requirement generation is the first step for the RFP process.  Similarly the requirements for the SWN project took over 8 years to create. Much of this time can be saved by getting a copy of these system requirements and updating them, using the best parts of both, and adapting old requirement to reflect the firstNet network. What is important is the categories and the types of requirements that are contained within the existing requirements specifications, that formed the basis for the RFP. The same type of functionality must be provided and does not need to be redone from scratch. Other states can also contribute their requirement sets: Ohio, Pennsylvania, Oregon, etc. There is always something that is forgotten and could be made better. SWN lacked a complete Network Operating Specification and its reliability requirements had a few flaws that caused problems in the RFP process. UK forgot to include details on how aircraft were integrated into the ground network, and the coverage plan requirements poor such that  airwave took over coverage planning from the vendor. Hence a very major lesson is that a system engineering framework for the billion dollar system is important. Consider the DOD Compreshensive system framework or something similar: http://dodcio.defense.gov/dodaf20/dodaf20_models.aspx

Use some subset of the above that is doable in the time frame permitted (taylor the types of upfront documentation that will be required).

§  Create an operational concept document

§  Design reviews at the system level, state, and local dispatch center level are very important

§  Test plans and procedures must be formal and complete. Every test must be executed and formal. The SWN vendor did not test every requirement on the basestations before they were deployed at 100k+ per site. This caused very significant issues when they were fielded with issues that were unknown by SWN and by the vendor.

§  Specify who does the integration

§  Specify how training is accomplished

§  Specify how coverage will be automatically tested. This is important and caused no end of issues for SWM and for the UK.

§  Make sure that all technical details are available about the vendor implementation of the radio. SWN could not get the subsystem details and system models of the radio system from the vendor so we did not know the lowest acceptable radio signal level, and therefore we did not know if their coverage models were accurate (they did have problems). There were also interference issues that only because apparent in NYC because the technical analysis did not have enough details.

§  Make sure that CPI/SPI for the detailed schedules are available from everyone playing a part in the design and implementation. SWN knew there were CPI/SPI issues and that the project was understaffed significantly but it was difficult/impossible to understand how bad the situation was getting. There was insufficient reporting on a project / business level for a project of this magnitude. The DOD knows how to ask for this type of information when writing an RFP.

Last point: SWN developed very good coverage planning software that the state of NY owns. It was developed through NYSTEC and SRC (mainly SRC). It was capable of optimizing thousands of frequencies across the state, and across state lines through a special automatic optimization algorithms. This software will save you years of work that really can’t be matched by anything on the market. It is a fantastic tool that you are going to want to get or need to redevelop the capability.

I could probably go on but this is all for today. I wish you all the best. You can call or write to me via the details shown below.

Doug Westmoreland
Doug.westmoreland@gmail.com
518-489-1350

The attached comments for NTIA consideration were published today at http://chemical-facility-security-news.blogspot.com/2012/10/comment-on-public-safety-broadband.html

Patrick Coyle
Chemical Facility Security News
PJCoyle@aol.com, 706-888-8459
Twitter: pjcoyle

On the radio side a technology that is robust in the presence of multipath (and can take advantage of it) and has a high spectrum-reuse should be used. CDMA technologies fulfill that. OFDM does not.

CDMA technologies also currently have the push-to-talk capability, perfect for law enforcement use. Site-teaming allows for multiple antennas at different "masts" to be
"bonded" for higher throughput.

Thank you!
Craig Paul
Lawrence, Kansas.

Please see attached submission from the NIST Visiting Committee on Advanced Technology

Vinton Cerf
Chairman, VCAT/NIST