The New LEC Order - Acronym City ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by New Hack City A general forward movement of telecommunications companies to ready themselves for ISDN has been revolutionizing the LEC's + IEC's. Focusing on the changes to the traditional, already-existing telecommunications network, it is clear that switches are more ready to not only carry more traffic, but ready to support more than the traditional analog voice/one channel per "circuit" (by circuit I mean not only LEC interoffice message trunks and special services circuits, but customer loop plant "lines" as well) service, becoming software-driven structures that not only support multi-channel digital data communications and high traffic, but that allow better administration of themselves by the LEC. And not only switches have changed - interoffice circuits have metamorphised from analog, single channel, public message trunks using MF signalling on a copper wire into digital, multi-channel (using FDM and TDM), private/public carriers using CCS6 (CCIS) signaling on a fiber optic cable, radio wave, microwave, or even a satellite. Even loop plant customer lines are being multiplexed, such as the DOV ISDN line. It's obvious that LEC's cannot continue to use the same facilities to provision, operate, and keep records on these new switches, "circuits" (lines, public message trunks, and special service circuits) and other telecommunications equipment (plug-in, DACS, etc.). Many OSS's cannot handle this new technology, and only through intensive manpower can provisioning, operating, and record-keeping of these new technological services be done. Complicated "RC service orders" are often unprocessable by both MIZAR and COSMOS, forcing RCMAC personnel t not only translate the RC service order for the specific switch (and switch version), but to enter the manually translated RC service orders into the specific switch...manually LFACS is another bogged down system with difficult-to-process service orders for digital loop carrier systems, forcing LAC to completethe order. Not only is the excessive manpower being used, but customer orders for service are often backlogged, making them wait for months for the service to be implemented. Which is where BELLCORE comes in. BELLCORE, among other things, mechanizes, restructures, and "updates" the LEC system ("Update" has two meanings - updating the network at large by adding new systems - which is done at the core of the BELLCORE engineering/planning brain, or updating an OSS to include knowledge of the latest batch of newly invented circuits - which is more of a details king of thing that BELLCORE does). Just knowing one OSS, say TIRKS, one can see all three of these BELLCORE functions in action; TIRKS is obviously updated on the new kinds of circuits, for it not only keeps track of all circuits on its "database" but it is a tool for designing new circuits as well; TIRKS's CIMAP module has SCC/CO communications mechanized as TIRKS has automated communications with PICS recently as well; and restructureing can be seen in TIRKS resturcturing from one large OSS with one database, into three separate modules: engineering and planning, provisioning, and operations (the CIMAP module), each having its own database. Actually, the entire LEC system is becoming divided into these three parts (engineering and planning, provisioning, and operations). BELLCORE has had a pet project that has been gnawing at it since its inception: integrating FACS and TIRKS. As special services circuits proliferate (they now account for half of all interoffice circuits), interoffice circuit become less things added when traffic between two switches grows, and more things that are provisioned from service orders - almost like a line...in this situation integrating FACS and TIRKS begins to make sense. Another reason for the integration is that TIRKS increasingly needs information from FACS (information about the loop makeup so that TIRKS can design special services circuits), and this information is all sent to TIRKS...manually. So besides circuit provisioning requests coming more and more from customer service orders instead of suggestions by traffic analyzing bureaus, more coordination is need between the loop plant, switch, and circuit provisioners to provision special services effectively, since all three are involved in the special services circuit provisioning process. The main BELLCORE plan in its updating, mechanizing, and restructuring of the overall network, the very core of BELLCORE's technological division's master plan for LEC's is the resubdivision of the LEC system. The LEC system is currently basically sub-divided into the different parts of the telecommunications network lines (LMOS, MLT, CRAS, CRSAB), MDF (COSMOS), switch (MIZAR, SCCS, ODD), plug-in equipment (PICS), and interoffice circuits (SSC, NTEC, and SARTS for special service circuits; CAROT and CTTU for public message trunks; and TIRKS for both types of interoffice circuit). The BELLCORE resubdivision of the LEC system will make all offices/bureaus/centers and OSS's fall under three systems: OPS, EPS, and IPS. OPS stands for Operations Process System. OPS is responsible for installing, testing, monitoring, maintaining, and "fixing" services/service equipment i the telecommunications network. OSS's such as SARTS, LMOS, and CAROT will be under the umbrella of OPS. EPS (Engineering and Planning System) designs and engineers the LEC telecommunications network by integrating distribution planning systems, inter-office planning systems, and switching planning systems. IPS stands for Integrated Provisioning System. IPS is what the FACS/TIRKS integration would come about under. IPS's responsibility is to assign equipment and facilities to provide a service. Some systems that will fall under IPS's umbrella are SOAC, LFACS, MIZAR, parts of TIRSK, and a new OSS that I will describe below. One should remember, however, that the idea that the Integrated Provisioning, Engineering and Planning, and Operations Process systems are self-enclosed is a fallacy. The EPS, OPS, and IPS will interrelate with each other, just as TIRKS interrelated with SOAC, or CRSAB interrelated with SSC on occasion. The "new order" is fairly obvious; customer requests for service are handled by IPS. Operation of the services is run by OPS. The examinations of the service, planning of new service to offer customers, and the enginereering of these new services is handled by EPS. The LEC's new subdivision into IPS, OPS, and EPS is going to have a huge effect on LEC operations as we know them today. It is happening because of the move towards ISDN, because of CCIS, multiplexing, and intelligent, SPC electronic switches. But really, the key figure in this change has been the special services circuit. The special services circuit is really what has revolutionized the LEC telecommunications network because the line and interoffice trunk came together to form one "circuit". This redefining of what a circuit is has enormouse implications on the future of telecommunications. SWITCH SWITCH is a new service provisioning OSS created by BELLCORE to help accomplish the aim of IPS, to allow flow-through processing of orders by automatically assigning LEC equipment and facilities for a service. SWITCH will keep track of and assign equipment on the line and trunk side of a wirecenter. SWITCH will also help the provisioning process in other areas as well. Because of the enormity of what SWITCH will do, integrating wirecenter facility provisioning on the line and trunk side of the switching network, SWITCH development is cut into two "phases" Version 1 of SWITCH (Version 1 meaning all subversion of Version 1 collectively - Version 1.0, 1.5, 1.7, 1.84758 etc.) will only keep track of assigned facilities on the line side of the wirecenter. Let us take a look at the "history" of SWITCH, starting with the conception of SWITCH in its development up to the second version. As stated in the previous section BELLCORE has had the idea of the IPS/OPS/EPS system, which integrated the provisioning, operations, engineering, and planning of the LEC system for both the line and trunk side of the network. In late 1987, BELLCORE did a detailed study of the LEC system, especially in the area of wirecenter provisioning of new technologies and services. From this study, the suggestion of a system that provisioned for both sides of the wirecenter, which would, through integration, help meet the growing demand for these enw technologies, came about. After two years of development of the system that would be called SWITCH (so named because it was an extension of the trunk and line side of the wirecenter, thus an extension of the "switch"), the design of Version 1.0 was completed (Perhaps needless to say, BELLCORE's original schedule of when the version would be out was a bit overenthusiastic time schedule wise). Version 1 of SWITCH provisions exclusively for the line side of the wirecenter. Of course, everyone is aware of the OSS that currently provides for the line side of the wirecenter COSMOS. In Version 1.0, SWITCH will have the ability to take over half of COSMOS capabilities (but Version 1.0 is just a test version - SWITCH Version 1.7 is the first "real" one - so that doesn't matter). Most of the ability to help in Version 1.0 would be in the field of provisioning the ISDN lines and packet switches. COSMOS is not able to allow flow-through provisioning of many of these new technologies. SWITCH is able to allow flow- through provisioning of ISDN's and packet switches for digital (and analog) switches because of its sophisticated data model of services and circuits. Obviously, SWITCH would be better able than COSMOS to generate switch-specific messages (RC messages) from service orders when MIZAR requests in the field of ISDN. FOMS, Frame Operations Management System is the sub-system of SWITCH that will deal with the management of work on the MDF. FOMS is to SWITCH as CIMAP is to TIRKS, i.e., FOMS is almost a separate OSS. The FOMS sub-system of SWITCH was created along with SWITCH and is not a leftover piece from COSMOS. FOMS will deal with the connection and seperation of cable pairs from OE. How would SWITCH work in the line provisioning process? A customer would phone in his request for a new line to the business office, giving any details needed (standard line or ISDN 1, call waiting - yes/no? etc.). Throughout whatever system the Business Office would have, the service order would eventually reach the SOP (SOP was the system which service orders entered FACS with). SOP would forward the service orders to SOAC. SOAC would send LFACS (LFACS is the provisioner for the outside loop plant) and SWITCH the order. LFACS provides for the outside plant part of the service order, i.e., station protector to cable vault... still the MDF an switch elements must be provided for. SWITCH gives the order to its FOMS subsystem for framework via SOAC. FOMS will attach the lines CP to OE. SWITCH also sends the service order to MIZAR via SOAC. MIZAR enters the service order into the switch as a RC message. This is how a line provision was done before, the only difference with SWITCH Version 1 being that FOMS replaces COSMOS. Why are SWITCH's connections to MIZAR and even FOMS (its own subsystem) done via SOAC? Because SWITCH has more "control" over the provisioning process. The control comes about when an order is changed while it is pending. In this situation, SWITCH is much more flexible than COSMOS. If an order changes midway, SWITCH can simply rework the order as necessary. SWITCH is "in charge" or "responsible" for reworking this order, mostly due to its flexible time schedule "piles" for orders. Obviously, besides these order schedule "piles", SWITCH must also have detailed records of all the lineside equipment of the wirecenter to allow this flexibility in assigning and reassigning facilities. SWITCH Version 1.0 was "implemented" during December of 1989 in two CO's - one in Long Branch, New Jersey (Bell Atlantic) and the other in Cahaba Heights, Alabama (BellSouth). Implemented is in quotes because SWITCH Version 1.0 never connects with the actual switching network. SWITCH Version 1.0 is located in the wirecenter, and gets service order data, but never connects with SOAC. These are two stages of Version 1.0 "implementation". Stage one is Provisioning On-site Verification Testing (POVT). POVT sends pseudo-orders, created by BELLCORE, to SWITCH with the pre-calculated correct results. Stage 2 of Version 1.0 "implementation" is Netted Field Verification Testing (NFVT). NFVT sends real customer orders to SWITCH to see if SWITCH processes orders correctly. Though the orders are real, SWITCH is still not actually connecting with a switching system. SWITCH Version 1.5 will be the first time SWITCH is actually connected with real equipment. SWITCH Version 1.5 will contain whatever modifications that BELLCORE felt the need to make from the results of POV and NFV testing. Through SOAC, SWITCH Version 1.5 will connect with LFACS and MIZAR, and will become a part of the service provisioning system. The "soak" version will be implemented in the same two wirecenters that POV and NFV testing took place in. COSMOS will not be totally out of the picture yet because SWITCH will need a few more updates entered, a few more bug weeded out, etc. Version 1.5 is expected to be implemented in mid-1991. SWITCH Version 1.7 will contain major changes that came about during the Version 1.5 "soak". The most major changes will be that SWITCH Version 1.7 can deal without COSMOS totally, i.e., those who implement SWITCH will get rid of COSMOS. Version 1.7 of SWITCH will be made available for LEC use in late 1991 ("projected" date - pretty precarious). By late 1992 mega-SWITCH implementation/COSMOS annihilations is expected. The BOS's most interested in SWITCH, and most interested in implementing it, are Nynex, Pacific Bell, and BellSouth. Version 2 of SWITCH will not only provision for the line side of the network, it will provision for the trunk side as well. As SWITCH replaces COSMOS for line-side wirecenter provisioning, SWITCH replaces the current trunk-side wirecenter provisioner(s) TAS (Trunk Administration System) and GTAS (Generic TAS). TAS and GTAS were TIRKS modules that assigned trunks to the "trunk frame" (I use this phrase virtually) on the trunk side of the network, and trunk provisioning at the CO was dependent on TAS/GTAS. But now SWITCH will assign "trunk frame slots" in reponse to "orders" (that come from the network planning/trunk traffic division of the LEC), just as SWITCH assigned line frame slots in response to orders (that came from customers). The entrance of SWITCH into trunk provisioning is just part of an overall effort underway of revising trunk provisioning. There will be a TIRKS-SOAC-SWITCH connection. When TIRKS gets an "order" from the trunk traffic/planning bureau for a new trunk or carrier to be placed between offices, the first thing TIRKS does is communicate with SOAC, and through SOAC, SWITCH. SWITCH assigns a spare for the trunk on the "trunk frame" and them returns the completed assignment to TIRKS through SOAC. Then TIRKS sends the order to other OSS's office's to complete the trunk order fully. I should make it clear that this Version 2 connection between TIRKS and "FACS" is just a token one, and the TIRKS/"FACS" connection will expand greatly within later versions of SWITCH, as well as non-related to SWITCH ways. Since TIRKS is connected with trunk provisioning and FACS is concerned with line provisioning, this expanded interface will mean more of a connection between line and trunk provisioning i the future. SWITCH version 2 will undergo testing just like version 1. The testing will take place in the 2 sites Version 1 testing took place in. Testing will revolve around the same lines: "parallel" testing with test data, "parallel" testing with real data, initial real usage of the system, system after modification made from watching previous testing (and ready for initial distribution). And since BELLCORE's time estimation of when Version 1 would be out was so off, they're not making any promises as of when Version 2 will be distributed. That's an explanation of the two versions of SWITCH. As I said, Version 1.5 is the first time SWITCH will actually be provisioning for orders and will actually be hooked up to SOAC i.e., the first time it will not be in test mode but in working mode. Implementation of SWITCH Version 1.5 should coincide with the distribution of this issue of 2600 by several weeks. The Business Office will use SWITCH as a database for telephone numbers and the service each telephone number has (RCF, Speed Calling, etc). This information will be provided through the Business Office SWITCH software contract. Other centers (and OSS's) that are connected with provisioning customer service will have their own separate software contracts with SWITCH for information receiving. "Contracts" are fundamentally to make SWITCH an OSCA system (after all this ASCA OSS planning we finally have one), but more theoretically contracts point out the second side of "provisioning". Of course, assignment has been the only part of SWITCH's provisioning process so far, assignment of line and trunk frame "slots". However, another big part of provisioning is inventory, or simply keeping track of the assignments. Through those contracts, SWITCH fulfills its second provisioning duty. The only system SWITCH actually connects to (in Version 1 and 2) is SOAC. But through SOAC (and through TIRKS via SOAC), SWITCH connects to LFACS, MIZAR, TIRKS, CIMAP, and even CAROT. The idea of connecting all the provisioning systems (trunk and line side) is a conerstone of IPS. One of SWITCH's features that make it better than COSMOS and GTAS/TAS in that if an order cannot be completed by SWITCH, it is at least partially completed with information from SWITCH's database, to make life for the person who would manually complete a complex order for a new digital service order. Perhaps the coolest thing about SWITCH (to the LEC's, not the hacker) is its flexability pertaining to pending work. It's "no prob" to change an order midway through the provisioning process with SWITCH. An order change can range from a change in due date (push the installation from 9/18 to 9/30) to a change in facilities (make that two lines, not one). SWITCH just reworks the order and that's that, no mess, no fuss. And SWITCH reworks an order in the most cost-efficient way that it can. I suppose I should tell you that SWITCH will be running on IBM-compatible mainframe computers. Since SWITCH won't be hooked up to any OSS's or even any actual equipment until two months past this article's deadline (never mind a node on a Datakit VCS or a BOC PSN), this article is a "pre-view", not a "re-view". For that reason, we do not go into the base mechanics of SWITCH logon, commands, etc. However, SWITCH 1.5 will be implemented right as the time this issue comes out (in the Bell Atlantic and BellSouth offices previously mentioned), so you will be able to hack into SWITCH. It would be rather amusing to have a hacker on a OSS on the first day of the OSS is ever used. So in the end, what will SWITCH and IPS/EPS/OPS mean for hackers? Well, "routes" are a more popular thing nowadays. One who "controls" Telenet can access a BOC's private "NUA prefix" with ease, and thus through Telenet one has a route to an BOC's OSS. On the same token, SWITCH will provide routes for hackers. SWITCH can route to SOAC, MIZAR, LFACS, and TIRKS. So basically if a hacker controls SWITCH and the switch, he controls the whole damned CO from cable room to OGT. SWITCH Version 2 provisions message trunks at the CO. Nowadays trunks aren't important without 2600 Hz abilities, unless they are special service circuits. But with CCIS and ISDN signalling, when the switching network and the customer begin to route calls over trunks separate of the data/voice signal, perhaps the importance of trunks will increase. Of course, traditionally, the OPS systems hold the greatest esteem among hackers, for LMOS and SARTS can actually take control of lines and special services circuits respectfully. IPS would be good for the databases.. after all, IPS not only provisions as well. Perhaps in the future, knowledge of LEC trunks will grow in importance, if the way the Nodal systems we currently have changes as well (i.e., from NPA/NXX-XXXX to a more complicated system containing "can't get to" areas - hardwiring and special services circuits).