Technology, Innovation & Telecomm

Welcome to the third in a series of tales of woe from the family garage.

So far, I’ve given you a flavor of the range of damage that my father and I inflicted on our hapless garage doors when I was a kid. The fun doesn’t stop there. No boy! We have even more stories of the strange and unlikely carnage visited upon those faithful barriers.

My dad enjoyed running cars pretty hard. He had a good time with all the stuff teenagers love to do with them: doing doughnuts in snowy parking lots, burning rubber, driving fast, and skidding to a halt…long after he had been an adult. No sweat though, ’cause we loved it.

Anyhow, the driveway leading to the garage ran up the right side of the house and it was gravel. The garage itself was situated such that part of it was actually behind the house, while the section that housed my mom’s car was directly in-line with the driveway. As a result, when you wanted to pull a car into my dad’s side of the building (where we did body work, light mechanical stuff, and collision re-builds), you had to make a slight left turn, followed quickly thereafter by a slight right. No big deal.

One of the things that my dad loved to do was to pull into the driveway at a fairly fast clip and then stand on the brakes as he performed the little “left-followed-by-quick-right” maneuver. The effect was to skid in the gravel right up to the door. Truth told, I think it was a personal challenge to him to see just how close he could get, but that’s just my opinion.

He was performing this little stunt one day, when the car he was driving decided on its own that its braking performance was not going to be all it should. Mind you, the brakes didn’t fail completely or anything like that. They simply “faded” rather than “grabbed”. There was a slight gravel skid with the associated left and right…followed by the nose of the car punching yet another hole through the garage door. The car stopped alright. It just wasn’t where my dad expected it would be. Score another repair for my father. …And some points for the pessimists of the world, since now the universe was once again out of balance.

Score:

1. Mom’s door: 1
2. Dad’s door: 2

(I suspect that nowadays, someone might think that the poor garage was some kind of terrorist training grounds, what with the use of various vehicles for dealing that kind of destruction)

Take heart though. Balance was later restored…

So, SuperComm 2005 has officially come to a close. In a way it’s kind of sad, since this is the last one.

For the last 18 or so years, SuperComm was the collaboration of USTA (U.S. Telecom Association) and TIA (Telecommunications, Industry Association) and held in a few places, including Chicago and Atlanta. The two organizations have decided to go their own ways over differing views of the direction the show should be headed in general.

As a result, there will now be two shows, one put on by TIA and the other hosted by USTA. TIA will continue to use Chicago and will be run at about the same time next year, while USTA will be hosting its new show in Las Vegas. It should be interesting how this shakes out for vendors that are used to showing at SuperComm. It was the biggie of the year for Telecom vendors and now that it’s being split up, one wonders how different equipment and service providers will divide their efforts…if they do. It used to be that vendors would use SuperComm as *the* show for introducing new products and services and just being there was practically an implicit “must do”. Now, folks will need to decide if their budgets will support two shows, or if in fact one or the other is more targeted towards the markets they serve. I don’t know what my company plans to do. It’ll be interesting.

It goes without repeating that the focus of this year’s show was IP everywhere. Specifically how voice, video and data can be efficiently implemented in the telecomm vendors’ space. It’s seen as a battle against the cable MSO’s, but I really wonder:

> It seems that the Telco’s are in an excellent position to capitalize on the wireless infrastructure, as they’ve done so well to date. One kind of wonders why they feel the burning need to have the video side too…

> The cable folk on the other hand have long had the video side of things handled really well and have been continually improving their networks. Why would they feel the desire to take voice business from the Telco market?

It almost seems to me that these guys want to play in the wrong sandbox. Mind you, I’m not against competition in principal and I suppose that it helps to drive technology. But, you have to wonder if the end user really makes out at the end of the day. Either way, it’s good for me and my industry and God knows I’ll try to make the best products for our target as I can.

It was a good show. I enjoyed the classes and I think that it was worthwhile attending. Oddly though, I always feel like I’m in another world during these things, what with all the shiny new tech and glitter and fanfare. In the end, I miss my wife and home and reality begins looking really good after about 3 days. I’ll be happy to be back.

