==Phrack Inc.==

                     Volume Three, Issue 26, File 6 of 11

         +-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

                         Basic Concepts of Translation

                               Brought to you by

                                 The Dead Lord
                                      and
                         The Chief Executive Officers

                               February 17, 1989

         +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-+

This tutorial is meant for the hardcore hackers who have entered the world of
ESS switches.  The information here is useful and valuable, although not
invaluable.  You can easily reap the benefits of access to a switch even if you
only know RC:LINE, but to really learn the system in and out, the concepts
about translation are ones that need to be mastered.

In electromechanical switches, switching was directly controlled by whatever
the customer dialed.  If a 5 were dialed, the selector moved across 5
positions, and so on. There were no digit storing devices like registers and
senders.  As the network grew larger, this became inefficient and switching
systems using digit storage and decoding devices were put into use.  In this
type of setup, the customer dials a number, which is stored in a register, or
sender.  The sender then uses a decoder and gives the contents of the register
as input.  The decoder translates the input into a format that can be used to
complete the call, and sends this translation back to the digit storage device.
This is a simplified example of translation, since the only input was dialed
digits and the only output was routable information, but it shows what
translation is:  The changing of information from one form to another.

When 1 ESS was first tested in Morris, Illinois in 1960, it introduced a
switching method called Stored Program Control.  Instead of switching and logic
functions being handled by hardware, it was done through computer programs.
This greatly expanded the translation function.  Because calls are handled by
many programs, information must be provided for each program.  For example,
when a customer picks up a phone, the switch needs to know if outgoing service
is being denied, if the line is being observed, line class, special equipment
features, etc.  The line equipment number is given to the translation program
as input. The translator translates the LEN and produces the answers to these
and other pertinent questions in a coded form that can be used by the central
processor of the switch.

If the call is an interoffice call, the first three dialed digits are given to
a translator as input and they translate into a route index and, possibly,
other information.  The route index, in turn, is given as input to another
translator, which translates into:  Which trunk to use (trunk identity),
transmitter identity, the alternate route, etc.  So actually, in early systems,
translation was a single shot thing, and in Stored Program Control Systems
(SPCS), the translation function is used many many times.

In the 1 ESS, translation data is stored on magnetic memory cards in the
program store.  However, since translation data is constantly being changed,
there is a provision made to store the changes in an area of the call store
memory.  The area of call store is called the recent change (RC) area.  The
changes are eventually transcribed from the call store into the program store
by a memory card writer.

In the 1A ESS, translation data is stored in the unduplicated call store, with
backup in the form of disk memory called file store.  Additionally, magnetic
tapes are made of the translation area of call store.  When a change in
translation is made, the change is entered in a duplicated copy of call store.
After checks are made as to the validity of the change (format and everything),
the change is then placed in the unduplicated copy of call store. After that,
the change is also written to a set of disk files in file store.  Before the
new data is written, the old data is written to a part of the disk file called
"rollback."

                  |------------|-------------|-------------|
                  |    DATA    |  1 ESS      |   1A ESS    |
                  |------------|-------------|-------------|
                  | Transient  | Duplicated  | Duplicated  |
                  |Information | Call Store  | Call Store  |
                  |------------|-------------|-------------|
                  |  Generic   | Duplicated  |Program Store|
                  |  Program   |Program Store|             |
                  |------------|-------------|-------------|
                  | Parameter  | Duplicated  |Unduplicated |
                  |   Table    |Program Store| Call Store  |
                  |------------|-------------|-------------|
                  |Translation | Duplicated  |Unduplicated |
                  |Information |Call Store + | Call Store  |
                  |            |Program Store|             |
                  |------------|-------------|-------------|


Transient Information:    Telephone calls or data messages in progress; present
                          state of all lines, junctors, and trunks in the
                          office.

Generic Program:          The operating intelligence of the system.  It
                          controls actions like line and trunk scanning,
                          setting up and taking down connections, etc.

Parameter Table:          Informs the generic program of the size and makeup of
                          the office.  This information includes equipment
                          items (frames and units), call store allocation (call
                          registers, hoppers, queues, etc.) and office options
                          (days AMA tapes will be switched, etc.).

