Group Reset Reception Processing

The time has finally come where it is no longer possible to avoid developing the ill-specified Group Reset (GRS). Our siege of the GRS was broken while SMG was undergoing conformance testing in Belgium. We knew this day would come and it's good that we could hold out as long as we did, because the time has allowed the general approach to circuit maintenance in ss7boost to mature and improve to handle many circuits under stressful conditions. We are ready to implement GRS reception. We continue to resist implementing GRS sending for reasons we offer in detail at the end of this article.

The base ss7boost 1.0.2.x is in lab test and has passed calls in both directions. This revision has the first working version of the Circuit Maintenance Manager for queueing and executing requests for circuit reset, block, and unblock. The CMM is required as the base for developing GRS reception processing to ensure compatibility with the new circuit maintenance model in ss7boost.

GRS reception processor decomposes the request into individual circuit reset requests that are each then submitted to the CMM. The CMM queues the requests and manages sending the reset requests to the core circuit reset reception handler (CCRH). The CCRH performs maintenance actions and then passes the request to call processing where the the concerned circuit is handled for reset based on its current state. The final reset action in the CCRH is to acknowledge the completion of the circuit reset. Currently the ackowledgement is a Release Complete (RLC) message sent in response to a Reset Circuit (RSC). ss7boost will be modified to conditionally send an RLC or a completion indication to the GRS processor. This approach will eliminate the need to modify the call processing state machine, which eliminates a significant amount of regression testing to a core function that has approximately 1.1 million hours of field verification time.

Our dislike of the GRS comes from the awkward specification of the Range and Status parameter. The format and coding of the parameter changes if it is being used in a GRS, CGB, or CGU, It also changes if it is being used in ANSI or ITU SS7 flavors. In some instances, it allows up to 30-ish circuits to be affected in a group of up to 256 circuits. This means that it's possible to receive a GRS with a status containing a 256 bit status field with each bit needing to be test for 0 (not affected) or 1 (affected). The Range field assigns meaning to the values 0, 1, and n>1, and if n>1 is used, then the actual count of affected circuits in the Range is n-1. The GRS processor must search of allocate a variable number of octets in the Range. The Range and Status field has a very high degree of variability which drives up the numbers of exceptions and test cases. A great deal of code must be written and tested for the exceptions. The possibility of partial success exists with the GRS, the processing of which is not specified clearly.

The cost versus the benefit of the GRS in a small and distrubuted ISUP implementation like ss7boost is not favorable. Using the RSC for each individual circuit make smuch more sense because the implementation is straightforward. In a large switch with large trunk groups, the GRS makes sense. Most samples of GRS harvested from the field show a restricted and rational use of the GRS in that circuit groups are in the same E1/T1. It is our opinion that the idea of the GRS is good, the specification is too broad and uses tricks to save a bit of space.

Our implementation of the GRS reception will be based on our field samples and a sub-set of the specifications that minimizes the number of exceptions that will be handled. If our GRS reception processor encounters a GRS that is legally forms and yet exceeds the limits we impose, it will rejected and announced. We will consider remedies if this should occur, but we are betting it will never occur.

Merging ss7boost Development Streams

For a while now there have been two ss7boost code streams: stable and development. The stable stream is a repository branch and the development stream is the repository tip. The development stream insulated users from the difficulties of building the Circuit Maintenance Manager. The development stream has reached functional parity with the stable stream in terms of circuit management, and the development stream needs to be tested in the field. The time has come to merge the stable and dev ss7boost streams.

The merge is complicated because the two streams have been apart for several months. A wholesale "diff -up stable dev > patchfile" followed by a "patch -p0 <>