Starting from a basically empty configuration after the last post, it was time to start putting configuration back into the switch from scratch.
As a starting point, I picked a straightforward goal: get some single-party phone lines assigned to the switch.
This doesn't sound like much, but it's worth remembering that all of the translations on the switch are totally gone, as well as all of the hardware tables. The switch doesn't even have a bearer network configured (like ENET) let alone the line cards you would actually assign a line to.
I went about this process very mechanically. I'd try to create a new single party flat rate line (1FR) in SERVORD, see what I got stuck on, and then go fix it.
Inside SERVORD, I used the 'NEW' command, used the default entry for SONUMBER ('NOW'), and then SERVORD asked me for a DN. At this point, we're already stuck as the switch doesn't have any DNs assigned.
DN ranges are defined in table TOFCNAME where we assign an NPA-NXX to the switch. However, before we can do that, we need an NPA assigned to the switch, which is done in SNPANAME.
KEY
-------
222SNPA means Serving Numbering Plan Area, and refers to NPAs (in the north american numbering plan or NANP) which our switch is equipped to 'serve'. There are obviously many other NPAs in the NANP, but if our switch doesn't service numbers within them, then they are not SNPAs.
In actuality, the DMS had previously given a message to the effect that I should not create an empty SNPANAME table (which is also tied in with HNPACONT, that I'll get to later) so all I did was change the old 205 SNPA to 222 for my own uses.
With the SNPA configured, we can create an office code in TOFCNAME now:
AREACODE OFCCODE OPTIONS
-----------------------------------------------------------------------
222 563 $The entry here is pretty straightforward. I made a 3 digit office code (563) within the 3 digit area code I created (222). I didn't use any special options for this office code, but this is where you could specify options relating to local number portability (LNP).
From here, we can give SERVORD another try. Now we can get a bit farther, with SERVORD accepting a DN in our newly assigned office code and even accepting a line class code (1FR) even though that isn't yet defined. The next field we get stuck on is LEN_OR_LTID since we don't have any line cards yet.
Here, we start walking a dependency tree.
Technically, things go a bit deeper, as an ENET is attached to the message switch, which attaches to the XA-core, but I didn't touch the relevant parts of the message switch and XA-core hardware tables when I was clearing tables.
In any case, we'll be starting in ENINV, adding the tuple back for shelf 0 (which really covers two shelves, one for each plane).
ENKEY ENCLASS FRTYPE FRNO FRPEC SHPEC MSCARD0 MSLINK0 MSPORT0 FLOOR0
ROW0 FRPOS0 SHELF0 LOAD0 MSCARD1 MSLINK1 MSPORT1
FLOOR1 ROW1 FRPOS1 SHELF1 LOAD1
---------------------------------------------------------------------------
0 PRI64K MCNI 0 NTYA05AA NT9X0818 6 0 0 1
A 2 39 ENC22BN 8 0 0
1 A 2 13 ENC22BNThe fields are filled as follows:
The creation of the ENET in ENINV automatically creates some tuples in ENCDINV relating to the normal common packs. However, we will need to add the crosspoint cards manually.
Before we do that, though, we have to turn on the ENET, and then put it in service. We do that in mapci by first putting each shelf into the manual busy state, loading the software, and finally returning them to service.
MAPCI NODISP;MTC;NET;SYSTEM
BSY 0 ALL
BSY 1 ALL
LOADEN 0 ALL
LOADEN 1 ALL
RTS 0 ALL
RTS 1 ALL
QUIT ALLThe first command enters the appropriate mapci level to administer the ENET. The second and third put planes 0 and 1 into the busy state (they will be in the offline state initially). The fourth and fifth loads the software into planes 0 and 1. The sixth and seventh return both planes to service. The eighth command quits back to the top CI level.
We'll also fill the BEARNETS table, which should also have a definition for ENET. I'm not totally clear if this is needed on a switch with only one bearer network, but we'll fill it anyway.
NETIDX BNETNAME DISPLAY FABRIC
OPTIONS
------------------------------------------------------
NET 0 TDM_ENET ENET ENET
$I mostly just based this off the old entry:
Finally, we'll move on to the ENCDINV table. Realistically there's not much reason I need more capacity than a single crosspoint card (which can support up to 2048 channels), but the DMS enforces a strict set of configurations with the most minimal being 4 cards. This has to do with the internal arrangement of the ENET plane relating to termination of internal busses. It's possible I could have a working configuration with 2 of the 4 cards disabled and removed since this would still leave me one card for interfacing peripherals and another for interfacing to the message switches, but I have not tried this.
The first card in the table is in slot 9, used to interface to the message switch, and it has no paddleboard. The next card is in slot 10, and this is the one I will use for interfacing the peripherals equipping it with a paddleboard that has 16 DS-30s and 3 DS-512s. The last two cards are in slot 31 and 32, required to meet the minimal configuration that the DMS requires, but not used here for any actual interfacing thus no paddleboards equipped.
ENCDKEY CPTYPE CPPEC CPDCD PBTYPE PBPEC
PBDCD
------------------------------------------------------------------------
0 0 9 CROSSPOINT NT9X35CA 15 NIL_PB NIL_PEC
0
0 0 10 CROSSPOINT NT9X35CA 15 DS_30_DS_512_INTERFACE NT9X45BA
4
0 0 31 CROSSPOINT NT9X35CA 15 NIL_PB NIL_PEC
0
0 0 32 CROSSPOINT NT9X35CA 15 NIL_PB NIL_PEC
0After physically installing the cards, we can follow a similar process to bring them into service as we did for the ENET shelf.
MAPCI NODISP;MTC;NET;SHELF 0
CARD 9;BSY 0;BSY 1
CARD 10;BSY 0;BSY 1
CARD 31;BSY 0;BSY 1
CARD 32;BSY 0;BSY 1
CARD 9;RTS 0;RTS 1
CARD 10;RTS 0;RTS 1
CARD 31;RTS 0;RTS 1
CARD 32;RTS 0;RTS 1
QUIT ALLHere, we're navigating to the correct level to perform maintenance on shelf 0 of the ENET planes. Then we put all cards in both planes 0 and 1 in the manual busy state (taking them out of the offline state). Afterward, we return all cards in both planes to service. Lastly, we quit back out to the top level CI.
With ENET configured, the LTC was next. However, we take a detour here first.
The parts I had from my switch were arranged as a DTCI and an LGC. Up until now, I had been using the LGC to get lines. However, between the DTCI, which does T1 trunks with ISDN capability, and the LGC, which hosts LCMs, I should have the right parts to build a single LTCI which does both.
I made a list of the cards I had between the two and consulted the manuals. I then came up with a list of cards I could use to convert the LGC into an LTCI.
With the cards selected, I could fill all of the info in LTCINV:
LTCNAME
ADNUM FRTYPE FRNO SHPOS FLOOR ROW FRPOS EQPEC LOAD
EXECTAB
CSLNKTAB
OPTCARD
TONESET PROCPEC
EXTLINKS
E2LOAD
OPTATTR
PEC6X40 EXTINFO
----------------------------------------------------------------------------
LTC 0
1 LTEI 0 18 1 B 3 6X02NA QLI22AO
( POTS POTSEX)$
(0 10 16 0) (0 10 16 1) (0 10 16 2) (0 10 16 3) (0 10 16 4) (0 10 16 5)
(0 10 16 6) (0 10 16 7) (0 10 16 8) (0 10 16 9) (0 10 16 10) (0 10 16 11)
(0 10 16 12) (0 10 16 13) (0 10 16 14) (0 10 16 15) $
(UTR15 ) (MSG6X69 ) (CMR13 CMRU23A) (ISP 16) $
NORTHAA SX05AA $ SX05AA $
0
SXFWAL01
$
6X40FA N There's a lot of information here, and it all needs to be entered very carefully following the data schema manual.
As usual, we need to put the newly created LTC into service. This involves first placing the DS-512 link in the manual busy state and then placing it in service. Then placing the LTC in the manual busy state, loading the software, and placing it in service.
MAPCI NODISP;MTC;NET;SHELF 0;CARD 10
BSY 0 LINK 16;BSY 1 LINK 16
RTS 0 LINK 16;RTS 1 LINK 16
PM;POST LTC 0
BSY PM
LOADPM PM
RTS PM
QUIT ALLThe first command enters the relevant section of MAPCI for administering the ENET card where the links reside. Then we move both planes of the link to the manual busy state, then return them to service with the next two commands. The next command enters the relevant section to administer the LTC. Here, we move the LTC to the manual busy state, then load its software, and finally return it to service with the next 3 commands. The last command quits back to the top level CI.
Note that loading the LTC software can take a while as the image is somewhat large and the message link that it boots over is only a 64kb link (not to mention protocol overhead). The NTSX05 takes about 45 minutes to load QLI22AO.
When we created the LTC, a tuple was automatically created in LTCPSINV for the P-side links of the new LTC. Each P-side link needs to be defined as either being used for DS30A (for connecting an LCM, for example) or T1 or PRA. The link numbers for the DS30As and DS1 interfaces can be referenced in the DMS-100 Family Quick Reference Guide.
It's worth noting that the DMS will force you to allocate the first two DS30A links for an LCM on different NT6X48 cards for redundancy, as these first two links provide the message links for the LCM.
LTCNAME
PSLNKTAB
----------------------------------------------------------------------------
LTC 0
N (0 NILTYPE ) (1 NILTYPE ) (2 NILTYPE ) (3 NILTYPE ) (4 NILTYPE )
(5 NILTYPE ) (6 NILTYPE ) (7 NILTYPE ) (8 NILTYPE ) (9 NILTYPE )
(10 NILTYPE ) (11 NILTYPE ) (12 NILTYPE ) (13 NILTYPE )
(14 NILTYPE ) (15 NILTYPE ) (16 NILTYPE ) (17 DS30A )
(18 NILTYPE ) (19 DS30A ) $Here, I've configured links 17 and 19 for DS30A usage, as this is where I plan to attach my first LCM.
That LCM is configured in LCMINV:
LCMNM FRTYPE SHPOS FLOOR ROW FRPOS EQPEC LOAD CSPMNO
BICTST ADNUM MEMSIZE
LCMTYPE
----------------------------------------------------------------------------
HOST 00 1 LCE 38 1 B 2 6X04AA XLCM18AW LTC 0
N 2 256K 256K
LCM Y C HLCM (17) (19)$As usual, we'll have to put the new LCM into service:
MAPCI NODISP;MTC;PM;POST LCM 0 1
BSY PM
LOADPM PM
RTS PM
QUIT ALLThe first command brings us to the correct place in mapci to administer the LCM. The second puts the LCM into the manual busy state so we can load the software. The next loads the software into the LCM which thankfully doesn't take nearly as long as the LTC. Next, we return the LCM to service. Finally, we quit back to the top level CI.
Creating our new LCM also creates an associated tuple in LCMDRINV. However, the default tuple contains no line drawers, so we need to add some.
LCMNM
DRWRTAB
----------------------------------------------------------------------------
HOST 00 1
(0 NT6X54AA NT6X05AA ) (1 NILDRWR ) (2 NILDRWR ) (3 NILDRWR ) (4 NILDRWR )
(5 NILDRWR ) (6 NILDRWR ) (7 NILDRWR ) (8 NILDRWR ) (9 NILDRWR ) $I edited the tuple to change line drawer 0 to be an NT6X05AA line drawer with a NT6X54AA bus interface card (BIC). The new line drawer can be put in service, though I don't remember if it was needed:
MAPCI NODISP;MTC;PM;POST LCM 0 1
BSY DRWR 0
RTS DRWR 0
QUIT ALLThe first command enters the section of mapci where LCMs are administered. The next command puts the drawer in the manual busy state and the one after puts it in service. The last command exits back out to the top level CI.
Finally, we can provision some actual line cards in LNINV. Card 0 in line drawer 0 of an LCM is reserved for some kind of test purposes, and must be provisioned as an NT6X17. I'm also provisioning a couple additional line cards so that I have some to provision actual service on.
LEN CARDCODE PADGRP STATUS GND BNV MNO CARDINFO
-----------------------------------------------------------------------
HOST 00 1 00 00 6X17AC STDLN HASU N NL N NIL
HOST 00 1 00 01 6X17AC STDLN HASU N NL N NIL
HOST 00 1 00 02 6X17AC STDLN HASU N NL N NIL Trying to create a line in SERVORD again, we get a bit farther this time before it gives us an error about not finding a line attribute index. Line attributes are defined in LINEATTR, which is still empty.
We're going to have to walk a few dependencies here again. LINEATTR points into RATEAREA and XLAPLAN, which additionally points into HNPACONT.
We'll start with HNPACONT. Since I didn't delete the one entry, we have that entry to start with which was renumbered when we adjusted SNPANAME.
STS SNPA NORTREFS NOAMBIGC RTEREF HNPACODE ATTRIB RTEMAP
OPTIONS
----------------------------------------------------------------------------
222 Y 99 20 ( 0) ( 0) ( 0) ( 0)
$Number translations are a complex system on the DMS, and I don't want to go into too much detail here. However, there are some points I want to call out.
An STS can be separate from an SNPA and vice versa. The simple way to look at it is that an SNPA is an area code where numbers reside while an STS determines how numbers are translated for those calls. In simple setups, often the STS is the same as an SNPA, and the STS in that case defines the translations needed for numbers in that SNPA. In more complex cases, such as switches that serve multiple area codes like splits or overlays, it can be useful to define otherwise identical translations separately from the SNPA so that multiple SNPAs may use the same STS.
For now, we will keep it as the same as my one and only SNPA, 222. I'm not going to get any further into defining the translations for that STS just yet. This minimal definition of the STS is enough to move on to the XLAPLAN.
XLAPLAN allows us to decouple certain aspects of translations from the line attributes so that they can be reused through multiple different line attributes if necessary. XLAPLAN controls translations and class of service screening mostly.
XLAPIDX SCRNCL HSTS PRTNM ZEROMPOS RESINF
OPTIONS ADMININF
-------------------------------------------------------------------
222_POTS_0 NSCR 222 NPRT NONE N
$ 1FR_POTSThe last thing we need for a line attribute is a RATEAREA. This controls deciding whether calls are local or long distance, as well as functions relating to message rate service and LATA.
RTAIDX LCANAME MRSA LATANM ADMININF
----------------------------------------------------------------------
NLCA_NILLA_0 NLCA NIL NILLATA $The entry I created is basically a null entry without any call rating information.
Finally, we have enough to create a line attribute.
LNATTIDX LCC CHGCLSS COST LTG TRAFSNO SFC MDI
IXNAME DGCLNAME FANIDIGS DFLTXLP DFLTRA
OPTIONS
----------------------------------------------------------------------------
0 1FR NONE NT 0 0 NILSFC 0
NIL NIL 00 222_POTS_0 NLCA_NILLA_0
$With that out of the way, we can finally create a couple lines in SERVORD. I created a couple 1FRs, 563-1000 and 563-1001, on HOST 00 1 00 01 and HOST 00 1 00 02. I used the DGT option to make sure they supported DTMF dialing.
I think SERVORD puts the line cards into service automatically, assuming the LCM and the line drawer are in service, but if not, they can be administered from MAPCI;MTC;LTP;POST D x where x is the DN. From there, they can be set to manual bsy and then returned to service.
With the lines provisioned, dialtone should be avaialable on the both of them. However, we don't have any real translations and routing in place, so nothing you call will work.
We can have a look at a TRAVER to see what tables the switch will refer to for routing:
> traver l 5631000 5631001 t
TABLE LINEATTR
0 1FR NONE NT 0 0 NILSFC 0 NIL NIL 00 222_POTS_0 NLCA_NILLA_0 $
LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE
TABLE XLAPLAN
222_POTS_0 NSCR 222 NPRT NONE N $ 1FR_POTS
TABLE RATEAREA
NLCA_NILLA_0 NLCA NIL NILLATA $
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE LENFEAT
TUPLE NOT FOUND
TABLE OFCVAR
AIN_OFFICE_TRIGGRP NIL
AIN Orig Attempt TDP: no subscribed trigger.
TABLE HNPACONT
222 Y 99 10 ( 0) ( 0) ( 0) ( 0) 0 $
. SUBTABLE HNPACODE
. KEY NOT FOUND
. REAL VALUE IS: VCT VACT NThe DMS software is looking at our line attribute to determine the STS assigned to our line. It uses this to index into HNPACONT where it begins to look in the HNPACODE subtable based on the first 3 digits that we dial.
As this table is still empty, the call ends here with the vacant number treatment selected (which, as a side note, is not configured either).
We can add some simple intra-switch routing information to the 222 HNPACODE subtable for our office code, 563:
FROMDIGS TODIGS
CDRRTMT
------------------------------------------
563 563
DN 222 563Finally, we can route calls from one phone line to another. However, there is one quirk I noticed.
When dialing a 7 digit number, the SL-100 waits for interdigit timeout instead of completing the call immediately. This is odd, because the translations should definitely know by then that the call unambiguously routes a certain way, and 7 digit dialing isn't an uncommon thing that the DMS shouldn't handle.
At the time, I didn't solve this but as I was writing this blog post, I started thinking about it again and decided to investigate. With treatments in place, I had better ability to see how things were reacting since I could just digit timeout based on when I got an announcement or reorder.
The way the DMS works, the line controller peripheral (LTC in this case) handles collection of digits using a simple rule set to determine when enough digits have been collected to report them back to the core for checking against translations. Normally, this should be 7 digits in most cases for a north american switch (and 3 digits in some other common cases). This is implemented so that the core doesn't have to handle every single digit dialed event just to turn back around and say more digits are needed thus saving realtime capacity on the core and offloading that task to the peripheral equipment.
Anyway, I was able to determine that my SL-100 was reporting digits after dialing just 5 of them. If I dialed a vacant code, I could dial just 5 digits and immediately get an announcement.
If I dialed my working code, 563, I could dial 8 digits before I got an immediate response without waiting for digit timeout. If I dialed just 7, I had to press # to end dialing or else wait for digit timeout.
I also noticed some odd behavior if I dialed 8 digits. On a hunch, I dialed 563-11007 and got connected to 563-1007. This was consistent regardless of what digit preceded 1007.
At this point, it was very clear something was wrong. This was definitely not the way the switch should be acting. Something somewhere was configured in a way that was preventing digit collection from working the way I would expect.
After exhausting most of the normal tables as possible contributors to the issue, I turned to the office parameter tables e.g. OFCENG and friends.
In OFCENG, I spotted a parameter called NUMBER_OF_DIGITS_PER_DN. Reviewing the manual, it sounded like this parameter was likely to be what determined how many digits would be collected from the line before reporting them to the core. My switch was set to 5 instead of the normal default value of 7.
PARMNAME PARMVAL
----------------------------------------------------------------------------
NUMBER_OF_DIGITS_PER_DN 5I think I had my smoking gun. I don't know why it was set to 5, but I suspect somebody did that because the University where my switch came from was using 5 digit extensions. However, at least on a modern software load, this parameter has nothing to do with IBN line digit collection and IBN lines are all that the university was using. All I can think is that either this was wrong from day 1 or got set wrong at some other date and nobody realized it because it had no effect on IBN lines. The other option is that the switch, which was installed as a DMS-100/200 in roughly 1984, worked very differently than it does today with modern software, and this was actually a necessary change that was made back then to account for the university's dial plan.
In any case, I changed the parameter to 7 and then everything worked as expected after that.
PARMNAME PARMVAL
----------------------------------------------------------------------------
NUMBER_OF_DIGITS_PER_DN 7There is a slightly special process to changing OFCENG parameters. Firstly, some parameters don't take effect until a restart, and for that you need to consult the office parameters manual to see if that's the case. Luckily the parameter I was changing didn't need a core restart, though it did require that static data be reloaded into line peripherals. It wasn't clear if that meant just the LTC or also the LCM, so I made sure both reloaded their static data.
To even change the parameter in the table, there's a special command to unlock write access: 'RWOK ON'. On some switches, this is a command that needs to be unlocked in TOOLSUP. Nortel didn't give access to that command to just anybody because changing office parameters has the potential to break the switch in ways that can be difficult to fix. I think they wanted you to be properly trained before giving you access, or be on the line with technical assistance where they'd walk you through it. In any case, my switch has the RWOK command enabled without locking, so I didn't need to deal with that.