By

Brian Antao, Ph.D. (Vanderbilt Univ.)

---

Well What seems to be the problem with First the Simple Hard-Wired Broadband Services not ramping up in speed in sync with the evolution of Fibre-optic Technologies ?

The problem is simple — Fibre-optic technology simply entails processing in the Optical regime, where as older generation of technologies that relied on Copper Wires as the transmission media plain and simply used these copper wires and hence inherently slower by their physical realisations in copper conductors.

So what has happened is the Fibre-Optic Technology that has emerged since has not been “Thought out Well” to be implemented and fabricated at “The Systems Level” — This being a complete different Processing Domain — “Optical” it should have been foreseen that Fibre-Optic Networks needed to be fully realised and isolated or some form of iso-coupling with the Copper networks had to be designed and put into place in order to best take advantage of the “Optical Processing Speeds” — “Without This ISO-Coupling” between the Copper-Optical domains what we have ended up having is what it is now an “Hodge-Podge” of mixture and tincture of Optical-with-Copper networks that are just piggy-backing Fibre-Optic over the Copper Wires !!

Well of-course you would say that the Optical-Copper boundary already has bi-directional in a manner of A/D Converters, but the issues still seem to exist at this O/C bi-directional Converters —

1. Are these O/C bi-directional Converters developed to the extent of our well pushed to the limits A/D Converters ?

2. We need a significant more effort to develop these as a special field of expertise and evolutionary development… to be developed in the same manner as the field of A/D Converters converging to perfection…

3. Just like the A/D Converter necessity, we will face with the perpetual need for the O/C Interface, hence we need renewed efforts just focused at this O/C Conversion “Bottleneck”

4. And last but not the least and quite obvious fact is that we need to “Minimize the number of O/C Interface elements as much as possible !!

Hence Cannot stress enough for the push to develop the “Bidirectional Optics-Electrons or Optics-Copper” Conversion field !!

Similar Coupling Issue with Wireless Communications:

A similar situation seem to exist for the “Wireless” Carriers as well … we have the different Technologies as well with in the Mobile Phone space — 2G, 3G, 4G and now talks of 5G … each of these can be viewed for example, 2G == Copper Wires; 3G == Optical Processing etc. So the 2G Domain has Got to be Completely Separate from 3G with the similar ISO-Coupling and 4G again completely Separate with ISO-Coupling …

So in the Wireless Communications spectra — We have a similar mess to deal with when the Connection switches across the Technology Domains — 2G<–>3G<–>4G We need to formalise the 3G/4G Conversion Process, and refine these 3G/4G Converters !!

                          “So we have this Huge Technology Mess On Our Hands”

Need For Mobile Apps to 4G Enable 3G Devices:

On the lines of the 3G<–>4G converters, we do need the various Mobile Apps Developers to work on and develop these 4G-Enabler Apples for the older range of 3G Limited Mobile and Tablet Devices … of course we would not see the complete vanishing of all 3G Devices so soon so it is a worth-while endeavour to pursue where we should see these 4G-Enabler apps which could be implemented in various “Architectural Forms” in order to Enable the older generation of 3G Devices to respond and take advantage of the 4G Features in the Wireless Service, where the Coverage is 4G; Instead of remaining locked and suck out the 3G signal. One form for the 4-G Enabler could be in an Emulator form, just Emulate the processing of 4G features in a 3G Configuration.

Good Software Methodologies recommended for use:

1. Altassian JIRA for Task Management.

2. Agile as the Software Process.

3. Jenkins for Continuous Integration

4. Ant or Maven for Build processes take your pick or both …

5. Use Custom Build Systems for e.g. — Contact Alex Russell formerly of Thrupoint Plc.from Cardiff, and see if you can acquire from him a nice Java Based Build System that would be neat to use.

=====================================