Now it’s time to apply what we learned.

I’ve found it kind of interesting that for the last several years, “Carrier Class Ethernet” has been a tag line for various products. The notion behind that phrase is that traditional LAN-based Ethernet doesn’t have the reliability and quality of service (QoS) that other transports like ATM, SONET, SDH, etc. have always had. All very true.

So, various vendors and industry consortia have been trying to get it right. Standards have emerged that are intended to address the gap and to make it possible for Ethernet to be the true transport for the world’s IP and other traffic. MPLS was developed, for example, to address a few needs. One was the need to make it possible to establish a known route through a network, between various end-points. Another reason was to allow equipment to be able to make switching decisions very rapidly, doing the least amount of frame disassembly and inspection as possible.

All that is to say that Ethernet has had kind of a rough road becoming the primary delivery vehicle throughout a Carrier’s network. SuperComm this year has seemed to focus more heavily than ever on IP-based services (voice, video, data, etc. - see the prior post), with a tacit belief that all this will eventually be carried by good old Ethernet.

Here’s some interesting information (based on various vendor’s opinions):

1. There needs to be better QoS features within Ethernet. Vendors then need to make consistent use of them so that end-to-end quality can be assured.

2. Ethernet is quite complex to set up and run when it lives within the core of a large Metro- or Wide- area network. Don’t presume that it’s somehow vastly easier than current technologies.

3. While ATM is assuredly on the decline, last year more ATM gear shipped than ever before. Vendors have de-emphasized development of ATM gear in favor of Ethernet, but these things take time for adoption, once it starts.

4. To achieve the kinds of bandwidth and bandwidth density that the market feels will be necessary, a lot of the existing SONET/SDH infrastructure may not be adequate. If you believe that a consumer will need 50 Mbps, that seems very true. Thus, carriers are pushing fiber directly to xDSL DSLAMs at Gig-E and 10Gig-E line rates. That’s expensive and time consuming.

5. It’s not clear to me whether Ethernet in the core is really any cheaper for the carriers or the consumers directly. I think that various vendors are in the same predicament. Time will shake a lot of that out, but at the moment it could well be mainly customer perception, rather than reality, that shapes the desire for “All Ethernet, All the Time”.

That’s all the news that’s fit to print and I have to get ready for another day at the show.

One thing is very clear: The so-called “triple play” is at the top of the telephony providers’ list of ” things to do”.

Not that this is some kind of news-flash, but there is certainly more evidence at the SuperComm show this year that it’s the current hot-ticket than I’ve seen previously.

That’s what they agree on. What’s perhaps more interesting is what they don’t. For example, one provider claims that 20 Mbps will serve the needs of the market for the next 5 years. Another vendor believes that’s a pipe dream and that in fact, consumers would be using 100 Mbps if it was available today. Still others claim that the only true answer to the bandwidth problem is to run fiber directly to the customer premises. The counter-claim is that one can achieve the same results by parking fiber at the curb, within the last 500 feet of the customer.

One thing is clear to me: There will be no single solution in the coming years that addresses all of the projected needs for bandwidth and associated content. It’s in this blend of technologies that a number of opportunities lie. Moreover, the types of services that will become possible once those kinds of data rates are achieved make for yet more opportunities for those creative enough and gutsy enough to pursue ‘em.

Areas and technologies to watch:

1. Beware the impact of service providers who “selectively manage” their bandwidth. That is, if you buy your pipe from provider “x”, watch out for how they manage the traffic for some service that is provided by another service vendor. If the pipe vendor also offers that service, you may not get the performance you expect. Anti-competitive? You tell me.

2. Mobile content. Look for companies to begin working the notion of “portable data” in the sense that they will offer servers (in your home or on the net somewhere) that know your preferences regarding movies, music, email and other content and will make that content available to you regardless of where you are. The implications for the mobile networking folks is obvious.

3. “Narrowcast” video will begin to find new homes once mobile high-speed networks truly become ubiquitous. Keep a close eye on the cellular providers and technologies like WiMAX to see where they’re headed. It’s clear that your data will become location independent. It’ll be a great time to be a podcaster and video-caster.