Translation Information:  Day to day changeable info which is accessed by
                          translator programs.  Also includes form tables,
                          lists called "translators" which are linked in an
                          hierarchical pattern.

This is a quote from Engineering and Operations in the Bell System, pages
415-416:

     "The 1 ESS includes a fully duplicated No. 1 Central Processor Unit
     (Central Control includes the generic program), program store bus,
     call store bus, program stores, and call stores.  The 1 ESS uses
     permanent magnet twister program store modules as basic memory
     elements.  These provide a memory that is fundamentally read only,
     and have a cycle time of 5.5 microseconds.  The call store provides
     "scratch pad," or temporary duplicated memory.

     As with the 1 ESS, the 1A CPU has a CPU, prog store bus, and call
     store bus that are fully duplicated.  However, the 1A processor uses
     readable and writable memory for both prog and call stores, and has
     a cycle time of 700 nanoseconds.  However, the program stores aren't
     fully duplicated, but 2 spare stores are provided for reliability.
     A portion of the call store is duplicated, but only one copy of
     certain fault recognition programs, parameter information, and
     translation data is provided.  An extra copy of the unduplicated
     prog and call store is provided for in file store."

The program store translation area in the 1 ESS and the unduplicated call store
translation area in the 1A ESS contain all the info that can change from day to
day for that office.  Here is a list of things that are stored in the
translation area:
+ Line Equipment Number (LEN), Directory Number (DN), trunk assignments (all
  explained later).
+ Office codes.
+ Rate and route information.
+ Traffic measurement information.
+ Associated miscellaneous info for call processing and charging.

Call store can be thought of as RAM; it is filled as long as the ESS is
powered.

Program store is like ROM; it is physically written onto magnetic cards.  File
store is simply information stored on magnetic tapes (or disk drives).  All
data that's changeable (rate and route, customers' features, trunk selection,
alternate paths, etc.) is called translation data and is stored in the
translation area.

Changes in translation are called recent changes and are stored in an area
called the recent change area.

Once again, I stress that this article is sort of a "masters" file for hackers
who are interested in ESS.  If the concepts are too difficult, don't panic.
Knowledge comes with time.  Don't feel bad if you don't catch on right away.

Translation data is stored in the form of tables or lists.  Each table is
linked in a hierarchical pattern.  Tables high in the hierarchy contain
pointers (addresses) to the lower tables.  Tables low in the hierarchy contain
the actual data.

Most translators are broken down into subtranslators, which are linked by a
Head Table, or "HT".  The HT points to the different ST's stored in memory, in
the same way that a table of contents in a book points to the pages of each
chapter. This way, when a new feature is added, it's just a matter of adding a
new entry in the HT, and having the entry point to a newly stored ST.

Translation input is divided into 2 parts: the selector and the index.  The
selector determines which ST to access, and the index determines which item
(word number) in that particular ST to access.  In some cases, the translation
information may not fit into the space allotted to an ST, so pointers to
auxiliary blocks and/or expansion tables may have to be given.  You can think
of a BASIC program, where a GOSUB points to a subroutine at location 4000.
Now, if the subroutine is 100 bytes long, but you only have room for 75,
another GOSUB must be issued to point to the rest of the subroutine.  So a full
translator is quite a large unit -- it can have a head table, subtranslators,
auxiliary blocks, abbreviated codes, lists, subauxiliary blocks and expansion
tables.  The example below shows a custom calling feature that exists on 5 ESS:
Dog Control Frequency, "DCF".  In the e below diagram, DCF represents the Head
Table, and has a list of pointers that identify the location of subtranslators
"A" through "D".  The data field "2" in subtranslator "D" is too small to store
the entire subroutine, so an expansion table "2A" was produced to house the
entire program.

    *  D.C.F. *  head table
    |
    |
|------|-----------|--------|
|      |           |        |
A      B           C        D  subtranslators
    |
    ---1  data: tables
    |or
    ---2 ---->| lists
    |         |
    ---3      |
    |         |
   etc       % /  expansion
 2-Atable

