|
|
Maximizing Carrier Profitability &
Efficiency
|
Communications
Carriers have constructed a vast network of equipment in order to sell
products and services to their customers. Be it Private Line, ATM, Frame
Relay or Long Distance, or other products/services, special communications
equipment produced by the likes of Nortel Networks, Lucent Technologies,
Cisco Systems, Ascend Communications, Fujitsu, and others is used as
the backbone for these services. However, when push comes to shove,
this network and related equipment has a single purpose - to supply
the necessary circuits to 'turn-up' the customer's order.
At BottomLine Data
Solutions (BDS) we rely on a tried and true '9 Step Equipment & Circuit
Reconciliation Process' to accurately and efficiently conduct all OSS
reconciliation activities. The reconciliation process begins by conducting
field equipment and circuit validation activities a
site at a time. Validation starts by completing an inventory
of the applicable network equipment at a given site (ex: DSX Panels,
Transport Equipment, Routers, Switches, Fiber Distribution Panels, etc.),
and is followed by gathering the physical and virtual cross-connect
data needed to support Circuit Reconciliation later. Field validation
is conducted using the MobileMap module of BDS' proprietary CircuitWise
software solution.
As Figure
1 below displays (at a high level), that there are four
phases related to reconciling all circuits (on-network and
off-network) associated with a Carrier's network. These phases are described
as follows:
Phase 1: Building Pairing:
BDS believes that
all equipment and circuit errors residing in the OSS should be 'cleaned-up'
a site at a time; while all circuits should be validated a segment at
a time. We refer to this as 'Building Pairing'. With Building Pairing,
circuit segments operating between a particular remote facility (Collocate,
Customer Prem, other) are validated and reconciled in relation to their
given Central Office (CO).
Phase 2: Sonet Rings: Beginning
in Phase 2, circuit segments begin to take the shape of Sonet rings.
Ultimately, all Sonet rings (and point-to-point) touching the audit
facility in question are validated. Also in Phase 2, circuit segments
associated with a particular Central Office facility and a multitude
of Points-of-Presence have been validated and reconciled.
Phase 3: MAN: All
inter-connected Sonet rings and point-to-point circuits operating within
a given Metropolitan Area Network (MAN) are validated. Also, Central
Offices have been audited for equipment and cross-connects that do not
relate to any outlying POP (largely attributed to incomplete disconnects).
Phase 4: Network: At
this point, reconciliation of the interconnected MAN cities is now complete.
Figure
1: High-Level BDS Circuit Reconciliation Approach
The
following Figure 2 displays a number
of circuit segments existing between a variety of network locations
within a single MAN city. In the example, there are two Sonet rings
(a 3 node and a 4 node), as well as two point-to-point segments. In
this example, a circuit is generated in the Central Office (labeled
below 'A Location') and is muxed/demuxed along a variety of circuit
segments ultimately terminating at the customer premises (labeled below
as the "Z Location"). For the customer's circuit to be accurately validated
all equipment and connections (physical and virtual) within the A to
Z path would require inventory.
Figure
2: Simple Circuit Path (A to Z)
Now taking the circuit inventory process inside the network facility,
in Figure 3 we will follow a particular
circuit from its origin, through the building, outside the building,
then into the customer facility. In the following site example we identify
nine (9) steps in the inventory process (note:
the actual process is much more detailed, but the following diagram
focuses on the core aspects). Here, a voice circuit originates
in Step 1 and rides over a hardwire cross-connect existing between the
switch (DMS, Lucent 5E, etc.) and a DSX panel. In Step 2, two DSX panels
are jumpered, with a hardwire cross-connect then occurring between DSX
2 and a DACS (ex: Tellabs Titan 5500) in Step 3. Step 4 is a virtual
connection, a 'software cross-connect', that will require electronic
data transfer from the DACS, with another hard-wire cross connect then
taking place in Step 5 to DSX 3. In Step 6, DSX 3 and DSX 4 are jumpered,
with DSX 4 then hard-wired to a piece of optical equipment in Step 7.
At this point, the circuit would then leave the building via a fiber
distribution panel and ride along a Sonet Cross-Connect (Step 8) ultimately
arriving at the customer location. At the customer premises, the circuit
would likely terminate to another fiber distribution panel, and then
be processed in the optical equipment - with the optical equipment and
a DSX Panel being hard-wired in Step 9. From there, the circuit would
be further cross-connected within the customer premises to the ultimate
recipient.
Figure
3: Following a customer circuit to the CPE
What
about off-net (off-network or leased) circuits? Frequently,
Carriers must hop on and off other Carrier networks in order to get
the circuit where it needs to go. This requires interconnection between
networks that also must be verified. The COGS (Type II Circuit) validation
and reconciliation process is the most challenging of all, but also
yields the greatest returns. The process is usually somewhat customized
for each client depending on a number of variables including network
configuration and how records are managed and maintained. Typically,
the process begins with identification of all Type II circuits residing
in the provisioning system (or systems). These circuits are then extracted
and stored in the CircuitWise database for validation and ultimately
reconciliation against off-net billing. Circuits are traced in the field
to the "meet me" point. However, often LEC partners do not like others
to touch their DSX panels. In many instances one may be limited to labeling.
Once the data is gathered, initial exception analysis occurs in WiseAnalyze
(CircuitWise reconciliation engine) and further manual research may
be required to "bless" exceptions as "errors". Research may be required
in customer agreements, notes, etc. Although the process can still be
somewhat manual, the COGS reconciliation process is significantly enhanced
(and expedited) via the aid of the BDS Solutions.
|