4. In-home network delivery systems are beginning to mature. Technologies like “media over cable”, power-line networks, phone line networking, etc. are beginning to take their place in the consumer premise.

It’s looking to me like the opportunities in the telecom market are returning. Just watch whats’s happening in the data, video and voice marketplace to get a small taste of the changes that now beginning to occur.

As my friend Sean well knows, I would really like to get my hands around a project where I can make use of Linux in an embedded system.

I’ve come close in the past; really I have. But every time I think there’s an opportunity, it seems that some situation arises that squashes it. However, a glimmer of light has started to creep into my peripheral vision…I think.

In the past when an opportunity has been there to make use of Linux, the real-time aspect has not been too heavy. That’s made the choice fairly simple, since I had a sufficient level of confidence that it would more than keep up. However, in this new possibility, it may be that a standard Linux distro may not do the trick where raw speed is concerned. To give a general scope, I need to be able to deal with Gigabit Ethernet speeds. We’ll have some hardware assistance, but I need the application to really scream.

I’m aware of a number of changes in the 2.6x kernel that makes it somewhat more amenable to semi real-time applications, but it still seems to me that it is limited enough to consider one of the real-time variants that exist. So, a number of questions come to mind with respect to the hard real-time needs of a high speed application:

1. With any particular variant (standard distro’s or something with real-time extensions), is there a way to put into place very high-speed, deterministic processes that can then communicate with lower-priority, more traditional Linux processes? It occurs to me that I’ve seen products that essentially place an RTOS above the hardware, which in turn runs Linux as a task. My concerns there run to points such as what happens to memory protection in that case? How do real-time processes communicate vs. Linux tasks? How do real-time tasks communicate with Linux tasks? Can the RTOS run in non-protected mode while Linux operates using memory management? And so on…

2. How complicated does the whole thing get with respect to the fact that this application will be hosted on non-Intel hardware that uses FLASH as it’s primary storage instead of a hard disk? If we assume that we’ll be using some variant that has an RTOS at the bottom, how can one partition FLASH up so that both Linux and the RTOS can gain access safely?

3. Can you (here I assume that you can, but I’ll ask anyhow) install interrupt handlers that run independently of the Linux kernel? What are the implications of direct hardware access? That is, I presume that the RTOS portion (again assuming something structured that way) gives you that ability to drive devices in some efficient manner.

4. Just how real-time can I get? (big, broad question)

I’m quite sure these are all easily answered and there are guaranteed to be many more-significant questions to be asked. These stem from my general ignorance of using Linux in such an application and are what pops into my head initially for some reason.

So, if anyone has experiences that they’d like to pass along, I’ll be more than grateful to hear them. Lord knows if I’ll actually get to use Linux this time, but I’m gonna try.

All info greatly appreciated!

Another area that I’m a bit concerned about is the whole issue of GNU and what our final responsibilities would be there. I know the general rules, but I’d love to hear from folks who’ve been through the process.

In 1978, I remember desperately wanting to get an Apple II. Truth told, I wanted just about any of the home computers that were big at the time. Do you remember the Sol I? How about the RCA Elf-COSMAC (VIP?)? Now there was an interesting architecture. Registers, registers, registers… There were a ton of totally cool machines, and boy I was totally lusting after each of ‘em.

My first computer was a KIM-1. It had 1K of RAM (if I recall). I managed to up that to 3K by adding a 2K static RAM to it (via wire-wrap wire, perf board and metal stand-offs). I also kludged an RS-232 port onto it so I wouldn’t need to use either the calculator keyboard and 7-segment displays, or the current-loop interface for teletypes… Had great fun modding that thing but oddly, I did’t write a lot of code on it. At the time, I was actually a bit averse to assembler/machine code. Next, I got ahold of a Sinclair ZX81. It was a computer made in England that eventually became the Timex-Sinclair 1000. It’s predecessor was the ZX80. Both were based on the Zilog Z-80 and were doggone cheap for the time. I ordered mine from the UK. Took a long time to get and sadly, it also wasn’t the best vehicle for my computer discovery. I was silly enough to purchase the 16K RAM pack and some software for it. Geez, that stupid RAM module was touchy since it was parked at the back of the already-small computer and stuck up above it. Any movement of the machine (and that was a dead-bang certainty given its size) and you risked losing everything in memory. While I didn’t make much progress on that machine at the time, hindsight has given me a certain respect for it, since Sir Clive Sinclair did a bloody good job of cramming a pretty significant amount of stuff into 4 IC’s.

