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_POTS