When I returned to Tecways (formerly CCS) in January of 2004, our southeast Asian customer wished to extend their Q3 subscriber administration for Siemens HLRs with a new feature referred to as Direct Q3. This feature uses CMIP-over-TCP/IP rather than CMIP over OSI, as well as a modified MIB. I was able to utilize the IQA CMIP platform that I had developed earlier in order to quickly complete this product.
As the Direct Q3 project was drawing to a close I heard about a different project based on the Alcatel X.29 provisioning solution that I had developed in 2000 for an Arabian customer. This new phase III project was running into urgent trouble. When I investigated, I discovered that the junior engineers who had been assigned to the new project had not properly understood the operation of the system. I took over the project leadership at that point, including the direction of two junior engineers, and completed the project to the customer's satisfaction.
On completion of the Alcatel X.29 provisioning project, I implemented an adapter for Ericsson HLRs, which I then installed at the customer site in Jakarta. This work involved modifications to other components of the Tecways provisioning solution (most of which I had already implemented previously). I eventually took over the project manager role for this product, including both Prepaid and Postpaid streams. I also implemented an adapter for Huawei HLRs for this project.
I started working at Siemens AG in May of 2001. I was initially assigned to the working group "Separation of Control and Transport". The goal of the team was to migrate the EWSD architecture, based on Line Trunk Group cards for synchronous TDM lines, to become a Media Gateway and Controller pair. This involved a complex weave of hardware and many protocols, including new UMTS protocols, legacy PSTN protocols, and transition protocols like BICC. I had privately investigated the H.248 Media Gateway Control Protocol, and was able to claim this protocol as my area of investigation. The working group produced an extensive design paper including the work of dozens of designers covering all aspects of the MSC from ATM hardware to transcoders. I contributed a section about using H.248 for non-call-related operations.
Unfortunately, further development on this feature was passed on to a development team in Athens. As a consequence, I was assigned to help with MSC software maintenance as a member of the Call Failure Diagnostics Team. I took over the ownership of the Cross Office Check and Glare recovery module. This is a mature module which has had minimal changes over several years.
I was surprised at the simple level of technology that is still in use at Siemens. A large proportion of the daily effort is involved in error-prone repetitive manual tasks that could be readily automated. I took it as a personal challenge to demonstrate how the application of established technology could be used to save considerable work. It gradually became clear, however, that there was little understanding of the use of software tools at Siemens ICM and even less interest in changing familiar procedures. I was able to take a favorable opportunity to leave Siemens and return to Tecways during a workforce-reduction program at Siemens (due to a concurrent workforce-reduction program at Tecways, the management asked me to wait 2 months before rejoining in the new year 2004).
In September of 1997, I started work at Chipcard and Communication Systems.
My initial responsibility at CCS was to implement a CMIP interface for retrieving billing data from GSM mobile telephony switches. A CMIP interface for subscriber administration was also required. I was the only OSI development engineer at CCS.
CCS had previously supported billing file retrieval and subscriber administration using file transfer protocols such as FTAM, scheduled by timer jobs. They had tried some time ago to implement a CMIP interface as well, but after two years of effort, the project was canceled.
My first task was to determine if a CMIP development framework could be purchased. It eventually became clear that such a framework would need to run on VMS first, mainly because the Mediation product offered by CCS is implemented only on VMS. Once this requirement was decided on, it immediately ruled out all platforms we investigated, including Vertel, DSET, and DEC itself.
DEC - alone - does offer a CMISE API for VMS, but it is apparently incompletely supported and documented. DEC recommends a third party source for the ASN.1 compiler. But that product is very expensive and offers no GDMO object model support.
CCS does have a simple - non-typed - ASN.1 encoder/decoder that it developed in-house. "Non-typed" is used here to mean that the encoder/decoder has no knowledge of the ASN.1 specification defining the data transmitted - it relies on the simple type information embedded in the data stream.
It was my decision to implement the CMIP interface on top of DEC's OSAK API (layer 6), using the CCS encoder/decoder (referred to here as CCSed). In order to do that, I developed a methodology for building PDUs using a cascade of API's. For example, the CCSed has no knowledge of transfer or local syntax, or how to convert between the two. A new function takes a primitive node of the ASN.1 memory tree and converts it into local syntax. To do this, is uses routines from another API for handling transfer syntax.
A minimum subset of the code is customer-specific, for the two applications of Billing Record retrieval (Alcatel Switches) and Subscriber Maintenance (Siemens Switches). The Alcatel-specific code is 18% of the entire code. The remainder is shared by both applications. Subsequently, this core was used to develop a third CMIP manager, for Hot Billing.
By completing the symmetry of the implementation - whereby both agent and manager sides of most PDUs are supported - I was able to use the same code as an agent simulator, for testing purposes.
Because I am more proficient at Unix than VMS, I did the development and initial testing on DECunix and then uploaded the code to VMS (where I eventually ported GNUmake to simplify the work).
During the development work on the CMIP interface, a customer approached CCS about a mechanism for handling a flood of alarms received from GSM base stations. The Request For Proposal did not specify the format of the alarms or what information would be available.
As a result, I prepared a high-level design of a Q3-compatible manager/agent architecture that would use surrogate agents to process whatever alarm information would become available from the sources and forward these across a Q3 interface to an Event Forward Discriminator. [1] The EFD would refine the alarms according to customer specification. This project would require that CCS create a simple Object Model based on the information obtainable from the alarms and other sources. CCS would also create the EFD and the surrogate agent, which could be resident on any platform that had connectivity to the alarm sources.
In May of 1996, I was assigned to the GSM layer 3 protocol development team of AEG Mobile Communication. During my stay at AMC, I worked primarily on Supplementary Services (SS).
My first, introductory, assignment at AEG was to port SS layer 3 tests for the GSM phase 1 cell-phone to a new test methodology. The original intention was to have developers write test cases in parallel to new code. These would then be input to a test machine to automatically perform the tests. This idea was later dropped.
My next assignment was to port the existing phase 1 Facility Encoder/Decoder (dubbed FED by me) to phase 2.
The original FED was a beautifully-engineered piece of code. It was minimal and effective, requiring only a few hundred lines of code. Using hand-written tables, it translated between ASN.1-encoded Facility Information Elements and static C data structures.
The problem was that in going from phase 1 to phase 2, ETSI made many changes in deeply-nested data definitions. For someone who was intimately familiar with the Facility IE, the problem might have been more trivial. But it occurred to me that it would be easier to write a recognizer to parse the phase 2 ASN.1 definitions and generate the tables than to try to do a mental phase 1-phase 2 "diff".
Rather than writing the parser from scratch, I took the lex and yacc parser from the public-domain SNACC ASN.1 compiler, [2] and using a lex tool I wrote, stripped all the C code out of the yacc file. I then tweaked this and the lexical front end until I could parse the Facility IE.
Once I had an ASN.1 recognizer - utterly trivial, in the sense that it merely recognized the language, but did nothing - the next job was to generate tables that the FED would recognized.
In order to do this, I augmented the parser to generate four lists: types, ANY-DEFINED-BYs, arrays, and members. These were readily available from the syntactic structure of ASN.1. Next, I generated a recursive routine to traverse these lists and generate an array of tables, one for each legal ASN.1 sub-object of a Facility IE. Finally, a routine to process each array entry and output a proper FED table was required.
A few slight changes in the original strategy of the FED were required to make it all work. For example, the hand-coded tables of phase 1 used names to refer to linked or embedded tables. This was no longer possible with the phase 2 data model, so I used generated table array subscripts instead.
Once the table generator (gentbl) prototype was completed, the next step was to test it. The first question was, would it generate the same code as the hand-written tables? To test this, I wrote two new lex tools. One took C data definitions according to the conventions of the original hand-written tables, and converted them to a canonical, representative form. The second tool took C data definitions as generated by gentbl and converted them to the same format. I fed the phase 1 ASN.1 definitions to gentlb and then diffed the output with that from the hand-written tables. After some debugging, the two representative files converged.
My next assignment was to recode the SDL specification of the layer 3 portion of Supplementary services. The development strategy at AMC was to use an SDL-to-C translator to generate the C code. But because the specification teams [3] didn't want to be encumbered with the details of translation or hardware, they would first write an abstract specification, and the implementation teams would rewrite that to a form of SDL recognizable by the translator.
It was my contention that it made no sense to rewrite the same expression twice. Either the specifier's specification was correct or it was not. If it was correct - at some abstraction level - then the code necessary to make it run could be inserted underneath as a sub-layer or API. It was only required that the specification team code to a single abstraction layer.
For example, the specification team was used to using SDL comment boxes to say things like "increment the invokeID". I encouraged the specifier to whom I was assigned to instead use an execute box called increment_invokeID. I would then write a procedure called increment_invokeID() which would be linked with the code generated by the translation of the specification to create a runnable image.
Although for various political reasons, I didn't have much success getting this approach pushed through generally, I was able to implement it successfully with layer 3 Supplementary Services.
My next assignment was to assist the Mobile Network/Call Control team in converting their specification to C. The Mobile Network was an AEG-specific layer above layer 3. By this time, it was clear that the redundant specification/implementation coding strategy was inefficient, and the MN specifiers' job was expanded to generate runnable code. It was my job to supply APIs as necessary to build a runnable module.
The major work here was to write an "adapter" to convert the new SDL-format primitives to and from the legacy (C) primitives so that the MML layer above would not yet need to be modified.
The next assignment was to complete the specification of the MN/SS layer for an employee who had been let go. This was a basically trivial SDL program and the necessary test cases.
The project I worked on in my final weeks at AEG was a proposal for replacing their obsolete build procedure - based on a complex network of generated Makefiles - with a simple Gnu-make Makefile.
I left AMC because of my concern that it would close shop, or, at least, let go of their contractors (which they subsequently did).
At Motorola CACS, I was a member of the team that was responsible for writing the CMIP agent. For the most part, this was the straightforward, mechanical, task of mapping Managed Object operations - as presented by the DSET toolkit that we used - into operations on the Cable Control Unit's native database. The trick was to access the DSET data structures properly and to avoid creating memory leaks.
Besides the repetitive task of writing agent code, I became involved in a number of tool support issues. Because of my experience parsing GDMO that I acquired at Motorola WDG, interest arose in analyzing the MIB. I generated a number of GDMO parsing tools, including a cross-reference program and an include file generator. I also built a tool to analyze the voluminous output of the agentTester test manager, in order to ensure coverage and spot errors. I also built the GNU-Makefile so that the DSET tools could be included into the project standard "standard makefile format".
I left Motorola CACS to take the opportunity at AMC to return to Europe.
The product being developed at Motorola WDG was a Cellular Digital Packet Data base station. My first, introductory, task was to contribute to the development of the SNMP agent.
Subsequently, I was able to start the installation of the Open Network Engineering (ONE) [4] OSI protocol stack that would be used for OSI connectivity. This required upgrading the pSOS realtime Operating System to Release 2. This was a non-trivial task because the manufacture switched over from an ad-hoc configuration method to a more automated facility with Release 2. Since there were local modifications to the Release 1 code and configuration, these had to be manually merged into the OS.
The following is recounted as an illustration of my interest in building tools to solve problems.
The base station was a turn-key box for unattended operation, so there was no local operator console. The menu-driven configuration facility was performed by a remote console process using a message-passing protocol. The messages only supported integer data, so an unfortunate methodology had been developed to use this integer data to refer to strings and fields in the remote process. [5] While porting the OSI stack, I developed a procedure using yacc and lex to preprocess the C code and generate the necessary tables. This allowed developers to code messages and displays using printf()-like statements, without having to keep table indexes and offsets up-to-date.
Since there was no team-specific support personnel, I also became involved in support for the CASE tool, CVS, and the maintenance of the GNU-Makefile.
DSET had written a simple prototype CMIP agent for us as a demonstration. After taking the 1 week CMIP agent course at DSET in New Jersey, it was my responsibility to augment the prototype to a full-fledged agent. Unfortunately, we never got a commitment from our customers that they would buy the agent. Motorola delayed buying the DSET package (beyond the limited-time demonstration copy) and then eventually canceled the agent. While awaiting a decision, I worked on the agent and a primitive test manager generator, written in yacc and lex, and based on the MIB.
Footnote 1
An example of a possible information source for such a surrogate
agent is the periodic polling of the size of a logfile via
ftp. This logfile might reside on an OMC somewhere in the network.
Once it got to be a certain size, a Q3 alarm would be generated.
Footnote 2
Note that the parser was a tool, not part of the product,
so no copyright violations were committed.
Footnote 3
AMC separated specification from implementation, which
corresponded largely to internal German teams and external English
teams. This distinction eventually dissipated.
Footnote 4
(now Netmansys)
Footnote 5
A major referential integrity problem arose anytime any message or
table was modified: the offsets in the entire table needed to be
recalculated and updated.