The first truly useful machine that I got was a Commodore VIC-20. I think it had 3K of RAM but was blessed with a full-sized keyboard. For some reason that machine just clicked with me. I managed to build all manner of hardware interfaces for that thing, including motor controls, speech synthesizers, analog I/O, DTMF decoders, etc. It’s BASIC was pretty powerful and you could get to the heart of the thing pretty easily. It was based on the 6502 and had a 40-column display. I loved it and moved on to the Commodore 64. Since the two machines were so similar in principal (I know, the ‘64 had way better sound capabilities, more RAM, better graphics, etc.), it was a natural for me to move over to it. Somewhere in there, I got ahold of a Rockwell International AIM 65. That was also a 6502 machine with a full-sized keyboard and a decent little LED display. It pre-dated the Commodore hardware, but I got it later on. It was also a lot of fun to develop hardware for. That was my last non-PC hardware until I purchased a Macintosh many, many years later.

The point of this little diatribe is that I somehow managed to gain a lot of valuable experience from those little pieces of hardware. It was a loving exercise in electronics, computers, & software. And…I worry that that kind of experience is harder and harder to come by. While I wasn’t directly involved in the revolution, being a kid around the time that personal computing was being born was quite a priviledge. How does one go about getting the same opportunities? Having electronics as a hobby is pretty hard for a kid these days, since so much of the silicon out there is highly integrated and oftentimes surface mount. One has to be pretty deft to do that kind of fine soldering, etc. to make the kinds of things that would be interesting these days. You can get hand-held game machines that have thousands of times the computing power and resources that we had when I started out, so what I see these days is a kind of “so what” attitude towards tinkering. Not sure what the effect of that will be in the long run. I do know that those experiences were invaluable as I entered the professional work-force.

I suppose I’m getting old and this is the kind of diddy that you’d expect from a geezer (hey, I’m an early-40’s dude. Not *that* old…). I always said I wouldn’t do it. You know, pine for the good old days. But the truth is that I think it’s pretty hard to come back to that kind of experience. And I guess time has moved on to other areas of focus for younger, tech-inclined folks. Let’s hope that their version of what I was able to experience is as much of a blast as I found it!

The realization has dawned on me slowly.

Over the last couple of years, I’ve been acquiring tools for “personal media publishing” — bits of hardware and software that allow me to actually produce and distribute things like music (see my previous posts on some recording I’ve been doing), video, print, etc. I guess I didn’t realize that it was happening, but it’s finally become clear to me: I’m a wanna-be media mogul.

That’s right. I want to be in the media business, creating music, producing video, publishing text and distributing it all at my leisure. To that end, here’s some of what I’ve acquired the ability to do:

> I can shoot pretty decent quality digital video on my JVC Mini-DV camcorder. This can be imported into my Mac, where with iMovie I can edit it, add effects, put in music, and generally produce a nice end product that can then be exported into a variety of formats.

> Not only can I put music into the video I created, but I can *compose* that same music, using a variety of tools not least of which is a package called “Garage Band”. With that product and others, I can compose a pretty nice range of music to accompany video content of all sorts. In the hands of a real composer, even better results can be had. I’ve posted a few of my compositions on the main Web site for Schoolhouse Multimedia (figured out yet why the site is named what it is?). Take a look under the “Music” link.

> With the output of the first two elements, I can author and burn DVDs with titles, menus, music, effects, scene selections, etc.

> I have a printer that will produce output on printable CD’s and DVDs. As a result, I can create low-quantities of highly polished-looking media.

Add to that the various tools that I have for recording, editing, mixing and sequencing music, speech, etc. and overall I have a pretty complete suite of media production facilities right in my home office. (Can you say “PodCast”?)

