4G LTE Only Network Connectivity at Small Offices?

Someone recently asked a question – can we go with an all 4G LTE network at a small office? Can we eliminate all the wired Ethernet and WiFi requirements at a small office?

My immediate reaction was that it might work for specific use cases. 4G LTE technology uses shared and broadcast channels that are not dedicated to a specific user. Also, the uplink and downlink speeds are asymmetrical in 4G LTE. If a small office is made up of users who only require data connectivity with moderate bandwidth requirements, then they can connect to corporate offices and data centers over remote access VPN solutions initiated from their 4G LTE enabled devices. Some of the service providers are launching IP VPN services over 4G LTE which makes it much easier for Enterprises that are looking for added security. Such VPN services are also ideal for M2M use cases as well. It should be noted that 4G LTE network today does not have native voice support and Voice over LTE (VoLTE) is still in nascent phase with only a handful of commercial launches. Therefore, we are forced to look at Over the Top (OTT) solutions such as IP soft-phones, Skype, Google Hangout etc., for 4G LTE enabled end-points to provide voice services. Such OTT solutions may suffer from voice quality issues due to varying network conditions and lack of QoS. There are other interesting problems that might arise if we work in an all 4G LTE network in a small office. Communication between peers in a 4G LTE network uses backend service provider network infrastructure today. This might cause excessive delays for print jobs or local file sharing where traffic has to go to service provider network over a lower speed uplink and then come down to a neighboring device in the same office. One should carefully evaluate use cases along with bandwidth and delay requirements before making a decision.

We obviously run into problems the moment connectivity requirements go beyond data and we need to connect business grade desk phones, IP phones, printers and any other device that works only on wired or wireless Ethernet. This forces us to use a typical small office design involving an integrated device that provides wired & wireless LAN for end-user devices and wired / 3G / 4G WAN connectivity.


Internet of Things: Networking Challenges

With the increasing hype around Internet of Things (IoT) and Internet of Everything (IoE), pundits, vendors and analysts are projecting that tens of billions of devices will get connected over the next few years. As a Network Engineer working in mostly Enterprise scenarios, I am curious to know the implications of IoT on network design, deployment and operations. Keeping aside massive computing power that is required to analyze the data sent by devices, sensors, machines, vehicles, wearable gadgets etc., the foundational requirement of connecting diverse set of end-points seems highly challenging. While no one has full answers as we are early into the hype phase, with some of the standards bodies beginning to announce their initiatives to bring this all together, I have tried to capture many of these challenges from the network design and operations perspective.

  • End-point Connectivity: I don’t think there will be much of a challenge in handling the wired connections. It’s the wireless connections that will pose many challenges. Given the range of devices which will operate with low power, we will have diverse wireless connectivity mechanisms ranging from 2G/3G/LTE, Wi-Fi to Wireless Personal Area Networks (WPANs). There are many emerging & competing WPAN standards such as Bluetooth Low Energy, Zigby, Z-wave, ISA100.11a, WirelessHART etc. Many of these are specified under the IEEE 802.15.4 standard. Some early demonstrations of Visible Light Communication (VLC) have also taken place which may some use cases. It will be interesting to see how all this evolves and which standards the industry will settle upon.
  • Scalability, Performance & Resiliency: Given the current challenges around transition from IPv4 to IPv6, there are many questions on how we can achieve a scalable network that connects tens of billions of devices in the future. Within a private network, the address scalability is unlikely to pose any big challenges, but home automation, wearable gadgets, mobile devices, field sensors, transportation systems, power grid sensors, etc. will require us to solve the IPv4 exhaustion problem and be ready with a truly scalable network. The network should handle diverse performance requirements as we will have low power and low data rate devices such as sensors that may transmit few bytes a minute to high data rate devices such as cameras generating multi-megabit video feeds will generate massive amounts of data. Large scale networks today keep the core of the network simple while all the complexity is handled at the edge. The same principle should help us build massively scalable networks to handle IoT requirements in future. Traditional networks with distributed control planes have provided Internet scale resiliency. I keep hearing about SDN in the context of IoT. SDN with decoupled control plane may work well within the boundaries of a Data Center, but the idea of using SDN to control a network on IoT scale is farfetched given the scalability limits of decoupled control plane. However, SDN may have a role in the hybrid mode where it can perform provisioning, policy and management automation while leaving forwarding decisions to the distributed control plane.
  • Interoperability: Given a plethora of last mile connectivity options especially for the wireless end-points, we should expect interoperability challenges. While no one has any answers, vendor consortiums and standards bodies are showing an interest to address this issue. One should be cautious given the fact that standards bodies will take years to come up with any meaningful and practical standards.
  • Manageability: This is going to be one of the biggest challenges considering how poorly most organizations manage their networks today. With an explosion of devices, network automation becomes an imperative without which network management would be extremely difficult.
  • Security, Compliance & Governance: This is one of the biggest concerns any organization will have regarding IoT. Given the enormous problems with current Network Admission Control systems around design, deployment and interoperability, there is no clarity on how we will classify devices, provide authenticated access, and ensure end-point security for an Enterprise considering IoT deployments. The attack surface has clearly increased with highly mobile devices today, with all sorts of non-IT devices getting connected; security, data privacy and governance become top concerns.
  • Cost: Finally, we have to tackle the issue of cost related to deployment and operations. Enterprises will need strong business case with a RoI model that provides business value in the end. While there are interesting IoT use cases for many industry verticals, it will be the line of business heads that will need to be convinced about the value of IoT and they are likely going to be the key decision makers.

