This manual covers Ericsson and General Electric products manufactured and sold by Ericsson Inc.
NOTICE!
Repairs to this equipment should be made only by an authorized service technician or facility designated by the supplier.
Any repairs, alterations or substitution of recommended parts made by the user to this equipment not approved by the
manufacturer could void the user’s authority to operate the equipment in addition to the manufacturer’s warranty.
NOTICE!
The software contained in this device is copyrighted by Ericsson Inc. Unpublished rights are reserved under the copyright
laws of the United States.
This manual is published by Ericsson Inc., without any warranty. Improvements and changes to this manual necessitated by typographical errors,
inaccuracies of current information, or improvements to programs and/or equipment, may be made by Ericsson Inc., at any time and without notice. Such
changes will be incorporated into new editions of this manual. No part of this manual may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying and recording, for any purpose, without the express written permission of Ericsson Inc.
Copyright August 1994, Ericsson Mobile Communications Inc.
3.1.3. Hard Disk Interface.............................................................................................................................. 12
4.2.1. Distribution Media...............................................................................................................................21
4.2.1.1. User Configuration Files.............................................................................................................22
4.3. CAL TERMINAL SERVER CONFIGURATION...........................................................................................34
APPENDIX A EDACS BILLING (CDR) FORMAT...................................................................................................A-1
APPENDIX B PHYSICAL CONFIGURATION DETAILS.........................................................................................B-1
APPENDIX C FAULT TOLERANCE........................................................................................................................C-1
4
INTRODUCTIONLBI-38965
1. INTRODUCTION
This manual contains installation instructions, physical and functional descriptions, specifications, and usage
information for the Enhanced Digital Access Communications System (EDACS) Billing Correlation Unit and the
Centralized Activity Logger (BCU/CAL). A block diagram of the BCU/CAL is shown below.
The BCU/CAL works as a subsystem attached to an Ericsson Private Radio Systems (PRS) Integrated Multisite and
Console Controller (IMC) and can be set to operate as a BCU, a CAL, or both. Each IMC node must have its own
BCU/CAL.
BCU and CAL are two separate capabilities which can run independently of each other on the same machine, yet still
utilize resources and utilities common to both.
Additional information for BCU/CAL can be found in the following publication:
l
LBI-38967, EDACS Billing Correlation Unit/Centralized Activity Logger User Interface Manual
Ethernet
TCP/IP WAN
Customer
Billing
Computer
DAT (Optional)
RF
System
Console
Terminal
Emulex
Terminal
Servers
16 RS-23216 RS-232
DEC
Terminal
Servers
BCU
CAL
Downlink
High-Speed
HDLC Link
RS-422
MIM
C
Area
A
IMC
M
Emulex
Terminal
Servers
Terminal
Servers
DEC
MIM
RF
System
EDACS
Network
Manager
DECNet
LAN
System
Manager
The dotted lines enclose the CAL-specific interfaces of the BCU/CAL.
Figure 1 - BCU/CAL Architecture
5
LBI-38965INTRODUCTION
1.1. BCU FUNCTIONAL DESCRIPTION
The main function of the BCU is to generate call detail records (CDRs) to be transferred to a n external billing system
for invoice generation. To accomplish this, the BCU scans an input stream of activity messages supplied by the IMC,
archives these messages in their raw form, uses those messages which indicate channel assignment and channel drop events
to calculate air time, and then generates the CDR.
Call Types Supported
All EDACS call types except for the following are supported by the BCU:
1.Console calls.
2.Conventional site calls.
3.Local interconnect calls.
4.System all calls.
NOTE
Non-EDG data calls are only supported if radios are “wide-area enabled” on the site.
1.2. CAL FUNCTIONAL DESCRIPTION
EDACS system administrators require both site monitor and activity download capabilities. These functions are
normally supported by the System Manager in conjunction with the Site Controller at each Radio Frequency (RF) System.
The CAL provides this capability for EDACS not equipped with a Site Controller.
1.Site Monitor
Provides the system operator at a System Manager terminal with a real-time display of the calls in progress on the
RF channels at the selected trunked system.
2.Activity Download
Call activity and system status information are collected by the CAL and buffered in internal memory. Once an
operator-defined buffer content threshold is exceeded, the CAL initiates a download of buffer contents to the
System Manager. The downloaded information is used to prepare traffic reports on system usage.
In existing EDACS networks, the System Manager communicates with Site Controllers at RF systems using modems
and dial-up or leased line connections, routed through a DECServer terminal server. A communications session is set up
via a DECServer port between the System Manager and the Site Controller. The System Manager associates the
DECServer physical port number with the Site Controller's identity.
Since the IMC is already connected to all the sites, it has centrally available much of the data that individual Site
Controllers normally output to the System Managerfor all the sites. The CAL connects to the IMC and demultiplexes
incoming call activity information messagesthe same messages that the BCU uses for billinginto activity download
data and site monitor data to send to a System Manager using Site Controller protocol.
The CAL uses two Internet Protocol (IP) terminal servers on the local area network (LAN) to communicate with the
System Manager's DECServer(s). Up to 32 RS-232 asynchronous serial connections are available, 16 per terminal server.
One System Manager DECServer port and one IP terminal server port are required per EDACS system being monitored by
CAL.
6
INTRODUCTIONLBI-38965
Call Types Supported
All EDACS call types except for the following are supported by the CAL:
1.Console calls.
2.Conventional site calls.
3.Local interconnect calls.
4.System all calls.
NOTE
Non-EDG data calls are only supported if radios are “wide-area enabled” on the site.
7
LBI-38965PHYSICAL DESCRIPTION AND COMPATIBILITY
2. PHYSICAL DESCRIPTION AND COMPATIBILITY
This section outlines the specifications, depicts the physical architecture, and provides compatibility information for the
BCU/CAL.
Software for the BCU and the CAL are merged into one software package. Feature encryption allows or disallows BCU
or CAL functionality. The two products can also run on the same hardware platform with minor additions for CAL.
2.1. PHYSICAL SPECIFICATIONS
General Specifications
BCU/CAL:
ELMA VME System 12 7-slot enclosure with PSU and integral cooling fan
TVME 147 single-board computer with TVME 712/M Transition Module
Formation WANServer fv5310
Maxtor MXT-1240S 1.2 GB 3½" half-height 8.5ms hard disk drive, internal
Teac FD235HS-711 1.44 MB 3½" half-height floppy disk drive, internal
Tape Drive (Optional with BCU only):
Archive/Maynard 4324NP 4/8 GB 3½" half-height 4mm digital audio tape (DAT) drive, internal
Console Terminal:
DEC VT100 or compatible console terminal
Terminal Servers (CAL only)
Emulex Performance Series P2516-SLTL (16 ports per terminal server)
Power Supply
BCU/CAL:
115/230 VAC, 47-63 Hz, 500 W
Physical (EGE Standard Cabinet)
BCU/CAL:
6 rack units: 26.67 cm (10.5 in.) high x 48.26 cm (19 in.) wide x 49.99 cm (19.68 in.) deep
The BCU/CAL's internal architecture is shown in Figure 2. The individual components and their primary functions are
outlined below.
P2 Adapter BoardVMEbus Backplane
RS-232
Appl. SW
HDLC
From CAM
SCSI
Ethernet
LAN
Common
VME
Platform
Formation
WANServer
Communications
Module
Hard Disk
TVME712/M Transition
Floppy
Disk
Module
Tape Drive
Figure 2 - BCU/CAL Architecture
TVME147 CPU
Administrative Terminal
To System Manager
Terminal Servers (CAL Only)
9
LBI-38965PHYSICAL DESCRIPTION AND COMPATIBILITY
The BCU/CAL is based on a VMEbus computing platform with the following components:
CPU
Technico TVME 147 single-board computer based on a 68030 microprocessor
•Supports BCU/CAL application processing
•Interfaces to hard disk, floppy disk, and tape drive via an on-board small computer systems interface (SCSI)
with a connector on the transition module
•Interfaces to the console terminal via an RS-232 serial port with a connector on the transition module
•Network physical connection is 802.3 Ethernet, 10 BASE-15 (Thick Wire). A MAU may be used for
connection to a Thin Wire (coaxial) network
Internal Drives
Hard Disk: 3½" 1.2 GB
•Provides configuration parameter storage
•Provides call detail record (CDR) storage
•Provides raw activity record (RAR) buffering/storage
Floppy Disk: 3½" 1.44 MB
•Used for application program updates
Tape: 3½" 4/8 GB 4mm DAT
•Provides call detail record (CDR) file archival storage
•Provides general purpose file interchange with UNIX
•UNIX Tar format, 512-byte tape block size, no data compression
Communications Module
Formation WANServer fv5310
•Interfaces the BCU/CAL via high-speed high-level data link control (HDLC) link to the Central Activity
Module (CAM) in the Integrated Multisite and Console Controller (IMC)
System Manager Interface (CAL only)
One or Two Emulex Performance Series P2516-SLTL Terminal Servers
•Communicates with the BCU/CAL over the network and with the System Manager over RS-232
•Converts between Transmission Control Protocol (TCP) sockets and asynchronous serial protocol
10
PHYSICAL DESCRIPTION AND COMPATIBILITYLBI-38965
2.3. COMPATIBILITY
The BCU/CAL software is compatible with the following IMC and System Manager versions:
•IMC Software V4.01 and later
•IMC CAM Controller Board (P/N 19D903299P3)
•Networks/Data VME Controller ROM V1.03
•MicroVax System Manager Software V3.01 and later (CAL only)
The System Manager Software version requirement applies only to the CAL feature. The BCU feature
operates independent of the System Manager. Thus, the BCU is “compatible” with any System Manager
software version.
Backwards Compatibility
The BCU/CAL will function with IMC software versions down to V3.04, with minor performance degradation. The
following features are not available with IMC software versions older than V4.01:
BCU/CAL
•The User Interface “stats” command will not provide information regarding queued, denied, system busy, and
convert-to-callee channel events.
CAL-Specific
•Activity records and site monitoring will not reflect queued, denied, system busy, and convert-to-callee channel
events.
•The site monitor will not provide current control channel indication.
11
LBI-38965SPECIFICATIONS
3. SPECIFICATIONS
3.1. COMMON BCU AND CAL OPERATIONAL SPECIFICATIONS
3.1.1. EDACS System Interface
The BCU/CAL interfaces to EDACS via a full duplex port supporting high-level data link control (HDLC) protocol.
The BCU/CAL will adapt to the data transmission rate to which the Central Activity Module (CAM) is set to operate (64K
or 360K, selectable via CAM dip switches).
BCU/CAL Input Data
Each raw activity record (RAR) contains the following information:
1.Day and time of event accurate to ±0.1 second
2.Type of event (i.e., assignment or drop)
3.Call type (individual clear voice, group clear voice, individual digital voice, group digital voice, data, etc.)
4.Site number or console number
5.Channel number (to match assignments with drops)
6.Caller ID
7.Callee ID
8.Digitally dialed PSTN digits for outgoing interconnect calls
The dialed digits correspond to the digits sent by a radio to the interconnect system to initiate an interconnect call; dual
tone multi-frequency (DTMF) overdial digits sent by the radio once an interconnect call is i n progress are not registered by
the BCU.
3.1.2. Throughput
The BCU/CAL's interface to the IMC is capable of receiving a peak data rate of 192 raw activity records (RARs) per
second. A buffer stores incoming RARs at the peak rate of 192 RARs per second for a minimum of 300 seconds (5
minutes).
3.1.3. Hard Disk Interface
The BCU/CAL provides nonvolatile storage of the BCU/CAL operating software, CDRs, system configuration data,
system defaults, and subscriber attributes. The hard disk provides concurrent support of call record processing and the
operator interface.
3.1.4. Operator Interface
Most BCU/CAL operator functions are capable of being performed without impacting or reducing the capacity of the
call processing functions below specified rates. Refer to the User Interface Manual, LBI-38967, for further information.
3.2. BCU OPERATIONAL SPECIFICATIONS
This section outlines the specifications that are unique to the BCU personality.
3.2.1. Subscriber Attribute Database
Each system subscriber and each group defined on the system is assigned a record in the subscriber attribute database.
This database supports a maximum of 16,383 individual subscribers and a maximum of 2048 groups.
12
SPECIFICATIONSLBI-38965
Console
Terminal
Terminal
Console
High-Speed
HDLC Link
DAT (Optional)
DAT (Optional)
Customer
Billing
Mainframe
TCP/IP WAN
BCU
RF
System
RF
System
RF
System
Area
IMC
MIM
MIM
C
A
M
Downlink
BCU
C
A
M
Area
IMC
MIMMIM
StarGate
To other IMCs
RF
System
Ethernet
The dotted lines enclose one optional setup for a StarGate (multi-node) billing architecture.
3.2.2. Billing Architecture
The EDACS billing system architecture is shown in Figure 3. Each IMC is connected to a BCU/CAL via a high-speed
serial communications link using HDLC protocol.
Figure 3 - Billing Architecture
3.2.3. BCU Operation Overview
Each RF system sends all call information to the IMC via the downlink. This is true for single-channel autonomous
trunking (SCAT), Conventional Network Interface (CNI), basic EDACS, and RF systems operating in failsoft mode.
All call activity information messages received by the IMC are collected by the Central Activity Module (CAM), where
each call message is time stamped. These messages, called raw activity records (RARs), are then passed via the high-speed
serial link to the BCU/CAL. The BCU examines each RAR and uses the time stamp values to determine the length of each
call. The actual billing algorithm is quite complex and depends on the BCU's keeping a memory of outstanding calls. The
output of the billing algorithm is stored to a regular disk file as a series of call detail records (CDR).
The CDR format is compatible with Cincinnati Bell Information System’s (CBIS) Cellware billing software.
13
LBI-38965SPECIFICATIONS
3.2.3.1. RF Channel Usage (Air Time)
The basic unit of RF channel usage for billing purposes is a channel assignment. One or more working RF channels is
assigned in response to a request from a subscriber unit (mobile radio, data terminal, etc.). Each channel assignment event
results in air time, which is defined as the period of time during which the RF channel or group of channels is i n use,
repeating the signal from a subscriber unit. If the system is operating in transmission trunked mode, one channel
assignment occurs each time the unit is keyed and unkeyed. I n a multisite network, more than one channel assignment can
occur in a single call—since multiple sites can participate i n a call—and a channel is used on each participating site. The
air time for such a call is defined as the sum of the air time associated with all of the channel assignments occurring in that
call.
In a multiple node network (StarGate or MultiLink), a single call may involve channel assignments on sites on more
than one node. In theory, these channel assignments are part of the same call. In practice, the BCU deals with data at the
node level and does not correlate channel assignment air time from remote nodes. A multiple node call is identified by the
StarGate interface ID as the site ID in the CDR; this facilitates the correlation of records across nodes in the external billing
system.
3.2.3.2. Conversations
If a CDR were created for each call, the data storage requirements for the BCU/CAL would be excessive. For this
reason, a different unit of RF channel usage, called a conversation, has been defined. A conversation includes one or more
calls. Calls are summed into conversations based on the subscriber (radio) units participating in the calls and the duration
of the time interval between the end of one call and the beginning of the subsequent call. The criteria for inclusion i n a
conversation are explained in detail below.
Grouping Calls
A set of calls may be grouped into a conversation only if each call involves the same participants and is of the same call
type as all other calls in the set. For group calls, only calls made with the same Group Identification (GID) may be linked.
In this case, the Logical Identification (LID) of the caller is irrelevant, except for the LID of the first caller i n a sequence
(this is explained in the next subsection). For individual calls, the caller's LID must be the same as either the caller's or the
callee's LID in every other call in the set.
Broken Call Sequences
A set of calls must occur in an unbroken sequence. A sequence is broken when one of the call participants calls a nonparticipant. For individual calls, this means that either the caller or the callee from the first call in the sequence calls some
third party, either a group or individual. For group calls, the sequence is broken if the caller from the first call in the
sequence calls a different group or an individual. Note that a subscriber unit may participate in multiple group
conversations overlapping in time, as long as that unit was not the first caller in at least one of the conversations.
A sequence of calls is also broken when the time interval separating the end of one call and the beginning of the
subsequent call in the sequence exceeds an arbitrary value. This value is called the pseudo hang time and is configurable on
a unit or group basis in the BCU.
3.2.3.3. Group Billing Mode
A group call may be charged to the caller or to the group. The CDR includes a flag which indicates which party to bill.
The choice is determined by a billing mode associated with each group ID or by the default billing mode. Individual calls
are always charged to the caller, except for land-to-mobile interconnect calls and incoming data calls. In each of these
cases, the ID of the caller (or sender of the data) is unknown; thus, the call must be billed to the callee.
3.2.3.4. Input Messages
Input to the BCU consists of a stream of activity messages. As a minimum, the messages include all channel
assignment events and channel drop events generated on EDACS. This includes channel assignment and drop from the
Jessica Private Branch Exchange (PBX) Gateway and StarGate interfaces.
14
SPECIFICATIONSLBI-38965
File Name
Contents
SYSTEM.BIN
Specifies system parameters, default pseudo hang times, and billing modes.
UNIT.BIN
Specifies the pseudo hang time associated with each LID.
GROUP.BIN
Specifies the pseudo hang time and the group billing mode associated with each GID.
Channel assignment and channel drop messages contain the following information:
•Date and time of event to the nearest tenth of a second
•Type of event (i.e., assignment or drop)
•Call type (individual clear voice, group clear voice, individual digital voice, group digital voice, data, etc.)
•Site number or console number
•Channel number
•Caller ID
•Callee ID
3.2.3.5. Time Synchronization
The time of channel event value is derived from the IMC's internal clock. This is slaved to the MOM-PC clock, which
can be synchronized externally from a WWVB signal, via a Spectracom clock unit. This unit is available as a n option to
the MOM-PC. The Spectracom unit includes an internal high-stability reference clock, which maintains synchronization
even in the event of loss of the WWVB signal for a n extended period. This configuration ensures that RAR timestamps are
accurate at all times.
3.2.3.6. Output Records
The BCU creates CDRs by processing the input messages due to channel assignments and channel drops. The format
of a CDR record entry is discussed in detail in Appendix A. Each CDR records the following information about each
conversation:
•The Logical Identification (LID) of the caller
•The identity of the callee (either LID or GID)
•The location (node, site, and channel number) of each RF channel involved in the conversation
•The call type (individual clear voice, group clear voice, individual digital voice, group digital voice, data, etc.)
•A flag indicating which party to bill (caller or callee)
•The start time of the first call
•The elapsed time from the start time until the end of the final call
•The number of channel assignments included in the conversation
•The total accumulated air time (Note that this is not the same as the elapsed time because of the pseudo hang
time, and the effect of multiple channels per call.)
3.2.3.7. BCU Configuration Files
The BCU uses binary configuration files to store various configuration values. The file names and their contents are as
follows:
These files are located in the 1.2/cnfg directory.
Since they are stored in binary form, these configuration files can be modified only by using the BCU/CAL
Configuration Service (BCS) program, which is described in the User Interface Manual (LBI-38967). The BCU i s able to
operate with no terminal input by using all default values for configuration parameters.
Pending development by Ericsson Inc. of a system-wide database management strategy, there is a method by which the
BCU configuration "database" can be maintained without using BCS to configure each unit manually.
15
LBI-38965SPECIFICATIONS
The three configuration files can be created by running BCS on a BCU/CAL used a s a master. Then, these files can be
copied to the appropriate directory (1.2/cnfg) on a target BCU, and the target will assume the same configuration values.
Changes specific to the target must be made either by running BCS on the target or by making the changes on the master,
copying the configuration files to the target, then reversing the changes to restore the master to its baseline configuration.
NOTE
To copy or delete the configuration files from a BCU/CAL, you must NOT be running BCS on that system. BCS keeps all
the configuration files open while it is running, thereby preventing them from being deleted or overwritten.
3.2.3.8. Operator Functions
An EDACS system operator is able to perform the following functions locally or remotely using a terminal interface
program running on the BCU/CAL:
•Input of default configuration database.
•Default pseudo hang time.
•Default group billing mode.
•Input of configuration data for individual LIDs and/or GIDs to override the default configuration database.
(Configuration data may be input for an individual ID or range of IDs.)
- LID pseudo hang time.
- GID pseudo hang time.
- GID group billing mode.
•Creation of a magnetic tape archive of CDRs.
•Transfer CDR files from the hard drive to the floppy drive.
Refer to LBI-38967 for a detailed explanation of the available operator functions.
3.2.3.9. Database Elements
This section describes the elements of the BCU's configuration database.
Default Data
A set of subscriber default attributes maintained on the system contains the following information:
1.Default unit pseudo hang time (seconds)
2.Default group pseudo hang time (seconds)
3.Default group billing mode (caller or group)
4.Default data call pseudo hang time (seconds)
Unit Data
Each subscriber can be assigned a record in the subscriber attribute database. This record contains the following
information: Pseudo_Hang-Time (seconds).
Group Data
Each group defined on the system shall be assigned a record in the subscriber attribute database containing the
following information:
1.Group pseudo hang time (seconds)
2.Billing mode (group or caller)
16
SPECIFICATIONSLBI-38965
3.2.3.10. Call Processing
This section contains specifications on the BCU's call processing capability.
CDR Processing
A record of each conversation is maintained by the system. A conversation is a collection of calls detailed by RARs
that have been correlated based upon call participants and caller pseudo hang time. Each CDR contains the following
information:
1.Caller billing ID (BID)
2.Callee BID or GID (group ID)
3.Call type (individual, group, Digital Voice, data, interconnect, etc.)
4.Bill flag (caller or callee)
5.Identification of each RF channel (node, site, and channel)
6.Start time of the first call
7.Number of channel assignments included in the conversation
8.Total elapsed time from start time to end of final call
9.Total accumulated node air time to within ±0.5 seconds
10. PSTN number dialed on outgoing interconnect calls
11. PSTN line number on incoming interconnect calls
Call Processing CDR Output
The call processing software redirects file output to a new file when the current file being written to exceeds a
maximum size. The system administrator can set this maximum size.
CDR Storage Requirements
The BCU is capable of storing all CDRs from the previous 30 days on its internal hard drive. CDR files are maintained
on the system for a programmable time period.
CDR Processing Errors
The call processing software recovers automatically from the following error conditions:
1.Link time-out exceeded
2.Unmatched channel drops
3.Unmatched channel assignments
4.CAM hardware reset
5.WANServer reset
3.2.3.11. Call Detail Records
A CDR is a series of ASCII characters terminated by a newline (NL) character. The records are variable length, but
they contain a fixed length segment, which is always present, followed by zero or more suffix segments.
There are two types of suffix segments. The first is an additional site segment, which identifies the sites and channels
used in a multisite call. The second type of suffix is a PSTN phone number field, which is appended to a mobile-originated
interconnect call record and contains the digits dialed by the caller.
17
LBI-38965SPECIFICATIONS
3.3. CAL OPERATIONAL SPECIFICATIONS
This section outlines the specifications that are unique to the CAL personality. Refer to Figure 4 for the CAL
architecture.
NOTE
Before linking a CAL to a System Manager, consult the EDACS VAX/VMS System Manager’s User’s Manual (LBI-38984)
to assure that the proper System Manager configuration has been chosen to handle the number of sites to be monitored.
Failure to install a properly sized System Manager may result in the loss of logging data during peak periods.
3.3.1. System Manager Interface
The CAL interfaces to the System Manager's DECServer(s) via one or two terminal servers capable of supporting up to
32 independent asynchronous RS-232 serial connections. The ports on the CAL's terminal servers are connected to the
ports on the System Manager's DECServers via RS-232 cables.
3.3.2. Protocol Supported
The CAL is capable of communicating with the System Manager using the System Manager-to-Site Controller (SMSC) and Site Controller-to-System Manager (SC-SM) protocol defined in EDACS Protocol Specification, SystemManager/Site Controller Version 1.1.
TCP/IP
LAN
RF
Syst e m
Emulex
Terminal Servers
MIM
MIM
Area
IMC
CAM
High-Speed HDLC
Link (RS-422)
Centralized
Activity
Logger
(CAL)
16 RS-232
RF
System
Terminal Servers
RS-232
CAL Cons ole Terminal
DEC
Syste m
Manager
18
Emulex
Terminal Servers
Figure 4 - CAL Architecture
16 RS-232
DECNet
LAN
DEC
Terminal Servers
SPECIFICATIONSLBI-38965
3.3.3. CAL Operation Overview
As new RARs enter the system, they are dispatched to an appropriate site handler which reformats and queues the data.
When the number of activity records queued exceeds a threshold value obtained from the System Manager at startup, a
download request is sent to the System Manager. At any point, the System Manager may log in to the site object and
request it to purge its queue of activity messages, start/stop download of activity messages, or start/stop the transmission of
monitoring messages.
3.3.4. Additional Product Features
Network File System
The BCU/CAL can be licensed to function as a network File Server (NFS). This feature allows the BCU/CAL system disk
to be mounted by client hosts, such as a billing mainframe computer. The NFS feature is provided at no charge for units
licensed for BCU operation. It may be purchased as an additional feature for the CAL.
19
LBI-38965INSTALLATION
4. INSTALLATION
4.1. HARDWARE INSTALLATION
CAUTION
Turn off the power before removing or installing VMEbus boards. Removing or reinstalling the boards while the power is
on will damage the boards.
This section describes the physical installation of the BCU/CAL. Other configuration is performed during
manufacture, and the information necessary is provided in Appendix B.
Follow these steps to connect a BCU/CAL to an IMC for the first time (except where indicated otherwise, these steps
apply to all configurations; BCU only, CAL only, or BCU and CAL):
Using the LAPB cable provided, connect the BCU/CAL's CAM control port 0, a female DB-25 connector located on the
rear of the BCU enclosure, to the lower connector on the IMC backplane which corresponds to the slot in which the CAM
resides. The cable is keyed so that it fits properly only when it is correctly oriented.
BCU/CAL Equipment Rack
A6 2203710G1
BCU/CAL
CAM Control
Port 0
Data Concentrator at
BCU/CAL Equipment Rack
19C852327G1
19D903531P1
J1
J14J9
Audio Concentrator
at IMC
19D903880P120-129
IMC Equipment Rack
19D903628P71
P2P1
J1
CAM Control
This will be plugged into
PA2XX on the backplane
and will correspond with
the slot in which the CAM
control card is located.
P72
P73
Figure 5 - BCU/CAL to IMC
Next, connect the console terminal to the female DB-25 connector labeled "SERIAL PORT 1/CONSOLE" on the
TVME-712/M transition module located in the rear of the BCU/CAL enclosure. (For reference, the BCU/CAL is delivered
preconfigured from the factory in a 19-inch rack.) Connect the other end of this cable to the console terminal's "host" port,
or equivalent. If a PC is used as the console terminal, then a DB-9 adapter may be needed. In either case, the serial cable
for the console is wired straight-through.
Configure the console terminal for the communications parameters below.
•9600 Baud
•No Parity
•8 Data Bits
•1 Stop Bit
20
Loading...
+ 44 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.