ESS programs access translators by locating their octal address in the Master
Head Table, which is also called the Base Translator.

1 ESS MHT
%%%%%%%%%
The 1 ESS has 2 copies of the MHT:  One in program store, and one in call
store.  The copy in call store is the one that's used normally, since call
store memory has a faster cycle time.  The one in program store is there for
backup.  The MHT is 338 bytes long (23 bit bytes), and as we mentioned, is used
as a sort of directory for locating translators.  The MHT can point to starting
addresses of Head Tables (which point to translators), or to tables and lists.
Head Tables point to subtranslators.  Subtranslators can point to auxiliary and
expansion blocks, lists, or tables.

There is another Master Head Table called the Auxiliary Master Head Table,
which points to other translators.  There are 2 copies of the AMHT, one in
program and one in call store.  The AMHT is found by accessing the MHT, and for
those interested, the address of the AMHT is located in the 28th byte of the
MHT.  The MHT is fixed; meaning that the first byte will ALWAYS be the address
of the DN translator.  The last byte will ALWAYS be the address to the JNNL to
JNNT/JCN Head Table (explained later).  ESS needs a table to read this table.
Otherwise, how would it know what byte leads where?  There is a "T-reading
octal program" located at (octal address) 1105615 in the parameter area in the
program store.This address is stored in the generic program and is used to read
the Master Head Table.

1A ESS
%%%%%%
A 1A ESS switch call store byte contains 26 bits, named 0 through 25, which is
a lot more than I can say about an Apple... Bits 24 and 25 are used for parity,
and are not used for data.  This leads to what is known as a K-code.  No, a
K-code is not used by lowly software K-rad pirates, but it is used by us ESS
hackers.  Each call store K-code contains 65,536 bytes, and can be thought of
as a "page" of memory.

Anyway, translation data is stored in the unduplicated call store.  Remember,
we're still talking about 1A ESS.  In generic 1AE6 and earlier, unduplicated
call store starts at K-code 17, and as more translation data is fed into the
system, it pushes down into K-code 16, 15, 14, etc.  In generic 7 and above,
call store has been increased by a great deal, because of a huge memory
expansion unit.  On the early generics, the entire call store and program store
had to fit in 38 K-codes.  In the later generics, there are 38 K-codes assigned
to call store (that's split between duplicated and unduplicated), and another
38 K-codes for program store.

Not all K-codes may be used, so it's not really a full 38 K-codes, but hey, you
can't have all your memory and use it too.  Anyhow, because generics 1A E7 and
higher have such huge call store memories, it's convenient to divide call store
into 3 parts:  The "duplicated call store" (DCS), which is located at the very
top of the memory map, the "low unduplicated call store," (LUCS), which is
located in the middle of call store, and the "high unduplicated call store,"
(HUCS).  The LUCS area starts at K-code 17 and goes down as it fills up (being
very watchful about not going into the DCS area.  The HUCS area starts at
K-code 37 and goes down as it fills up to K-code 20, being mindful not to step
on LUCS's toes.  Translators are classified as being either HUCS or LUCS
translators, (but not both).

LUCS translators aren't fixed; they can exist anywhere in the area as long as
they're identified by the MHT.  HUCS translators can either be fixed or not
fixed.  Note that in generics 1AE6 and earlier, there is no such distinction,
because there's not enough memory to make such a distinction feasible.  As for
the location of the MHT, in generic 1AE6 and earlier, it's located in K-code 17
at octal address 3724000, and is 1376 bytes long.  The later MHT's were moved
to K-code 37 at octal address 7720000, and is 3424 bytes long.

Translator Types
%%%%%%%%%%%%%%%%
As I said, translators take data as input and change it into another form for
output.  All translators exist in the form of hierarchical lists and tables.
They reside in call store on 1A's and program store on 1's.  The higher data in
a translator points to the location of the lower data.  The lower data contains
the actual information.  The different translators are located by the Master
Head Table, which contains pointers to all the translators in the system.  The
kind of data that needs to be translated is changeable data.

For example:

o  line equipment number
o  directory number
o  3/6 digit codes
o  trunk network number to trunk group number
o  trunk network number to peripheral equipment number

Now, there are two types of translators:  Multilevel and expansion.  The
multilevel translators contain a maximum of six levels of information in the
form of linked hierarchical tables:

1- Head Table
2- Subtranslator
3- Primary translator word
4- Auxiliary block or expansion table
5- List
6- Subauxiliary block

(1) Head Table:  The HT is the "directory" for the translator.  It contains
    addresses or pointers to each subtranslator.

(2) Subtranslator:  The ST's are the main subdivisions, so as an office grows
    larger, or as more features are added, the number of ST's grows larger.
    For example, there is a translator for every 1,000 directory numbers, so if
    an office grows from 3,000 to 8,000 lines, an extra 5 subtranslators must
    be added.  Input for translation must contain 2 things:  A selector and an
    index.  The selector contains the information as to which subtranslator to
    use (in the case of DCF, the selector would either be an A, B, C, or D).
    The index shows which item or word in that particular subtranslator to
    access.  In the DCF example, if the selector were "D", the index could be
    1, 2, 3, etc.

(3) Primary Translation Word (PTW):  Each index points to a PTW, which is a
    byte of information.  Often, all you need is 1 byte of information
    (remember that each byte is 23 bits!).  If the data isn't stored in the
    PTW, an address will be there to point to an auxiliary block or expansion
    table, where the data will be found.  The ESS can recognize whether the
    byte contains data or an address by:

    1 ESS)   The 3 most significant bits will be 0.
    1A ESS)  The 4 most significant bits will be 0.

    So, if all the 3 (or 4 for 1A) most significant bits contain 0's, the word
    will be interpreted as an address. (Anyone want to throw the ESS switch
    into an endless loop????)
