Original escrito por Rachel Lloyd para

Estamos solo en la mitad del 2019, y ya estamos dando forma al prometido año del 5G. Verizon, AT&T y Sprint han lanzado sus redes 5G en areas especificas de USA; Swisscom esta ofreciendo servicios comerciales de 5G en las mayores ciudades de Suiza; EE cambio a 5G en algunos ciudades el ultimo mes; y en Corea del Sur, SK Telecom, KT y LG Uplus anuciaron sus primeros suscriptores 5G en Abril. 

Sin embargo, conseguir suscriptores 5G es solo una arte de este rompecabezas. Es sorprendente la cantidad de juegos de Realidad Aumentada y video en vivo en en los smartphones, habra una gran cantidad de IoT y casos de uso de IoT, los cuales realmente apalancaran el crecimiento comercial de 5G. Diferentes sectores verticlaes y diferentes casos de uso requeriran diferentes tipos de conectividad y los operadores estaran contractualmente obligadas a asegurar los servicios ofrecidos. Los clientes (y sus usuarios finales) esperan que los operadores soporten efectivamente las Comunicaciones Masivas Tipo Maquina (en ingles mMTC),   el ancho de banda movil mejorado (en ingles eMBB) y las comunicaciones de baja latencia ultra confiables (en ingles URLLC). 

La unica forma en que los operadores estaran habilitados para entegar estos acuerdos de servicio estaran optimizados para la red 5G, y garantizar que el masivamente diverso ecosistema IoT corra efectivamente, es por medio de la llamada Segmentacion de la Red. 

Que es segmentacion de la red?

Segmentar la red significa crear una red independiente end-to-end sobre una infraestructura virtual,  compartida, y que pueda atender las demandas y funciones de multiples casos de uso 5G o multiples tipos de comunicacion. Una analogia para entender esto mejor es un policia acompañante que crea un camino limpio, libre de trancones a traves de una via congestionada. El camino estara limpio y adecuado a las necesidades especificas del acompañante, por ejemplo atravesar una calle ocupada en forma rapida, confiable y perfecta, con los otros vehiculos priorizando al acompañante sobre sus propios movimientos.

Why test network slicing now?

5G deployments are still few and far between, so operators should use this current period to test and assure the architectures and approaches which will be so vital to its success across different vertical markets and customer segments. When testing network slicing, operators must consider:

  • Does each network slice select the correct network nodes (AMF, access and mobility management function; SMF, session management function; and UPF, user plane function, are all new with 5G networks)?
  • Does the function of the network slice work correctly?
  • Can the network support the volume and variety of systems and devices which characterise 5G networks?

Testing a 5G network loaded with multiple types of data traffic in a real-world scenario is near impossible. Imagine trying to test a URLLC use case like connected cars, for instance, which will involve a network slice supporting thousands of vehicles and ensuring their safe, regulation-complying movement within smart city environments.

How can operators test network slicing effectively?

For operators to prepare themselves for the 5G use cases of the future they must test network slicing in a virtual, lab environment. VIAVI Solutions has developed end-to-end, RANtoCore test and validation solutions capable of emulating the 5G core network as a whole, individual nodes such as the UPF, SMF, AMF as well as multiple other functions.

Combining TeraVM and TM500 provides operators with a solution to the network slicing challenge, which is unique in the T&M industry, enabling service providers to ready their networks for 5G, get ahead of the competition, and future-proof their business.

To find out more about the importance of testing network slicing, learn how VIAVI is supporting major operators globally, and discover the benefits of partnering with us, head to our dedicated whitepaper. 


Invariably, things change. Profound I know, but even in the world of the venerable IRIG timecode there is a new search engine contender, iRig. Granted, a new guitar interface adapter for your smart phone app is a far cry from a waveform used to synchronize instrumentation, but even in IRIG there are revolutionary changes happening. To which we can collectively ask, “why did it take so long to do something so obvious?”

Here’s a little backstory: IRIG stands for Inter-Range Instrumentation Group, but is commonly the term used to refer to the waveforms passed through coaxial cables used to synchronize the time-of-day on test instrumentation used on military test ranges. These IRIG timecodes date back to mid-last century when military test ranges needed a way to time align all sorts of measurement equipment, videos, radars, strip chart recorders, etc. for flight tests conducted over the vast geographical expanse of the test range. While the formats and accuracy of the IRIG timecodes have evolved over time, IRIG in general is still very widely deployed.

For decades, generating an IRIG timecode took discreet electronic hardware and components to generate the waveform. Flexibility was characterized by DIP switches to choose IRIG formats and plug-in modules filled with BNC connectors inserted into 1U, 2U and 3U rack mount chassis. In fact, as far as I know, with one exception, all solutions offered today still deliver IRIG this way. Of course, it’s that one exception that, like a guitar interface to your smartphone, changes everything.

Innovation is often driven by someone asking, “Why can’t I just do this instead?” This is exactly what happened in IRIG timecode generation, selection and output in the Microsemi SyncServer S650. A bright timing scientist asked, “Why can’t we just take everything we do in IRIG hardware and program an FPGA to do it?” Marketing then comes along and promptly agrees with innovative ideas they don’t have to figure out how to make work. They give it a name – “FlexPorts” – and a new era in IRIG timecode generation is born in the Microsemi SyncServer S650 FlexPort™ option.

I must say that FlexPorts are obvious, innovative and cool. Imagine a module with a collection of BNC connectors that plugs into the 1U SyncServer S650. The module has its own web page in the intuitive SyncServer web GUI. You can navigate to the module web page, which is organized like the physical BNC connectors on the module, and merely select from drop down menus which IRIG signal you want to output from each connector. Configure each connector waveform output any way you please as it supports a lot more waveforms than just IRIG, press “apply” and viola! Those signals are all instantly being generated and output, all synchronized to the main clock and as perfectly aligned to each other as you can get. No changes to physical hardware, no removing modules and flipping DIP switches, no installing a module that has 3-4 connectors when you just need one. FlexPorts really are a pretty cool technology.

At this point, I suspect that you might be a bit underwhelmed, and that’s understandable. The FlexPort concept is a bit obvious and the next question is probably “Why did it take so long to figure that out?” Well, like the wheel, its benefits were obvious to some, but not to all. The Smithsonian asserts that wheels were used as potter’s wheels for 300 years before someone used them on a chariot. Not sure what a wheel-less chariot looks like, much less rides like. And kudos to the guy that figured out a stone potter’s wheel on a chariot was a non-starter and that wood was a better choice, but I digress. We’re now very glad we have wheels and we’re very glad we figured out how to use an FPGA to generate IRIG timecodes on demand instead of expensive, inflexible, purpose built IRIG timecode modules with discrete hardware parts.

If you want to learn more about FlexPort technology and what it can do, have look at the FlexPort Technology for SyncServer S650 application note here. If you have been at all involved with IRIG timecodes I think you’ll agree that while iRig for your guitar app interface may be novel, FlexPort technology for saving time, money, and ease-of-use in deploying a precise IRIG time synchronization solution like the SyncServer S650 makes a lot of sense.