Download TMBroadcast Onda Cero English

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Piggybacking (Internet access) wikipedia , lookup

Computer network wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

IEEE 1355 wikipedia , lookup

Network tap wikipedia , lookup

List of wireless community networks by region wikipedia , lookup

Airborne Networking wikipedia , lookup

Transcript
ONDA CERO
turns IP
It was this summer when Onda Cero finished an ambitious project
that took a few years around the house: the unification of data and
audio on a single network. We have come to the headquarters in
Madrid to talk to them about this integration.
Interview
with
Nuria
Dominguez, Technical Director
of ONDA CERO
It was an ambitious and cutting
edge project. How did it start?
At the time when the project was raised
ten years ago, we were operating in
Frame Relay data lines and it was not
feasible for the amount of delay, jitter
and bandwidth requirements, integrate
data and audio on that network. So the
first step was to restructure the data
network more consistently with what
we wanted. In the permanent audio
network (contribution and satellite
backup) we were working with 15 kHz
analog lines. What we did first was
reorder the data lines and pass the
audio lines to the same operator as the
data. We leave it all tuned to what we
needed, a base from which to work.
That’s why it has been a long project; it
took time to improve the network and
management of everything.
A problem we encountered, which is
logical, is that telecommunication
operators understand very well the data
traffic, but the same does not occur
with live audio. It is normal because
they don’t consider a problem when the
data packet comes with a small delay.
But if we're talking about live audio that
means audio cuts, which is obviously
unacceptable. So we had to define how
the new lines should be on the basis of
getting the better audio performance,
with quality of service and setting a
jitter threshold.
Two worlds colliding...
They were two worlds, data and audio,
we wanted to join and now I can say
that they fit perfectly. We did not want
to put into operation the audio data
over the network until we were sure we
had everything under control. You
could not endanger the emission, which
is sacred. That is why we did so many
tests.
Prodys, which has been our equipment
supplier, has always been very open to
everything we said to them, as was the
operator
Telefonica,
although
sometimes there was some dispute as
is normal in this type of projects. Going
on edge means you're going to find
things nobody has seen before, like a
connection working perfect through an
ADSL but failing through a macroLAN,
although it is assumed that the latter
has a guaranteed bandwidth. We
realized that actually the data network
was not designed or intended for audio
and then decided to use FEC. There
are many intermediate routers and
equipment so that if a data packet is
having problems, the route is changed.
For an email, this means nothing but
for broadcasting, it means a lot as the
live audio is going to be affected. We
solved this using FEC, which supposed
to double the contracted bandwidth.
We included a clause in the contract
with the operator to maintain the
analog audio lines until the network
was not fully deployed, so we could
work without incident while we were
solving the problems that were
appearing. Now everything works over
IP, all.
We had problems with the maintenance
of the permanent network in analog
audio due to the age of the equipment
used. It is a service that is no longer in
our catalog and will expire when
broadcasters who still use it decide to
their networks. We could have chosen
simply to change the permanent point
to point network of analog audio lines
by point to point digital network. That
would have been more immediate and
easier but at the cost of losing flexibility
and money. Our advantage was that
the data network was deployed and
operational. There are colleagues from
other stations that prefer separate
networks, but it is much more
expensive and in these times we must
take
advantage
of
technology to become more efficient.
How was the change?
The truth is that the change has not
been traumatic; we expected more
complications than we have had and
these complications have been solved
by all parties. It is true that IP audio is
used by many people, but that your
entire network relies on that is
something that has not been done so
far. We wanted the change to be as
transparent as possible for sound
technicians. That meant we had to
automate the switching the codecs had
to make, the IP addresses to call and
the connections to be maintained. The
project not only included the digitizing
and unification of audio and data
networks,
but
the
connections
automation.
Still, we managed to get people to
change a bit their working methods. It
had long been working in the same way
and bad habits had been acquired. For
example, N-1 was not used because
the delay in analog lines was negligible,
but with digital communications,
despite all the changes we have done
and all that we have improved, you do
need N -1.
Training has been fundamental. We
have given many courses because it is
very important that everyone has the
necessary
technical
information.
Because the network we have now
works better and sounds great, but you
need to have the necessary knowledge,
to do much teaching and involve
everyone. So we had it all tied up
before summer and we rushed, we did
the change and cancelled the analog
lines. We are working perfectly now.
How is that network?
It is a multipoint network, all can work
with everyone. Before the audio
network was point to point, connecting
the headquarters with the header
stations and these in turn with
provincial stations and these with the
local. If you wanted to interconnect
delegations, you had to go by bridges
between patch panels. The great thing
in the integration we've done is that
any two stations can be interconnected
in a flexible and easy way with both
data and audio without the expense of
dedicated lines.
What equipment
mounted?
have
you
We did many tests with different
equipment and suppliers. The truth is
that everyone is in a very high level.
We finally chose Prodys because they
accepted the challenge of adopting the
changes we needed. Since the project
was so pioneering it was not just to
choose good equipment, but to choose
a partner willing to help in any way
necessary. We have installed various
equipment of the Prodys Pronto family
as ProntoNet, ProntoNet LC and
Nereus, which is a chassis where
multiple encoder cards can be fitted.
The latter are aimed at facilities where
many codecs are required because it is
economically more profitable to have
such
chassis
than
several
1U
equipments. In larger venues such as
Madrid, Seville, Barcelona and Valencia
a Nereus equipment installation has
been made, which can rapidly expand
by adding the cards as needed.
Everything is scaled by the number of
connections that can be made, using a
very rational approach. The good thing
about the equipment we have chosen
and the network topology is that
everything is perfectly scalable, so we
decided to go to minimum and increase
if necessary.
To control all the ProntoNets we are
using Prodys Control. With it we can
connect at any time to a encoder
whatsoever wherever it is. We also
have an application to read all the data
from the Prontonets to see if there is
any alarm and to monitor the state of
each codec. Prodys has worked hard
in the integration of their equipment
with our applications. It was critical to
monitor real-time the state of
everything, regardless of whether we
could enter a remote station to see the
equipment in detail.
How
do
you
commutations?
make
the
We use the satellite as the primary
channel for sending audio (main
program) and disconnection data.
When necessary, a command is sent to
change to main, regional, provincial or
local program. Thanks to the data
network, disconnection commands can
be sent from any delegation as all the
broadcast equipment is interconnected
and receive orders through both
satellite and WAN. This has allowed the
MCR to be released from this work it
had to do for the entire broadcast
network and has provided greater
freedom to smaller centers.
We designed which commutations had
to be made depending on the type of
disconnection and how and what data
had to be received and sent to Madrid
to see the status of equipment. Another
great advantage of the network that we
have implemented is that previously we
were lost if the satellite fell. When this
happened, the analog lines became
operational through simple switching
units that changed the line if a lack of
satellite signal was detected, but we
lost the disconnection data with
everything that implies. Now, if we
have an issue with the satellite, we are
still having audio and you can send
anything you want on the network
losing absolutely no functionality. We
have gained a lot.
After everything you've learned
and the good communication
with the operator and the
provider, will it be easier for
those who go after you?
The truth is that all people involved in
this project have learned a lot. I
imagine that all that knowledge will be
useful for those who go behind. We
have been at the forefront with a
difficult goal. Telefónica has come to
understand the needs and has adapted
to what we found. Prodys has been
very flexible to fit everything too,
because even if the codec was
wonderful, they had to do everything
we asked for. If not, it was useless for
us. It had to be able to do things like
looking in the agenda, see the IP that
had to change and do it; it was not just
the audio. In this case they have heard
us and they have done everything we
asked them.
From TM Broadcast, number 44. Pages
40 to 44. Translated from Spanish