Trouble is, with all of this ability I’ve yet to really put it all to good use. Part of the trouble is that I’m not a professional in any of the particular areas that I’ve mentioned: video, music, etc. Lord knows I love all that stuff, but the simple fact is that I make my living developing software. I post on the blog partly to satisfy one of my other desires: to write. Again, I’m no professional and heaven knows I don’t make any money at it.

What has continuously impressed me in the last few years is just how much I can do from one desktop computer. 5 years ago, it would have been prohibitively expensive to do what I can do today for under 5 Kilobucks. And we’re not talking about poor-quality stuff. Having no talent whatever, one can now put out some truly polished looking … junk. Crap is still crap. It’s just that you can make some fine looking crap these days, and you can do in record time. Heck, Apple just introduced Final Cut Studio. It’s a combination of Final Cut Pro, Soundtrack Pro, Motion, and DVD Studio Pro. That combination of truly professional tools cost less than $1500.00 and we’re not talking low-end or even middle of the road here. These are tools that Pros are using for things like corporate video, documentaries, and Hollywood productions. Imagine professional video, sound, motion graphics and DVD authoring for that price!

So, in a perfect world I’d find someone who’d pay me to write articles, compose music, shoot, edit and produce video and publish the results on CD, DVD and the Web. And, along the way I’d get to develop interesting software. A pipe dream I know, butI can dream can’t I?

Know anyone who’s willing to take me on?

The title of this blog of course starts with “Technology” and ends with “Telecomm”. To date, I think I’ve managed to put out a few words on those two topics and even the middle one.

Since I’ve been feeling a bit guilty about spending so much space on issues *other* than the original target ones, I figured the following rant would help assuage my need to be true to the name. Note too that I work in the telecommunications industry and this post has particular poignance for me right now.

I’m responsible at the moment for developing a communications interface (I hesitate to call it a protocol, for reasons that will become clear presently) called “(T)ransaction (L)anguage 1″, or most commonly: TL1. I’ll apologize in advance for what I’m about to say, to those who know and love TL1…but I believe that this has to be one of the poorest excuses for a communications interface (human or computer) that has yet been invented.

I’ve implemented a pretty significant number of protocols in my years as a developer. I don’t at all claim that I’m an expert on the subject, but having done them has given me at least my own perspective on what’s good or bad. First, here’s what’s good about TL1:

1. (…)

Ok, let me move on to what’s bad about it… Just kidding. There are at least a few endearing qualities to TL1:

1. It’s text-based, so it’s fairly easy for a human to understand and enter.
2. It has at least a vaguely common form from implementation to implementation.
3. It’s used in telecommunications vendors’ gear across the industry.

Here’s what’s bad about it:

1. There’s no real standard per-se to the structure of a TL1 transaction. There are recommendations as to how one should structure TL1 messages and what the responses should look like. But, they’re seemingly just that: recommendations. More on that in a second.

2. TL1’s been around for a good while, which means that vendors have managed to implement their own variations that often don’t quite mesh with other vendors’ versions. The “standard” has been evolving for a long time, making the whole spectrum of implementations pretty wide… It has the feel of something that’s grown out of years of work by summer interns…

3. Telcordia (formerly BellCore) is tasked with keeping the standards related to the telecomm industry, but they have to be mindful of the fact that folks don’t just throw away old equipment simply because its TL1 isn’t up to snuff. That said, virtually everything that preceded any given incarnation of the spec has been grandfathered-in.

The basic structure of a TL1 message is this (fully-qualified):

VMM:TID:AID:CTAG:GENERAL_BLOCK:DATA;

Where:

VMM represents the specific command being issued. VMM stands for (V)erb (M)odifier (M)odifier and is essentially a dash-separated construct representing a unique command.

TID (target identifier) is an identifier that usually refers to the piece of equipment you are actually communicating with directly.

AID (access identifier) is the name of the logical entity within the device referenced by TID that is the target of this particular command.

CTAG (correlation tag) is a host-assigned identifier that is returned by the target of this message to allow the host to correlate responses to their associated command.

GENERAL_BLOCK is fairly complicated and is frequently ignored. It can be thought of as belonging to the DATA portion of the message if you like.

