mirror of
https://github.com/fdiskyou/Zines.git
synced 2025-03-09 00:00:00 +01:00
382 lines
20 KiB
Text
382 lines
20 KiB
Text
==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.
|
|
|
|
_______________________________________________________________________________
|