(4) Auxiliary Block:  The first byte in the AB contains the length of the
    block.  This byte is called the word number (WRDN), and is used by the ESS
    so it knows where the auxiliary block ends. Remember that when the ESS
    reads data, all it sees is:

    110001011000101010100100101110010010101000101010100100101111

    So, in order to stop at the end of the block, the WRDN number must be
    present.

(5) List:  The list is used when additional information other than the standard
    found in the auxiliary block is needed.  The list, like the ST, has an
    associated index.  The address of the list is found in the AB and the index
    shows which item of data in the list should be looked at.  A good example
    of what kind of information is found in the list would be a speed calling
    list.

(6) Subauxiliary Block:  The list is only large enough to hold a 7 digit phone
    number, and if more information has to be stored (like a 10 digit phone
    number or a trunk identity), an address is stored in the list that points
    to an SB, which acts very much like an AB.

Expansion Translator
%%%%%%%%%%%%%%%%%%%%
The expansion translator has one table (called an expansion table).  This type
of translator gets only an index as input, since this type of translator is
only a bunch of words.  It could have auxiliary blocks, if the space allocated
to a word is too small.

RECENT CHANGE AREA OF CALL STORE (1 ESS)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The recent change area consists of:

+ primary recent change area
+ auxiliary recent change area
+ customer originated recent change (CORC)

The starting and ending addresses for these rc areas are stored in the MHT.
The primary recent change area is used to store changes affecting primary
translation words.  Each change is stored in a primary RC register, which
consists of two 23 bit bytes.  These two bytes contain status bits, primary
translation address in the program store, and the primary translation word
(PTW) address in call store.  The first byte in the register is the "address
word" (AW) and the second is the new primary translation word.  When looking
through the AW, bits 22 and 21 can tell you what kind of recent change is being
implemented:

11: temporary (not to be put into PS)
10: permanent (to be put into PS)
01: delayed (not active yet)
00: deleted (this space is available)

The PTW (abbreviations make things SO much easier) contains the translation
data or the address of the auxiliary RC (TAG).  You can tell whether the data
is an RC or an address by looking at bits 22 to 18.  If they are 0, then this
byte contains an address, which is stored in bits 17 to 0.