DATA is the actual payload of a given message.

Sounds good, right? Wrong. Things being what they are, a message like this is entirely possible:

VMM:CTAG;

As you can see, there are a few missing elements. Most critically, the TID and AID fields seem to be missing. It’s actually OK that there’s no GENERAL or DATA sections. But what makes TL1 so infuriating is that the above message has actually been implemented in some gear.

Another annoying feature of the language has to do with the DATA portion of a TL1 message. There can be fundamentally two types of data. The first is what is known as “position dependent”. The second is (shockingly)…”position INdependent”! The position-dependent data are just that: The data each represents is indicated by WHERE in the message each parameter appears, so the order is critical. Position-independent values are represented by a KEY=VALUE-type structure. This allows the values of various parameters to be located anywhere within the DATA portion of the message. One only has to locate a particular key in order to determine its value. Data parameters (it’s recommended) are to be separated by commas. Alas, that often ain’t the case.

I’ve seen the DATA portion of some TL1 messages structured similarly to:

Parameter,Parameter:Parameter:Parameter

…or some similarly ugly form.

So, from the perspective of a host software developer, the fact that each vendor can more or less structure their TL1 any way they like makes life pretty difficult. You have to have a fair amount of specialized code in place in order to accomodate the bizarre variations that occur, or you must invent some kind of “Rosetta Stone” mechanism that allows you to map your data to the proper form required by a given piece of TL1 equipment. And, that still implies that you manage your TL1 on a per-equipment basis rather than being able to rely on a standarized form at least.

Responses are yet another matter. The form of a TL1 response message in no way relates to the structure of a TL1 command. You’d think that responses would be formed in the same general way. Nope. Not by a mile. Where a TL1 command has colons that generally delineate fields of the message, TL1 responses are a mash-up of time stamp, textual response codes, CTAGs, and free-form data. There are essentially no hard field delimiters, so one has to have some significant text-processing capabilities to deal with the range of possible response formats. One never knows, for instance, if a response will be formatted for consumption by a human or simply for a computer. You may see a response that contains carriage-returns and line-feeds so that it’s more readable…or you may not.

My gripe in this situation (among so many others) relates to the other side of the equation. As an equipment vendor, it ought to be pretty simple. I should just be able to define my own dialect of TL1 commands and responses, and issue a spec that tells anyone using my stuff just how to talk to me. But I can’t. Why? Because my equipment has to be cameleon-like. I need to be able to emulate the behavior of other types of equipment, since the hosts using ours may not be able to be modified to accomodate. Thus, if I have to behave like equipment ‘X’, then I need to know a priori how to manage messages that will arrive. It’s no walk in the park to figure out how to deal with a whole suite of implementations in a generic fashion.

There is a Web site, hosted by Micromuse that has a pretty good description of TL1. To read it, you’d guess that TL1 was the greatest invention in American Telecomm in the last century. But, the industry demands TL1 support and who are we as suppliers to object? Why can’t folks start moving towards emerging standards like Web services, browser-based interfaces, Yiddish, etc.? Because history prevails and there’s an awful lot of gear out there that spews this cruft, that’s why.

There. Geeky enough for you? I hope so, since it’s been a part of my recent work life and frankly, it offends my technical sensibilities. I had to unload. You paid the price.

We now return you to your usual feather-weight postings…

I use a really nice little Mac RSS aggregator called NewsFire ™. It does a fine job for me, has an elegant interface and gets out of the way when necessary. It integrates nicely with Safari, the Apple Web Browser for OS X. And, it cost $19.00 US. One of the nice little convenience features of NewsFire is that it will attempt to discover the RSS feeds for the page that you’re currently displaying in Safari. It’ll do the same for a specified URL if you know it. Anyhow, I was trolling the Engadget site and saw a reference to a research product called the “Hug”, developed at Carnegie Mellon University here in Pittsburgh.

As it turns out, the site that this came from is called “gizmag“. They have a print magazine as well as the site. It’s a cool site for gadget geeks like myself. I’m glad I stumbled across it and in the process, found a nice feature of NewsFire. Take a glance at the site and if you run across NewsFire, try it out too.