Recommendations for spectrum allocation in India for 5G

4G and earlier

Despite obvious advantages with respect to interoperability, breadth of coverage and overall capital expenditure, instead of choosing either GSM or CDMA, India's Department of Telecommunications allowed operators to offer services with both radio protocols. For a country that should be worried about efficient allocation of capital, this was a choice that led to short term windfall for the government in terms of spectrum auction prices but eventually led to public-borne losses due to defaults by Reliance Communications [Ref 1].

It is imperative that the relevant government authorities learn from past failures and follow well established international practices on spectrum allocation to come up with a 5G spectrum allocation method.

5G

Expected Impact

5G has significant technical improvements over 4G that are expected to enable new use cases and improve productivity. In particular relevance to this blog, 5G can enable more functionality in connected autonomous vehicles. A study claims that within a decade of investment, economic output per person could increase by up to US $1500 after a decade of 5G rollout [Ref 2].  The 5G global value chain including network operators, core technology and component suppliers, device OEMs, infrastructure providers, and content and application developers, is expected to grow to $3.5 trillion in 2035 [Ref 3].

Early indications

5G has two leading contenders - "sub 6" for frequences < 6 GHz and "mmWave" for frequencies > 30 GHz and > 6 GHz.
The Indian government has, as per early indications, come out in support of the 24.25-27.5 GHz band. This seems a reasonable first step since it aligns with EU and China plans [Ref 4].

Recommendations

1. Align with China.
   Unlike 3G and 4G, where an advanced economy like the United States could afford nationwide rollout of both GSM (AT&T and T-Mobile) and CDMA (Verizon and Sprint), a developing economy like India could gain economies of scale by adopting one standard with multiple suppliers.  The size of the Chinese market can be expected to be supplied by multiple network equipment vendors from around the world.
2. Partake in the value chain
   While base stations will need to change to support the new radio interface, the back-end can be leveraged from existing networks, albeit with lowered latencies and higher bandwidths. India can target specific elements in infrastructure to be sourced from local companies. Software based switching stations, integrated billing software, nationwide emergency services integration, etc. could be targeted for such initiatives.
   Another way to partake in the value chain would be to encourage purchase from suppliers that build their sofware in India.
3. Overlay security on top
   Assume that the underlying network elements are insecure, build a secure layer on top that enables end to end security. 
4. Localize network management
   Prioritize growth in local expertise of network management and software. Network management expertise may lead to custom APIs for Indian needs such as for congestion and emergency management.
5. Finally, accelerate deployment of 5G. ज़माने के साथ चलना पड़ेगा यदि भारत को एक विकसित देश बनाना है|

References

1.RCom plunges more than 20% on mounting debt woes, Q4 loss.

2. Impacts of 5G on productivity and economic growth.

3. 5G global impact 

4. 26 GHz band for India

Empowering software integration

Software integration is often looked down upon in the software development community despite the key role it plays in the software delivery process. Quite often, even the broader scoped Software Configuration Management is not given its due in terms of resources or recognition. Here are my suggestions to make software integration contribute in a more meaningful way to make the entire software delivery cycle more efficient:

Software integration is the process of pulling multiple sources of code together, building them, testing the output and releasing either the source or the generated binary. The established best practice is to enable continuous delivery of software where the integration, build, test and release tasks are handled automatically when new source code is submitted for integration.

Where Continuous Integration starts to particularly break down is on embedded systems when the work output of largely independent software teams is integrated and the resultant output runs on a single processor with constrained memory and clock cycles. Each team contributes to thoroughly testing its own deliverable, but an integrated test is needed for performance under concurrency. Most often, this "integrated test" is simply a concurrent run of the individual tests. The challenge is to select the right tests to run concurrently and to establish metrics that signal the test pass/fail status.

By shifting ownership of the concurrent test and performance metrics to the integration team, one can make the team contribute more meaningfully to the software delivery life cycle. The integration team should establish checks to ensure that each contributing team consumes its pre-established amount of system resources such as memory and processor cycles. This structure also automatically establishes a triage workflow since any concurrency related failures are first looked at by the team that performed the integration rather than the individual technology team, thus speeding up troubleshooting.

Linking test delivery to code, with coverage based pass/fail is a topic for another day.
-Kuntal.