As with any emerging trend early in the hype cycle, IoT leaves us with too many technical questions at present. In the Enterprise business world, IoT adoption and success will be determined by the business value derived from the use cases.

What skills are needed to build and run Software Defined Networks?

Networking world has witnessed heated debates over SDN over the last 2-3 years. Even today, there are debates raging over what SDN is or what it should be. In the middle of all this hype and heated debates between SDN enthusiasts, skeptics and neutral observers, we are beginning to see 1st generation SDN products hitting the market. A survey by the market research firm Infonetics suggests that 87% of medium and large N. American enterprises surveyed intend to have SDN live in the data center by 2016. Only time will the success of SDN and the kind of SDN model that will be adopted (centralized vs hybrid).

Many organizations are now beginning to prepare themselves for the kind of skills and competencies required to run Software Defined Networks. A frequent query that comes up in these discussions is whether or not Network Engineers should learn programming skills. When you look at the structured programming interfaces such as C, Java, and Python provided by SDN vendors, one wonders whether or not a Network Engineer needs to learn these programming languages. These topics were touched upon in a recent article in Network Computing and a blog entry by Greg Ferro.

I agree with Greg that the programming skill would be nice to have to gain insight into the application world, but it may not be needed in the long run as SDN platforms mature and we may have enough abstractions to help address common use cases. In the initial days, programming might be required to address shortfalls in the SDN products. But these skills can be borrowed if the Network team does not have them. In addition, Enterprises do not want to develop and maintain custom applications unless it is a critical business need. On the other hand, scripting skill is highly useful. Network Engineers like me have always found scripting to be very useful to make our lives easier by eliminating or minimizing repetitive and/or structured tasks from our daily routines.

When you consider the Network Life-cycle, other interesting things emerge. Broadly speaking, we can break network life-cycle into Build and Run phases. We should be aware of many unique requirements of these phases not only in terms of skills required, but the size of the network team required as well.

The Network Build Phase will require architects and designers to have software integration skills due to plethora of options available and interoperability will become a key issue if it involves multiple vendors. This is especially the case in Data Centers where SDN controllers will have to integrate with Northbound applications via APIs. These may include virtualization management, network automation, network management and cloud orchestration tools. Cross-technology skills will become crucial for DC network architects & designers to ensure success of these complex software integrations.

The Network Run Phase is where SDN will likely deliver its benefits the most in the form of increased automation. This will require us to change our mind-set from administering the network to orchestrating the network. If and when this becomes a reality, we will be forced to size the Network Operations team size appropriately as simple/repeatable/structured tasks will be automated leading to fewer folks at the bottom the skill pyramid. These might include VLAN, ACL, QoS, basic security and server load-balancing policies among many other things. Since failure is an underlying feature of any complex system, the complex software integrations and sticky architectures will elevate the importance of Network Specialists with deep skills who will help keep the networks running.

We can draw a parallel from what has happened in the Enterprise Telephony market. With network convergence becoming increasingly popular about 15 years ago, Data Network Engineers quickly learned the voice technology to enable VoIP and IP Telephony in their networks. Over the last 10 years, industry has evolved from IP Telephony to Unified Communication & Collaboration (UC&C) which today is mostly software and application integration play requiring UC&C Engineers to be well versed in LDAP, Messaging, IM, SIP Federation etc. While UC&C platforms provide APIs for custom application development, I have rarely come across UC&C Engineers who can also develop custom apps as well. Typically it is left to the application developers to customize UC&C apps for a particular use case that an organization needs.  Teaming is required between application developers and UC&C Engineers to ensure success of such projects. I envisage similar things to happen in SDN space as well where we have to team up with application developers to build custom use cases. It should also be noted that many mature UC&C platforms today provide many features and functions which required custom development just a few years ago.

In summary, to build and run SDN networks:

  • A sound understanding of networking technology will be highly valued. There is no getting away from the fundamentals.
  • Cross-technology skills will be essential (more so in Data Centers where complexity is higher)
  • Scripting skills will be very useful in creating quick and dirty automation use cases which may not be readily available in SDN products
  • Programming skill will be nice to have, but not a must. In the long run, SDN maturity should enable availability of higher level abstractions for Network Engineers to address most of the use cases easily without the need for custom programming.